acceptedSLES 12 Security Technical Implementation GuideThis Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: disa.stig_spt@mail.mil.DISASTIG.DOD.MILRelease: 1 Benchmark Date: 28 Sep 20181I - Mission Critical Classified<ProfileDescription></ProfileDescription>I - Mission Critical Public<ProfileDescription></ProfileDescription>I - Mission Critical Sensitive<ProfileDescription></ProfileDescription>II - Mission Support Classified<ProfileDescription></ProfileDescription>II - Mission Support Public<ProfileDescription></ProfileDescription>II - Mission Support Sensitive<ProfileDescription></ProfileDescription>III - Administrative Classified<ProfileDescription></ProfileDescription>III - Administrative Public<ProfileDescription></ProfileDescription>III - Administrative Sensitive<ProfileDescription></ProfileDescription>SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-010000The SUSE operating system must be a vendor-supported release.<VulnDiscussion>A SUSE operating system release is considered "supported" if the vendor continues to provide security patches for the product. With an unsupported release, it will not be possible to resolve security issues discovered in the system software.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-001230Upgrade the SUSE operating system to a version supported by the vendor. If the system is not registered with the SUSE Customer Center, register the system against the correct subscription.
If the system requires Long-Term Service Pack Support (LTSS), obtain the correct LTSS subscription for the system.Verify that the SUSE operating system is a vendor-supported release.
Check that the SUSE operating system is a vendor-supported release with the following command:
# cat /etc/os-release
NAME="SLES"
VERSION="12"
Current End of Life for SLES 12 is 31 Oct 2024.
If the release is not supported by the vendor, this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-010010Vendor-packaged SUSE operating system security patches and updates must be installed and up to date.<VulnDiscussion>Timely patching is critical for maintaining the operational availability, confidentiality, and integrity of information technology (IT) systems. However, failure to keep SUSE operating system and application software patched is a common mistake made by IT professionals. New patches are released frequently, and it is often difficult for even experienced System Administrators (SAs) to keep abreast of all the new patches. When new weaknesses in a SUSE operating system exist, patches are usually made available by the vendor to resolve the problems. If the most recent security patches and updates are not installed, unauthorized users may take advantage of weaknesses in the unpatched software. The lack of prompt attention to patching could result in a system compromise.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-001227Install the applicable SUSE operating system patches available from SUSE by running the following command:
# sudo zypper patchVerify the SUSE operating system security patches and updates are installed and up to date.
Note: Updates are required to be applied with a frequency determined by the site or Program Management Office (PMO).
Check for required SUSE operating system patches and updates with the following command:
# sudo zypper patch-check
0 patches needed (0 security patches)
If the patch repository data is corrupt check that the available package security updates have been installed on the system with the following command:
# cut -d "|" -f 1-4 -s --output-delimiter " | " /var/log/zypp/history | grep -v " radd "
2016-12-14 11:59:36 | install | libapparmor1-32bit | 2.8.0-2.4.1
2016-12-14 11:59:36 | install | pam_apparmor | 2.8.0-2.4.1
2016-12-14 11:59:36 | install | pam_apparmor-32bit | 2.8.0-2.4.1
If the SUSE operating system has not been patched within the site or PMO frequency, this is a finding.SRG-OS-000023-GPOS-00006<GroupDescription></GroupDescription>SLES-12-010020The SUSE operating system must display the Standard Mandatory DoD Notice and Consent Banner until users acknowledge the usage conditions and take explicit actions to log on for further access to the local graphical user interface (GUI).<VulnDiscussion>Display of a standardized and approved use notification before granting access to the SUSE operating system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.
The banner must be acknowledged by the user prior to allowing the user access to the SUSE operating system. This provides assurance that the user has seen the message and accepted the conditions for access. If the consent banner is not acknowledged by the user, DoD will not be in compliance with system use notifications required by law.
System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist.
The banner must be formatted in accordance with applicable DoD policy. Use the following verbiage for the SUSE operating system:
"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.
By using this IS (which includes any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.
-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."
Satisfies: SRG-OS-000023-GPOS-00006, SRG-OS-000024-GPOS-00007</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000048CCI-000050Configure the SUSE operating system to display the Standard Mandatory DoD Notice and Consent Banner until users acknowledge the usage conditions and take explicit actions to log on for further access.
Note: If GNOME is not installed, this requirement is Not Applicable.
Edit the file "/etc/gdm/Xsession".
Add the following content to the file "/etc/gdm/Xsession" below the line #!/bin/sh:
if ! zenity --text-info \
--title "Consent" \
--filename=/etc/gdm/banner \
--no-markup \
--checkbox="Accept." 10 10; then
sleep 1;
exit 1;
fi
Save the file "/etc/gdm/Xsession".Verify the SUSE operating system displays the Standard Mandatory DoD Notice and Consent Banner until users acknowledge the usage conditions and take explicit actions to log on via the local GUI.
Note: If GNOME is not installed, this requirement is Not Applicable.
Check the configuration by running the following command:
# more /etc/gdm/Xsession
The beginning of the file must contain the following text immediately after (#!/bin/sh):
if ! zenity --text-info \
--title "Consent" \
--filename=/etc/gdm/banner \
--no-markup \
--checkbox="Accept." 10 10; then
sleep 1;
exit 1;
fi
If the beginning of the file does not contain the above text immediately after the line (#!/bin/sh), this is a finding.SRG-OS-000023-GPOS-00006<GroupDescription></GroupDescription>SLES-12-010030The SUSE operating system must display the Standard Mandatory DoD Notice and Consent Banner before granting access via local console.<VulnDiscussion>Display of a standardized and approved use notification before granting access to the SUSE operating system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.
The banner must be acknowledged by the user prior to allowing the user access to the SUSE operating system. This provides assurance that the user has seen the message and accepted the conditions for access. If the consent banner is not acknowledged by the user, DoD will not be in compliance with system use notifications required by law.
System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist.
The banner must be formatted in accordance with applicable DoD policy. Use the following verbiage for SUSE operating system:
"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.
By using this IS (which includes any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.
-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000048Configure the SUSE operating system to display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system via local console by performing the following tasks:
Edit the "motd" file and replace the default text inside with the Standard Mandatory DoD banner text:
"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.
By using this IS (which includes any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.
-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."Verify the SUSE operating system displays the Standard Mandatory DoD Notice and Consent Banner before granting access to the system via local console.
Check the "motd" (message of the day) file to verify that it contains the DoD required banner text:
# more /etc/motd
The output must display the following DoD-required banner text:
"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.
By using this IS (which includes any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.
-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."
If the output does not display the correct banner text, this is a finding.SRG-OS-000228-GPOS-00088<GroupDescription></GroupDescription>SLES-12-010040The SUSE operating system must display a banner before granting local or remote access to the system via a graphical user logon.<VulnDiscussion>Display of a standardized and approved use notification before granting access to the SUSE operating system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.
The banner must be acknowledged by the user prior to allowing the user access to the SUSE operating system. This provides assurance that the user has seen the message and accepted the conditions for access. If the consent banner is not acknowledged by the user, DoD will not be in compliance with system use notifications required by law.
System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist.
The banner must be formatted in accordance with applicable DoD policy. Use the following verbiage for SUSE operating system:
"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.
By using this IS (which includes any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.
-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-001384CCI-001385CCI-001386CCI-001387CCI-001388Configure the SUSE operating system to display a banner before local or remote access to the system via a graphical user logon.
Create a database that will contain the system wide graphical user logon settings (if it does not already exist) with the following command:
# sudo touch /etc/dconf/db/local.d/01-banner-message
Add the following line to the "[org/gnome/login-screen]" section of the "/etc/dconf/db/local.d/01-banner-message" file:
[org/gnome/login-screen]
banner-message-enable=trueVerify the SUSE operating system to display a banner before local or remote access to the system via a graphical user logon.
Check that the SUSE operating system displays a banner at the logon screen by performing the following command:
# grep banner-message-enable /etc/dconf/db/local.d/*
banner-message-enable=true
If "banner-message-enable" is set to "false" or is missing completely, this is a finding.SRG-OS-000228-GPOS-00088<GroupDescription></GroupDescription>SLES-12-010050The SUSE operating system must display the approved Standard Mandatory DoD Notice before granting local or remote access to the system via a graphical user logon.<VulnDiscussion>Display of a standardized and approved use notification before granting access to the SUSE operating system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.
The banner must be acknowledged by the user prior to allowing the user access to the SUSE operating system. This provides assurance that the user has seen the message and accepted the conditions for access. If the consent banner is not acknowledged by the user, DoD will not be in compliance with system use notifications required by law.
System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist.
The banner must be formatted in accordance with applicable DoD policy. Use the following verbiage for SUSE operating system:
"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.
By using this IS (which includes any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.
-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-001384CCI-001385CCI-001386CCI-001387CCI-001388Note: If the system does not have GNOME installed, this requirement is Not Applicable. This command must be run from an X11 session; otherwise, the command will not work correctly.
Configure the SUSE operating system to display the approved Standard Mandatory DoD Notice before granting local or remote access to the system via a graphical user logon.
Create a database to contain the system wide graphical user logon settings (if it does not already exist) by performing the following command:
# touch /etc/dconf/db/local.d/01-banner-message
Add the following lines to the "[org/gnome/login-screen]" section of the "dconf/db/local.d/01-banner-message" file:
[org/gnome/login-screen]
banner-message-text="You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.\nBy using this IS (which includes any device attached to this IS), you consent to the following conditions:\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-At any time, the USG may inspect and seize data stored on this IS.\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-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.\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."
Note: The "\n" characters are for formatting only. They will not be displayed on the GUI.
Run the following command to update the database:
# dconf updateVerify the SUSE operating system displays the approved Standard Mandatory DoD Notice before granting local or remote access to the system via a graphical user logon.
Check that the SUSE operating system displays the exact approved Standard Mandatory DoD Notice and Consent Banner text by performing the following command:
# grep banner-message-text /etc/dconf/db/local.d/*
banner-message-text=
"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.\nBy using this IS (which includes any device attached to this IS), you consent to the following conditions:\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-At any time, the USG may inspect and seize data stored on this IS.\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-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.\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."
Note: The "\n" characters are for formatting only. They will not be displayed on the GUI.
If the banner text does not exactly match the approved Standard Mandatory DoD Notice and Consent Banner, this is a finding.SRG-OS-000028-GPOS-00009<GroupDescription></GroupDescription>SLES-12-010060The SUSE operating system must be able to lock the graphical user interface (GUI).<VulnDiscussion>A session 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 want to log out because of the temporary nature of the absence.
The session lock is implemented at the point where session activity can be determined.
Regardless of where the session lock is determined and implemented, once invoked, the session lock must remain in place until the user reauthenticates. No other activity aside from reauthentication must unlock the system.
Satisfies: SRG-OS-000028-GPOS-00009, SRG-OS-000030-GPOS-00011</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000056CCI-000058CCI-000060Note: If the system does not have GNOME installed, this requirement is Not Applicable. This command must be run from an X11 session; otherwise, the command will not work correctly.
Configure the SUSE operating system to allow the user to lock the GUI.
Run the following command to configure the SUSE operating system to allow the user to lock the GUI:
# gsettings set org.gnome.desktop.lockdown disable-lock-screen falseVerify the SUSE operating system allows the user to lock the GUI.
Note: If the system does not have GNOME installed, this requirement is Not Applicable. This command must be run from an X11 session, otherwise the command will not work correctly.
Run the following command:
# gsettings get org.gnome.desktop.lockdown disable-lock-screen
If the result is "true", this is a finding.SRG-OS-000028-GPOS-00009<GroupDescription></GroupDescription>SLES-12-010070The SUSE operating system must have vlock installed to allow for session locking.<VulnDiscussion>A session 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 want to log out because of the temporary nature of the absence.
The session lock is implemented at the point where session activity can be determined.
Regardless of where the session lock is determined and implemented, once invoked, the session lock must remain in place until the user reauthenticates. No other activity aside from reauthentication must unlock the system.
Satisfies: SRG-OS-000028-GPOS-00009, SRG-OS-000030-GPOS-00011, SRG-OS-000031-GPOS-00012</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000056CCI-000058CCI-000060Configure the SUSE operating system to allow the user to perform a GUI session lock.
Allow users to lock the console by installing the "vlock" package using zypper:
# sudo zypper install vlockVerify the SUSE operating system allows the user to perform a graphical user interface (GUI) session lock.
Check that the SUSE operating system has the "vlock" package installed by running the following command:
# zypper if vlock | grep "Installed:"
Installed: Yes
If "vlock" is not installed, this is a finding.SRG-OS-000029-GPOS-00010<GroupDescription></GroupDescription>SLES-12-010080The SUSE operating system must initiate a session lock after a 15-minute period of inactivity for the graphical user interface (GUI).<VulnDiscussion>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 users to manually lock their SUSE operating system session prior to vacating the vicinity, the SUSE operating system needs to be able to identify when a user's session has idled and take action to initiate the session lock.
The session lock is implemented at the point where session activity can be determined and/or controlled.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000057Configure the SUSE operating system to initiate a session lock after a 15-minute period of inactivity of the graphical user interface (GUI) by running the following command:
Note: If the system does not have GNOME installed, this requirement is Not Applicable. This command must be run from an X11 session, otherwise the command will not work correctly.
# gsettings set org.gnome.desktop.session idle-delay 900Verify the SUSE operating system initiates a session lock after a 15-minute period of inactivity via the graphical user interface (GUI) by running the following command:
Note: If the system does not have GNOME installed, this requirement is Not Applicable. This command must be run from an X11 session, otherwise the command will not work correctly.
# gsettings get org.gnome.desktop.session idle-delay
uint32 900
If the command does not return a value less than or equal to "900", this is a finding.SRG-OS-000029-GPOS-00010<GroupDescription></GroupDescription>SLES-12-010090The SUSE operating system must initiate a session lock after a 15-minute period of inactivity.<VulnDiscussion>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 users to manually lock their SUSE operating system session prior to vacating the vicinity, the SUSE operating system needs to be able to identify when a user's session has idled and take action to initiate the session lock.
The session lock is implemented at the point where session activity can be determined and/or controlled.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000057Configure the SUSE operating system to initiate a session lock after a 15-minute period of inactivity by modifying or creating (if it does not already exist) the "/etc/profile.d/autologout.sh" file and add the following lines to it:
TMOUT=900
readonly TMOUT
export TMOUT
Set the proper permissions for the "/etc/profile.d/autologout.sh" file with the following command:
# sudo chmod +x /etc/profile.d/autologout.shVerify the SUSE operating system must initiate a session logout after a 15-minute period of inactivity for all connection types.
Check the proper script exists to kill an idle session after a 15-minute period of inactivity with the following command:
# cat /etc/profile.d/autologout.sh
TMOUT=900
readonly TMOUT
export TMOUT
If the file "/etc/profile.d/autologout.sh" does not exist or the output from the function call is not the same, this is a finding.SRG-OS-000031-GPOS-00012<GroupDescription></GroupDescription>SLES-12-010100The SUSE operating system must conceal, via the session lock, information previously visible on the display with a publicly viewable image in the graphical user interface (GUI).<VulnDiscussion>A session 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.
The session lock is implemented at the point where session activity can be determined. The SUSE operating system session lock event must include an obfuscation of the display screen to prevent other users from reading what was previously displayed.
Publicly viewable images can include static or dynamic images, such as patterns used with screen savers, photographic images, solid colors, a clock, a battery life indicator, or a blank screen, with the additional caveat that none of the images conveys sensitive information.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000060Note: If the system does not have X Windows installed, this requirement is Not Applicable.
Configure the SUSE operating system to use a publically viewable image by finding the Settings menu and then navigate to the Background selection section:
- Click "Applications" on the bottom left.
- Hover over "System Tools" with the mouse.
- Click the "Settings" icon under System Tools.
- Click "Background" and then "Lock Screen".
- Set the Lock Screen image to the user's choice.
- Click "Select".
- Exit Settings Dialog.Verify the SUSE operating system conceals via the session lock information previously visible on the display with a publicly viewable image in the graphical user interface (GUI).
Note: If the system does not have X Windows installed, this requirement is Not Applicable.
Check that the lock screen is set to a publicly viewable image by running the following command:
# gsettings get org.gnome.desktop.screensaver picture-uri
'file:///usr/share/wallpapers/SLE-default-static.xml'
If nothing is returned or "org.gnome.desktop.screensaver" is not set, this is a finding.SRG-OS-000373-GPOS-00156<GroupDescription></GroupDescription>SLES-12-010110The SUSE operating system must reauthenticate users when changing authenticators, roles, or escalating privileges.<VulnDiscussion>Without reauthentication, users may access resources or perform tasks for which they do not have authorization.
When SUSE operating system provide the capability to change user authenticators, change security roles, or escalate a functional capability, it is critical the user reauthenticate.
Satisfies: SRG-OS-000373-GPOS-00156, SRG-OS-000373-GPOS-00157, SRG-OS-000373-GPOS-00158</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-002038Configure the SUSE operating system to remove any occurrence of "NOPASSWD" or "!authenticate" found in the "/etc/sudoers" file. If the system does not use passwords for authentication, the "NOPASSWD" tag may exist in the file.Verify that the SUSE operating system requires reauthentication when changing authenticators, roles, or escalating privileges.
Check that "/etc/sudoers" has no occurrences of "NOPASSWD" or "!authenticate" with the following command:
# sudo egrep -i '(nopasswd|!authenticate)' /etc/sudoers
%wheel ALL=(ALL) NOPASSWD: ALL
If any occurrences of "!authenticate" are returned, or occurrences of "NOPASSWD" are returned and active accounts on the system have valid passwords, this is a finding.SRG-OS-000027-GPOS-00008<GroupDescription></GroupDescription>SLES-12-010120The SUSE operating system must limit the number of concurrent sessions to 10 for all accounts and/or account types.<VulnDiscussion>SUSE operating system management includes the ability to control the number of users and user sessions that utilize a SUSE operating system. Limiting the number of allowed users and sessions per user is helpful in reducing the risks related to Denial-of-Service (DoS) attacks.
This requirement addresses concurrent sessions for information system accounts and does not address concurrent sessions by single users via multiple system accounts. The maximum number of concurrent sessions should be defined based on mission needs and the operational environment for each system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000054Configure the SUSE operating system to limit the number of concurrent sessions to 10 or less for all accounts and/or account types.
Add the following line to the file "/etc/security/limits.conf":
* hard maxlogins 10Verify the SUSE operating system limits the number of concurrent sessions to 10 for all accounts and/or account types by running the following command:
# grep "maxlogins" /etc/security/limits.conf
The result must contain the following line:
* hard maxlogins 10
If the "maxlogins" item is missing, the line does not begin with a star symbol, or the value is not set to "10" or less, this is a finding.SRG-OS-000021-GPOS-00005<GroupDescription></GroupDescription>SLES-12-010130The SUSE operating system must lock an account after three consecutive invalid logon attempts.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000044Configure the SUSE operating system to lock a user account until the locked account is released by an administrator after three consecutive failed logon attempts.
Add or modify the following line in the auth section of the "/etc/pam.d/login" file (or other services being used) to match the following:
auth required pam_tally2.so deny=3Verify the SUSE operating system locks a user account until the locked account is released by an administrator after three consecutive failed logon attempts.
Check that the systems locks a user account after three consecutive failed login attempts with the following command:
# grep pam_tally2.so /etc/pam.d/login
auth required pam_tally2.so deny=3
If the "deny" option is greater than "3" or is missing, this is a finding.SRG-OS-000480-GPOS-00226<GroupDescription></GroupDescription>SLES-12-010140The SUSE operating system must enforce a delay of at least four (4) seconds between logon prompts following a failed logon attempt.<VulnDiscussion>Limiting the number of logon attempts over a certain time interval reduces the chances that an unauthorized user may gain access to an account.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system to enforce a delay of at least four (4) seconds between logon prompts following a failed logon attempt.
Add or update the following variable in "/etc/login.defs" to match the line below ("FAIL_DELAY" must have a value of "4" or higher):
FAIL_DELAY 4Verify the SUSE operating system enforces a delay of at least four (4) seconds between logon prompts following a failed logon attempt.
Check that the SUSE operating system enforces a delay of at least four (4) seconds between logon prompts following a failed logon attempt with the following command:
# grep FAIL_DELAY /etc/login.defs
FAIL_DELAY 4
If the value of "FAIL_DELAY" is not set to "4", "FAIL_DELAY" is commented out, or "FAIL_DELAY" is missing, then this is a finding.SRG-OS-000069-GPOS-00037<GroupDescription></GroupDescription>SLES-12-010150The SUSE operating system must enforce passwords that contain at least one upper-case character.<VulnDiscussion>Use of a complex password helps increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.
Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000192Configure the SUSE operating system to enforce password complexity by requiring at least one upper-case character.
Edit "/etc/pam.d/common-password" and edit the line containing "pam_cracklib.so" to contain the option "ucredit=-1" after the third column.Verify the SUSE operating system enforces password complexity by requiring that at least one upper-case character.
Check that the operating system enforces password complexity by requiring that at least one upper-case character be used by using the following command:
# grep pam_cracklib.so /etc/pam.d/common-password
password requisite pam_cracklib.so ucredit=-1
If the command does not return anything, the returned line is commented out, or has a second column value different from "requisite", or does not contain "ucredit=-1", this is a finding.SRG-OS-000070-GPOS-00038<GroupDescription></GroupDescription>SLES-12-010160The SUSE operating system must enforce passwords that contain at least one lower-case character.<VulnDiscussion>Use of a complex password helps increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.
Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000193Configure the SUSE operating system to enforce password complexity by requiring at least one lower-case character.
Edit "/etc/pam.d/common-password" and edit the line containing "pam_cracklib.so" to contain the option "lcredit=-1" after the third column.Verify the SUSE operating system enforces password complexity by requiring that at least one lower-case character.
Check that the operating system enforces password complexity by requiring that at least one lower-case character be used by using the following command:
# grep pam_cracklib.so /etc/pam.d/common-password
password requisite pam_cracklib.so lcredit=-1
If the command does not return anything, the returned line is commented out, or has a second column value different from "requisite", or does not contain "lcredit=-1", this is a finding.SRG-OS-000071-GPOS-00039<GroupDescription></GroupDescription>SLES-12-010170The SUSE operating system must enforce passwords that contain at least one numeric character.<VulnDiscussion>Use of a complex password helps increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.
Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000194Configure the SUSE operating system to enforce password complexity by requiring at least one numeric character.
Edit "/etc/pam.d/common-password" and edit the line containing "pam_cracklib.so" to contain the option "dcredit=-1" after the third column.Verify the SUSE operating system enforces password complexity by requiring that at least one numeric character.
Check that the operating system enforces password complexity by requiring that at least one numeric character be used by using the following command:
# grep pam_cracklib.so /etc/pam.d/common-password
password requisite pam_cracklib.so dcredit=-1
If the command does not return anything, the returned line is commented out, or has a second column value different from "requisite", or does not contain "dcredit=-1", this is a finding.SRG-OS-000266-GPOS-00101<GroupDescription></GroupDescription>SLES-12-010180The SUSE operating system must enforce passwords that contain at least one special character.<VulnDiscussion>Use of a complex password helps increase the time and resources required to compromise the password. Password complexity or strength is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.
Password complexity is one factor in determining how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.
Special characters are not alphanumeric. Examples include: ~ ! @ # $ % ^ *.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-001619Configure the SUSE operating system to enforce password complexity by requiring at least one special character.
Edit "/etc/pam.d/common-password" and edit the line containing "pam_cracklib.so" to contain the option "ocredit=-1" after the third column.Verify the SUSE operating system enforces password complexity by requiring that at least one special character.
Check that the operating system enforces password complexity by requiring that at least one special character be used by using the following command:
# grep pam_cracklib.so /etc/pam.d/common-password
password requisite pam_cracklib.so ocredit=-1
If the command does not return anything, the returned line is commented out, or has a second column value different from "requisite", or does not contain "ocredit=-1", this is a finding.SRG-OS-000072-GPOS-00040<GroupDescription></GroupDescription>SLES-12-010190The SUSE operating system must require the change of at least eight (8) of the total number of characters when passwords are changed.<VulnDiscussion>If the SUSE operating system allows the user to consecutively reuse extensive portions of passwords, this increases the chances of password compromise by increasing the window of opportunity for attempts at guessing and brute-force attacks.
The number of changed characters refers to the number of changes required with respect to the total number of positions in the current password. In other words, characters may be the same within the two passwords; however, the positions of the like characters must be different.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000195Configure the SUSE operating system to require at least eight characters be changed between the old and new passwords during a password change with the following command:
Edit "/etc/pam.d/common-password" and edit the line containing "pam_cracklib.so" to contain the option "difok=8" after the third column.Verify the SUSE operating system requires at least eight (8) characters be changed between the old and new passwords during a password change.
Check that the operating system requires at least eight (8) characters be changed between the old and new passwords during a password change by running the following command:
# grep pam_cracklib.so /etc/pam.d/common-password
password requisite pam_cracklib.so difok=8
If the command does not return anything, the returned line is commented out, or has a second column value different from "requisite", or does not contain "difok", or the value is less than "8", this is a finding.SRG-OS-000120-GPOS-00061<GroupDescription></GroupDescription>SLES-12-010200The SUSE operating system must employ FIPS 140-2 approved cryptographic hashing algorithm for system authentication (system-auth).<VulnDiscussion>Unapproved mechanisms that are used for authentication to the cryptographic module are not verified and therefore cannot be relied on to provide confidentiality or integrity, and DoD data may be compromised.
SUSE operating systems using encryption are required to use FIPS-compliant mechanisms for authenticating to cryptographic modules.
FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules use authentication that meets DoD requirements. This allows for Security Levels 1, 2, 3, or 4 for use on a general-purpose computing system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000803Configure the SUSE operating system to require "pam_unix.so auth" to use SHA512.
Edit "/etc/pam.d/common-auth" and edit the line containing "pam_unix.so" to contain the option "sha512" after the third column.Verify the SUSE operating system requires that "pam_unix.so auth" is configured to use SHA512
Check the algorithms that are used to hash system passwords with the command:
# grep pam_unix.so /etc/pam.d/common-auth
auth required pam_unix.so sha512 try_first_pass
If the command does not return anything, the returned line is commented out, or has a second column value different from "required", or does not contain "sha512", this is a finding.SRG-OS-000120-GPOS-00061<GroupDescription></GroupDescription>SLES-12-010210The SUSE operating system must employ FIPS 140-2 approved cryptographic hashing algorithm for system authentication (login.defs).<VulnDiscussion>Unapproved mechanisms that are used for authentication to the cryptographic module are not verified and therefore cannot be relied on to provide confidentiality or integrity, and DoD data may be compromised.
SUSE operating systems using encryption are required to use FIPS-compliant mechanisms for authenticating to cryptographic modules.
FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules use authentication that meets DoD requirements. This allows for Security Levels 1, 2, 3, or 4 for use on a general purpose computing system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000803Configure the SUSE operating system to require "ENCRYPT_METHOD" in "/etc/login.defs" be set to "SHA512" by running the following command as a superuser:
# sudo grep -q '^.*ENCRYPT_METHOD' /etc/login.defs && sudo sed -i 's/^.*ENCRYPT_METHOD.*/ENCRYPT_METHOD SHA512/' /etc/login.defs || sudo echo 'ENCRYPT_METHOD SHA512' >> /etc/login.defsVerify the SUSE operating system requires that the "ENCRYPT_METHOD" value in "/etc/login.defs" is set to "SHA512".
Check the value of "ENCRYPT_METHOD" value in "/etc/login.defs" with the following command:
# cat /etc/login.defs | grep -i encrypt_method
ENCRYPT_METHOD SHA512
If "ENCRYPT_METHOD" is not set to "SHA512", if any values other that "SHA512" are configured, or "ENCRYPT_METHOD" is commented out or not set, this is a finding.SRG-OS-000073-GPOS-00041<GroupDescription></GroupDescription>SLES-12-010220The SUSE operating system must employ FIPS 140-2-approved cryptographic hashing algorithms for all stored passwords.<VulnDiscussion>The system must use a strong hashing algorithm to store the password. The system must use a sufficient number of hashing rounds to ensure the required level of entropy.
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.
Satisfies: SRG-OS-000073-GPOS-00041, SRG-OS-000120-GPOS-00061</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000196CCI-000803Configure the SUSE operating system to encrypt all stored passwords with a strong cryptographic hash.
Set "ENCRYPT_METHOD" in "/etc/login.defs" to "SHA512" by running the following command as a superuser:
# sudo grep -q '^.*ENCRYPT_METHOD' /etc/login.defs && sudo sed -i 's/^.*ENCRYPT_METHOD.*/ENCRYPT_METHOD SHA512/' /etc/login.defs || sudo echo 'ENCRYPT_METHOD SHA512' >> /etc/login.defs
Lock all interactive user accounts not using SHA512 hashing until the passwords can be regenerated.Verify the SUSE operating system requires the shadow password suite configuration be set to encrypt interactive user passwords using a strong cryptographic hash.
Check that the interactive user account passwords are using a strong password hash with the following command:
# sudo cut -d: -f2 /etc/shadow
$6$kcOnRq/5$NUEYPuyL.wghQwWssXRcLRFiiru7f5JPV6GaJhNC2aK5F3PZpE/BCCtwrxRc/AInKMNX3CdMw11m9STiql12f/
Password hashes "!" or "*" indicate inactive accounts not available for logon and are not evaluated.
If any interactive user password hash does not begin with "$6", this is a finding.SRG-OS-000073-GPOS-00041<GroupDescription></GroupDescription>SLES-12-010230The SUSE operating system must configure the Linux Pluggable Authentication Modules (PAM) to only store encrypted representations of passwords.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000196Configure the SUSE operating system Linux PAM to only store encrypted representations of passwords. All account passwords must be hashed with SHA512 encryption strength.
Edit "/etc/pam.d/common-password" and edit the line containing "pam_unix.so" to contain the SHA512 keyword after third column. Remove the "nullok" option.Verify the SUSE operating system configures the Linux PAM to only store encrypted representations of passwords. All account passwords must be hashed with SHA512 encryption strength.
Check that PAM is configured to create SHA512 hashed passwords by running the following command:
# grep pam_unix.so /etc/pam.d/common-password
password required pam_unix.so sha512
If the command does not return anything or the returned line is commented out, has a second column value different from "required", or does not contain "sha512", this is a finding.SRG-OS-000073-GPOS-00041<GroupDescription></GroupDescription>SLES-12-010240The SUSE operating system must employ FIPS 140-2-approved cryptographic hashing algorithms for all stored passwords.<VulnDiscussion>The system must use a strong hashing algorithm to store the password. The system must use a sufficient number of hashing rounds to ensure the required level of entropy.
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.
Satisfies: SRG-OS-000073-GPOS-00041, SRG-OS-000120-GPOS-00061</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000196CCI-000803Configure the SUSE operating system to encrypt all stored passwords with a strong cryptographic hash.
Edit/modify the following line in the "/etc/login.defs" file and set "SHA_CRYPT_MIN_ROUNDS" to a value no lower than "5000":
SHA_CRYPT_MIN_ROUNDS 5000Verify the SUSE operating system configures the shadow password suite configuration to encrypt passwords using a strong cryptographic hash.
Check that a minimum number of hash rounds is configured by running the following command:
egrep "^SHA_CRYPT_" /etc/login.defs
If only one of "SHA_CRYPT_MIN_ROUNDS" or "SHA_CRYPT_MAX_ROUNDS" is set, and this value is below "5000", this is a finding.
If both "SHA_CRYPT_MIN_ROUNDS" and "SHA_CRYPT_MAX_ROUNDS" are set, and the highest value for either is below "5000", this is a finding.SRG-OS-000078-GPOS-00046<GroupDescription></GroupDescription>SLES-12-010250The SUSE operating system must employ passwords with a minimum of 15 characters.<VulnDiscussion>The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised.
Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps determine strength and how long it takes to crack a password. Use of more characters in a password helps exponentially increase the time and/or resources required to compromise the password.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000205Configure the SUSE operating system to enforce a minimum 15-character password length.
Edit "/etc/pam.d/common-password" and edit the line containing "pam_cracklib.so" to contain the option "minlen=15" after the third column.
The DoD standard requires a minimum 15-character password length.Verify the SUSE operating system enforces a minimum 15-character password length.
Check that the operating system enforces a minimum 15-character password length with the following command:
# grep pam_cracklib.so /etc/pam.d/common-password
password requisite pam_cracklib.so minlen=15
If the command does not return anything, the returned line is commented out, or has a second column value different from "requisite", or does not contain "minlen" value, or the value is less than "15", this is a finding.SRG-OS-000075-GPOS-00043<GroupDescription></GroupDescription>SLES-12-010260The SUSE operating system must be configured to create or update passwords with a minimum lifetime of 24 hours (1 day).<VulnDiscussion>Enforcing a minimum password lifetime helps prevent repeated password changes to defeat the password reuse or history enforcement requirement. If users are allowed to immediately and continually change their password, the password could be repeatedly changed in a short period of time to defeat the organization's policy regarding password reuse.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000198Configure the SUSE operating system to enforce 24 hours/1 day or greater as the minimum password age.
Edit the file "/etc/login.defs" and add or correct the following line. Replace [DAYS] with the appropriate amount of days:
PASS_MIN_DAYS [DAYS]
The DoD requirement is "1" but a greater value is acceptable.Verify the SUSE operating system to create or update passwords with minimum password age of "1" day or greater.
Check that the SUSE operating system enforces 24 hours/1 day as the minimum password age, run the following command:
# grep PASS_MIN_DAYS /etc/login.defs
PASS_MIN_DAYS 1
If "PASS_MIN_DAYS" does not have a value of "1" or greater, this is a finding.SRG-OS-000075-GPOS-00043<GroupDescription></GroupDescription>SLES-12-010270The SUSE operating system must employ user passwords with a minimum lifetime of 24 hours (1 day).<VulnDiscussion>Enforcing a minimum password lifetime helps prevent repeated password changes to defeat the password reuse or history enforcement requirement. If users are allowed to immediately and continually change their password, the password could be repeatedly changed in a short period of time to defeat the organization's policy regarding password reuse.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000198Configure the SUSE operating system to enforce 24 hours/1 day or greater as the minimum password age for user accounts.
Change the minimum time period between password changes for each [USER] account to "1" day with the command, replacing [USER] with the user account that must be changed:
# sudo passwd -n 1 [USER]Verify the SUSE operating system enforces a minimum time period between password changes for each user account of "1" day or greater.
Check the minimum time period between password changes for each user account with the following command:
# sudo cat /etc/shadow | cut -d ':' -f1,4 | grep -v 1 | grep -v ":$"
smithj:1
If any account has a value of "0", this is a finding.SRG-OS-000076-GPOS-00044<GroupDescription></GroupDescription>SLES-12-010280The SUSE operating system must be configured to create or update passwords with a maximum lifetime of 60 days.<VulnDiscussion>Any password, no matter how complex, can eventually be cracked. Therefore, passwords need to be changed periodically. If the SUSE operating system does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the SUSE operating system passwords could be compromised.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000199Configure the SUSE operating system to enforce a maximum password age of "60" days or less.
Edit the file "/etc/login.defs" and add or correct the following line. Replace [DAYS] with the appropriate amount of days:
PASS_MAX_DAYS [DAYS]
The DoD requirement is "60" days or less (greater than zero, as zero days will lock the account immediately).Verify that the SUSE operating system is configured to create or update passwords with a maximum password age of "60" days or less.
Check that the SUSE operating system enforces "60" days or less as the maximum password age with the following command:
# grep PASS_MAX_DAYS /etc/login.defs
The DoD requirement is "60" days or less (greater than zero, as zero days will lock the account immediately).
If PASS_MAX_DAYS is not set to "60" days or less, this is a finding.SRG-OS-000076-GPOS-00044<GroupDescription></GroupDescription>SLES-12-010290The SUSE operating system must employ user passwords with a maximum lifetime of 60 days.<VulnDiscussion>Any password, no matter how complex, can eventually be cracked. Therefore, passwords need to be changed periodically. If the SUSE operating system does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the SUSE operating system passwords could be compromised.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000199Configure the SUSE operating system to enforce a maximum password age of each [USER] account to "60" days. The command in the check text will give a list of users that need to be updated to be in compliance:
# sudo passwd -x 60 [USER]
The DoD requirement is "60" days.Verify that the SUSE operating system enforces a maximum user password age of "60" days or less.
Check that the SUSE operating system enforces "60" days or less as the maximum user password age with the following command:
# sudo cat /etc/shadow | cut -d':' -f1,5 | egrep -v "([0|60])" | grep -v ":$"
If any results are returned, this is a finding.SRG-OS-000077-GPOS-00045<GroupDescription></GroupDescription>SLES-12-010300The SUSE operating system must employ a password history file.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000200Configure the SUSE operating system to create the password history file with the following commands:
# sudo touch /etc/security/opasswd
# sudo chown root:root /etc/security/opasswd
# sudo chmod 0600 /etc/security/opasswdVerify the password history file exists on the SUSE operating system.
Check that the password history file exists with the following command:
# ls -al /etc/security/opasswd
-rw------- 1 root root 7 Dec 13 17:21 /etc/security/opasswd
If "/etc/security/opasswd" does not exist, this is a finding.SRG-OS-000077-GPOS-00045<GroupDescription></GroupDescription>SLES-12-010310The SUSE operating system must not allow passwords to be reused for a minimum of five (5) generations.<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000200Configure the SUSE operating system password history to prohibit the reuse of a password for a minimum of five generations.
Edit "/etc/pam.d/common-password" and edit the line containing "pam_pwhistory.so" to contain the option "remember=5 useauthtok" after the third column.Verify the SUSE operating system prohibits the reuse of a password for a minimum of five (5) generations.
Check that the SUSE operating system prohibits the reuse of a password for a minimum of five (5) generations with the following command:
# grep pam_pwhistory.so /etc/pam.d/common-password
password requisite pam_pwhistory.so remember=5 useauthtok
If the command does not return anything, the returned line is commented out, or has a second column value different from "requisite", or does not contain "remember" value, or the value is less than "5", or is missing the "useauthtok" keyword, this is a finding.SRG-OS-000480-GPOS-00225<GroupDescription></GroupDescription>SLES-12-010320The SUSE operating system must prevent the use of dictionary words for passwords.<VulnDiscussion>If the SUSE operating system allows the user to select passwords based on dictionary words, this increases the chances of password compromise by increasing the opportunity for successful guesses and brute-force attacks.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system to prevent the use of dictionary words for passwords.
Edit "/etc/pam.d/common-password" and add the following line:
password requisite pam_cracklib.soVerify the SUSE operating system prevents the use of dictionary words for passwords.
Check that the SUSE operating system prevents the use of dictionary words for passwords with the following command:
# grep pam_cracklib.so /etc/pam.d/common-password
password requisite pam_cracklib.so
If the command does not return anything, or the returned line is commented out, this is a finding.SRG-OS-000123-GPOS-00064<GroupDescription></GroupDescription>SLES-12-010330The SUSE operating system must never automatically remove or disable emergency administrator accounts.<VulnDiscussion>Emergency accounts are privileged accounts that are established in response to crisis situations where the need for rapid account activation is required. Therefore, emergency account activation may bypass normal account authorization processes. If these accounts are automatically disabled, system maintenance during emergencies may not be possible, thus adversely affecting system availability.
Emergency accounts are different from infrequently used accounts (i.e., local logon accounts used by the organization's system administrators when network or normal logon/access is not available). Infrequently used accounts are not subject to automatic termination dates. Emergency accounts are accounts created in response to crisis situations, usually for use by maintenance personnel. The automatic expiration or disabling time period may be extended as needed until the crisis is resolved; however, it must not be extended indefinitely. A permanent account should be established for privileged users who need long-term maintenance accounts.
To address access requirements the SUSE operating system can be integrated with enterprise-level authentication/access mechanisms that meet or exceed access control policy requirements.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-001682Configure the SUSE operating system to never automatically remove or disable emergency administrator accounts.
Replace "[Emergency_Administrator]" in the following command with the correct emergency administrator account. Run the following command as an administrator:
# sudo chage -I -1 -M 99999 [Emergency_Administrator]Verify the SUSE operating system is configured such that emergency administrator accounts are never automatically removed or disabled.
Note: Root is typically the "account of last resort" on a system and is also used as the example emergency administrator account. If another account is being used as the emergency administrator account, the command should be used against that account.
Check to see if the root account password or account expires with the following command:
# sudo chage -l [Emergency_Administrator]
Password expires:never
If "Password expires" or "Account expires" is set to anything other than "never", this is a finding.SRG-OS-000118-GPOS-00060<GroupDescription></GroupDescription>SLES-12-010340The SUSE operating system must disable account identifiers (individuals, groups, roles, and devices) after 35 days of inactivity after password expiration.<VulnDiscussion>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.
The SUSE operating system needs to track periods of inactivity and disable application identifiers after 35 days of inactivity.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000795Configure the SUSE operating system to disable account identifiers after "35" days of inactivity after the password expiration.
Run the following command to change the configuration for "useradd" to disable the account identifier after "35" days:
# sudo useradd -D -f 35
DoD recommendation is "35" days, but a lower value greater than "0" is acceptable.Verify the SUSE operating system disables account identifiers after "35" days of inactivity after the password expiration
Check the account inactivity value by performing the following command:
# sudo grep -i inactive /etc/default/useradd
INACTIVE=35
If "INACTIVE" is not set to a value greater than "0" and less than or equal to "35", this is a finding.SRG-OS-000002-GPOS-00002<GroupDescription></GroupDescription>SLES-12-010360The SUSE operating system must provision temporary accounts with an expiration date for 72 hours.<VulnDiscussion>If temporary user accounts remain active when no longer needed or for an excessive period, these accounts may be used to gain unauthorized access. To mitigate this risk, automated termination of all temporary accounts must be set upon account creation.
Temporary accounts are established as part of normal account activation procedures when there is a need for short-term accounts without the demand for immediacy in account activation.
If temporary accounts are used, the SUSE operating system must be configured to automatically terminate these types of accounts after a DoD-defined time period of 72 hours.
To address access requirements, many SUSE operating systems may be integrated with enterprise-level authentication/access mechanisms that meet or exceed access control policy requirements.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000016In the event temporary accounts are required, configure the SUSE operating 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" with the appropriate value:
# sudo chage -E `date -d "+3 days" +%Y-%m-%d` system_account_name
`date -d "+3 days" +%Y-%m-%d` sets the 72-hour expiration date for the account at the time the command is run.Verify that the SUSE operating system provisions temporary accounts with an expiration date for "72" hours.
Ask the System Administrator if any temporary accounts have been added to the system. For every existing temporary account, run the following command to obtain its account expiration information:
# sudo chage -l system_account_name
Verify each of these accounts has an expiration date that is within "72" hours of its creation.
If any temporary accounts have no expiration date set or do not expire within "72" hours of their creation, this is a finding.SRG-OS-000480-GPOS-00226<GroupDescription></GroupDescription>SLES-12-010370The SUSE operating system must enforce a delay of at least four seconds between logon prompts following a failed logon attempt.<VulnDiscussion>Limiting the number of logon attempts over a certain time interval reduces the chances that an unauthorized user may gain access to an account.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system to enforce a delay of at least four seconds between logon prompts following a failed logon attempt.
Edit the file "/etc/pam.d/common-auth".
Add a parameter "pam_faildelay" and set it to:
# delay is in micro seconds
auth required pam_faildelay.so delay=4000000Verify the SUSE operating system enforces a delay of at least four seconds between logon prompts following a failed logon attempt.
# grep pam_faildelay /etc/pam.d/common-auth*
auth required pam_faildelay.so delay=4000000
If the value of "delay" is not set to "4000000", "delay" is commented out, "delay" is missing, or the "pam_faildelay" line is missing completely, this is a finding.SRG-OS-000480-GPOS-00229<GroupDescription></GroupDescription>SLES-12-010380The SUSE operating system must not allow unattended or automatic logon via the graphical user interface (GUI).<VulnDiscussion>Failure to restrict system access to authenticated users negatively impacts SUSE operating system security.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Note: If GNOME is not installed, this requirement is Not Applicable.
Configure the SUSE operating system GUI to not allow unattended or automatic logon to the system.
Add or edit the following line in the "/etc/gdm/custom.conf" file directly below the "[daemon]" tag:
AutomaticLoginEnable=falseNote: If GNOME is not installed, this requirement is Not Applicable.
Verify the SUSE operating system does not allow unattended or automatic logon via the GUI.
Check that unattended or automatic login is disabled with the following command:
# sudo grep -i automaticloginenable /etc/gdm/custom.conf
AutomaticLoginEnable=false
If the "AutomaticLoginEnable" parameter is not set to "false", this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-010390The SUSE operating system must display the date and time of the last successful account logon upon logon.<VulnDiscussion>Providing users with feedback on when account accesses last occurred facilitates user recognition and reporting of unauthorized account use.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system to provide users with feedback on when account accesses last occurred by setting the required configuration options in "/etc/pam.d/login".
Add the following line to the top of "/etc/pam.d/login":
session required pam_lastlog.so showfailedVerify the SUSE operating system users are provided with feedback on when account accesses last occurred.
Check that "pam_lastlog" is used and not silent with the following command:
# grep pam_lastlog /etc/pam.d/login
session required pam_lastlog.so showfailed
If "pam_lastlog" is missing from "/etc/pam.d/login" file, or the "silent" option is present, this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-010400There must be no .shosts files on the SUSE operating system.<VulnDiscussion>The .shosts files are used to configure host-based authentication for individual users or the system via SSH. Host-based authentication is not sufficient for preventing unauthorized access to the system, as it does not require interactive identification and authentication of a connection request, or for the use of two-factor authentication.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Remove any ".shosts" files found on the SUSE operating system.
# rm /[path]/[to]/[file]/.shostsVerify there are no ".shosts" files on the SUSE operating system.
Check the system for the existence of these files with the following command:
# find / -name '*.shosts'
If any ".shosts" files are found on the system, this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-010410There must be no shosts.equiv files on the SUSE operating system.<VulnDiscussion>The shosts.equiv files are used to configure host-based authentication for the system via SSH. Host-based authentication is not sufficient for preventing unauthorized access to the system, as it does not require interactive identification and authentication of a connection request, or for the use of two-factor authentication.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Remove any ".shosts.equiv" files found on the SUSE operating system.
# rm /etc/ssh/shosts.equivVerify there are no "shosts.equiv" files on the SUSE operating system.
Check the system for the existence of these files with the following command:
# ls -al /etc/ssh/shosts.equiv
If any "shosts.equiv" files are found on the system, this is a finding.SRG-OS-000478-GPOS-00223<GroupDescription></GroupDescription>SLES-12-010420FIPS 140-2 mode must be enabled on the SUSE operating system.<VulnDiscussion>Use of weak or untested encryption algorithms undermines the purposes of using encryption to protect data. The SUSE operating system must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.
Satisfies: SRG-OS-000396-GPOS-00176, SRG-OS-000478-GPOS-00223</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-002450To configure the SUSE operating system to run in FIPS mode, add "fips=1" to the kernel parameter during the SUSE operating system install.
Enabling FIPS mode on a preexisting system involves a number of modifications to the SUSE operating system. Refer to section 9.1, "Crypto Officer Guidance", of the following document for installation guidance:
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2435.pdfVerify the SUSE operating system is running in FIPS mode by running the following command.
# cat /proc/sys/crypto/fips_enabled
1
If nothing is returned, the file does not exist, or the value returned is "0", this is a finding.SRG-OS-000080-GPOS-00048<GroupDescription></GroupDescription>SLES-12-010430SUSE operating systems with a basic input/output system (BIOS) must require authentication upon booting into single-user and maintenance modes.<VulnDiscussion>To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DoD-approved PKIs, all DoD systems (e.g., web servers and web portals) must be properly configured to incorporate access control methods that do not rely solely on the possession of a certificate for access. Successful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement.
Access control policies include identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed by the application to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000213Note: If the system does not use a basic input/output system (BIOS) this requirement is Not Applicable.
Configure the SUSE operating system to encrypt the boot password.
Generate an encrypted (GRUB2) password for root with the following command:
# sudo grub2-mkpasswd-pbkdf2
Enter Password:
Reenter Password:
PBKDF2 hash of your password is grub.pbkdf2.sha512.10000.MFU48934NJD84NF8NSD39993JDHF84NG
Using the hash from the output, modify the "/etc/grub.d/40_custom" file with the following command to add a boot password for the root entry:
# cat << EOF
set superusers="root"
password_pbkdf2 root grub.pbkdf2.sha512.VeryLongString
EOF
Generate an updated "grub.conf" file with the new password using the following commands:
# sudo grub2-mkconfig --output=/tmp/grub2.cfg
# sudo mv /tmp/grub2.cfg /boot/grub2/grub.cfgVerify that the SUSE operating system has set an encrypted root password.
Note: If the system does not use a basic input/output system (BIOS) this requirement is Not Applicable.
Check that the encrypted password is set for root with the following command:
# sudo cat /boot/grub2/grub.cfg | grep -i password
password_pbkdf2 root grub.pbkdf2.sha512.10000.VeryLongString
If the root password entry does not begin with "password_pbkdf2", this is a finding.SRG-OS-000080-GPOS-00048<GroupDescription></GroupDescription>SLES-12-010440SUSE operating systems with Unified Extensible Firmware Interface (UEFI) implemented must require authentication upon booting into single-user mode and maintenance.<VulnDiscussion>If the system allows a user to boot into single-user or maintenance mode without authentication, any user that invokes single-user or maintenance mode is granted privileged access to all system information.
If the system is running in EFI mode, SLES 12 by default will use GRUB 2 EFI as the boot loader.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000213Note: If the system does not use UEFI, this requirement is Not Applicable.
Configure the SUSE operating system to encrypt the boot password.
Generate an encrypted (GRUB 2) password for root with the following command:
# sudo grub2-mkpasswd-pbkdf2
Enter Password:
Reenter Password:
PBKDF2 hash of your password is grub.pbkdf2.sha512.10000.MFU48934NJD84NF8NSD39993JDHF84NG
Using the hash from the output, modify the "/etc/grub.d/40_custom" file with the following command to add a boot password for the root entry:
# cat << EOF
set superusers="root"
password_pbkdf2 root grub.pbkdf2.sha512.VeryLongString
EOF
Generate an updated "grub.conf" file with the new password using the following commands:
# sudo grub2-mkconfig --output=/tmp/grub2.cfg
# sudo mv /tmp/grub2.cfg /boot/efi/EFI/sles12/grub.cfgVerify that the SUSE operating system has set an encrypted root password.
Note: If the system does not use Unified Extensible Firmware Interface (UEFI) this requirement is Not Applicable.
Check that the encrypted password is set for root with the following command:
# sudo cat /boot/efi/EFI/sles12/grub.cfg | grep -i password
password_pbkdf2 root grub.pbkdf2.sha512.10000.VeryLongString
If the root password entry does not begin with "password_pbkdf2", this is a finding.SRG-OS-000185-GPOS-00079<GroupDescription></GroupDescription>SLES-12-010450All SUSE operating system persistent disk partitions must implement cryptographic mechanisms to prevent unauthorized disclosure or modification of all information that requires at rest protection.<VulnDiscussion>SUSE operating systems handling data requiring "data at rest" protections must employ cryptographic mechanisms to prevent unauthorized disclosure and modification of the information at rest.
Selection of a cryptographic mechanism is based on the need to protect the integrity of organizational information. The strength of the mechanism is commensurate with the security category and/or classification of the information. Organizations have the flexibility to either encrypt all information on storage devices (i.e., full disk encryption) or encrypt specific data structures (e.g., files, records, or fields).
Satisfies: SRG-OS-000185-GPOS-00079, SRG-OS-000404-GPOS-00183, SRG-OS-000405-GPOS-00184</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-001199CCI-002475Configure the SUSE operating system to prevent unauthorized modification of all information at rest by using disk encryption.
Encrypting a partition in an already-installed system is more difficult because of the need to resize and change existing partitions. To encrypt an entire partition, dedicate a partition for encryption in the partition layout. The standard partitioning proposal as suggested by YaST (installation and configuration tool for Linux) does not include an encrypted partition by default. Add it manually in the partitioning dialog.
Refer to the document "SUSE 12 Security Guide", Section 11.1, for a detailed disk encryption guide:
https://www.suse.com/documentation/sles-12/book_security/data/sec_security_cryptofs_y2.html#sec_security_cryptofs_y2_part_runVerify the SUSE operating system prevents unauthorized disclosure or modification of all information requiring at rest protection by using disk encryption.
Determine the partition layout for the system with the following command:
# sudo fdisk -l
Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 4208639 4206592 2G 82 Linux swap / Solaris
/dev/sda2 * 4208640 53479423 49270784 23.5G 83 Linux
/dev/sda3 53479424 125829119 72349696 34.5G 83 Linux
Verify the system partitions are all encrypted with the following command:
# sudo more /etc/crypttab
luks UUID=114167a-2a94-6cda-f1e7-15ad146c258b
swap /dev/sda1 /dev/urandom swap
truecrypt /dev/sda2 /etc/container_password tcrypt
truecrypt /dev/sda3 /etc/container_password tcrypt
Every persistent disk partition present on the system must have an entry in the file.
If any partitions other than pseudo file systems (such as /proc or /sys) are not listed or "/etc/crypttab" does not exist, this is a finding.SRG-OS-000138-GPOS-00069<GroupDescription></GroupDescription>SLES-12-010460The sticky bit must be set on all SUSE operating system world-writable directories.<VulnDiscussion>Preventing unauthorized information transfers mitigates the risk of information, including encrypted representations of information, produced by the actions of prior users/roles (or the actions of processes acting on behalf of prior users/roles) from being available to any current users/roles (or current processes) that obtain access to shared system resources (e.g., registers, main memory, and hard disks) after those resources have been released back to information systems. The control of information in shared resources is also commonly referred to as object reuse and residual information protection.
This requirement generally applies to the design of an information technology product, but it can also apply to the configuration of particular information system components that are, or use, such products. This can be verified by acceptance/validation processes in DoD or other government agencies.
There may be shared resources with configurable protections (e.g., files in storage) that may be assessed on specific information system components.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-001090Configure the SUSE operating system shared system resources to prevent any unauthorized and unintended information transfer by setting the sticky bit for all world-writable directories.
An example of a world-writable directory is "/tmp" directory. Set the sticky bit on all of the world-writable directories (using the "/tmp" directory as an example) with the following command:
# sudo chmod 1777 /tmp
For every world-writable directory, replace "/tmp" in the command above with the world-writable directory that does not have the sticky bit set.Verify the SUSE operating system prevents unauthorized and unintended information transfer via the shared system resources.
Check that world-writable directories have the sticky bit set with the following command:
# sudo find / -xdev -perm -002 -type d -fstype xfs -exec ls -lLd {} \;
256 0 drwxrwxrwt 1 root root 4096 Jun 14 06:45 /tmp
If any of the returned directories do not have the sticky bit set, or are not documented as having the write permission for the other class, this is a finding.SRG-OS-000363-GPOS-00150<GroupDescription></GroupDescription>SLES-12-010500Advanced Intrusion Detection Environment (AIDE) must verify the baseline SUSE operating system configuration at least weekly.<VulnDiscussion>Unauthorized changes to the baseline configuration could make the system vulnerable to various attacks or allow unauthorized access to the SUSE operating system. Changes to SUSE operating system configurations can have unintended side effects, some of which may be relevant to security.
Detecting such changes and providing an automated response can help avoid unintended, negative consequences that could ultimately affect the security state of the SUSE operating system. The SUSE operating system's Information Management Officer (IMO)/Information System Security Officer (ISSO) and System Administrator (SAs) must be notified via email and/or monitoring system trap when there is an unauthorized modification of a configuration item.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-001744CCI-002696CCI-002699Configure the SUSE operating system to check the baseline configuration for unauthorized changes at least once weekly.
If the "aide" package is not installed, install it with the following command:
# sudo zypper in aide
Configure the file integrity tool to automatically run on the system at least weekly. The following example output is generic. It will set cron to run AIDE weekly, but other file integrity tools may be used:
# cat /etc/cron.weekly/aide
0 0 * * * /usr/sbin/aide --check | /bin/mail -s "aide integrity check run for <system name>" root@notareal.emailVerify the SUSE operating system checks the baseline configuration for unauthorized changes at least once weekly.
Note: A file integrity tool other than Advanced Intrusion Detection Environment (AIDE) may be used, but the tool must be executed at least once per week.
Check to see if the "aide" package is installed on the system with the following command:
# sudo zypper if aide | grep "Installed"
Installed: Yes
If the "aide" package is not installed, ask the System Administrator (SA) how file integrity checks are performed on the system.
Check for the presence of a cron job running daily or weekly on the system that executes AIDE to scan for changes to the system baseline. The command used in the following example looks at the daily cron job:
Check the "/etc/cron" subdirectories for a "crontab" file controlling the execution of the file integrity application. For example, if AIDE is installed on the system, use the following command:
# grep aide etc/crontab etc/cron.*
/etc/crontab: 30 04 * * * /etc/aide
If the file integrity application does not exist, or a "crontab" file does not exist in "/etc/crontab", the "/etc/cron.daily" subdirectory, or "/etc/cron.weekly" subdirectory, this is a finding.SRG-OS-000447-GPOS-00201<GroupDescription></GroupDescription>SLES-12-010510The SUSE operating system must notify the System Administrator (SA) when AIDE discovers anomalies in the operation of any security functions.<VulnDiscussion>If anomalies are not acted on, security functions may fail to secure the system.
Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters.
Notifications provided by information systems include messages to local computer consoles and/or hardware indications, such as lights.
This 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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-002702Configure the SUSE operating system to notify the SA when AIDE discovers anomalies in the operation of any security functions.
Create the aide crontab file in "/etc/cron.daily" and add following command replacing the "[E-MAIL]" parameter with a proper email address for the SA:
0 0 * * * /usr/sbin/aide --check | /bin/mail -s "aide integrity check run for <system name>" root@notareal.emailVerify the SUSE operating system notifies the SA when AIDE discovers anomalies in the operation of any security functions.
Check to see if the aide cron job sends an email when executed with the following command:
# sudo grep -i "aide" /etc/cron.*/aide
0 0 * * * /usr/sbin/aide --check | /bin/mail -s "aide integrity check run for <system name>" root@notareal.email
If the "aide" file does not exist under the "/etc/cron" directory structure or the cron job is not configured to execute a binary to send an email (such as "/usr/bin/mail"), this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-010520The SUSE operating system file integrity tool must be configured to verify Access Control Lists (ACLs).<VulnDiscussion>ACLs can provide permissions beyond those permitted through the file mode and must be verified by file integrity tools.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system file integrity tool to check file and directory ACLs.
If AIDE is installed, ensure the "acl" rule is present on all file and directory selection lists.Verify that the SUSE operating system file integrity tool is configured to verify extended attributes.
Check to see if Advanced Intrusion Detection Environment (AIDE) is installed on the system with the following command:
# sudo zypper if aide | grep "Installed"
Installed: Yes
If AIDE is not installed, ask the System Administrator how file integrity checks are performed on the system.
If there is no application installed to perform integrity checks, this is a finding.
Note: AIDE is highly configurable at install time. These commands assume the "aide.conf" file is under the "/etc" directory.
Use the following command to determine if the file is in another location:
# find / -name aide.conf
Check the "aide.conf" file to determine if the "xattrs" rule has been added to the rule list being applied to the files and directories selection lists.
An example rule that includes the "acl" rule follows:
All= p+i+n+u+g+s+m+S+sha512+acl+xattrs+selinux
/bin All # apply the custom rule to the files in bin
/sbin All # apply the same custom rule to the files in sbin
If the "acl" rule is not being used on all selection lines in the "/etc/aide.conf" file, or extended attributes are not being checked by another file integrity tool, this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-010530The SUSE operating system file integrity tool must be configured to verify extended attributes.<VulnDiscussion>Extended attributes in file systems are used to contain arbitrary data and file metadata with security implications.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system file integrity tool to check file and directory extended attributes.
If AIDE is installed, ensure the "xattrs" rule is present on all file and directory selection lists.Verify that the SUSE operating system file integrity tool is configured to verify extended attributes.
Check to see if Advanced Intrusion Detection Environment (AIDE) is installed on the system with the following command:
# sudo zypper if aide | grep "Installed"
Installed: Yes
If AIDE is not installed, ask the System Administrator how file integrity checks are performed on the system.
If there is no application installed to perform integrity checks, this is a finding.
Note: AIDE is highly configurable at install time. These commands assume the "aide.conf" file is under the "/etc" directory.
Use the following command to determine if the file is in another location:
# find / -name aide.conf
Check the "aide.conf" file to determine if the "xattrs" rule has been added to the rule list being applied to the files and directories selection lists.
An example rule that includes the "xattrs" rule follows:
All= p+i+n+u+g+s+m+S+sha512+acl+xattrs+selinux
/bin All # apply the custom rule to the files in bin
/sbin All # apply the same custom rule to the files in sbin
If the "xattrs" rule is not being used on all selection lines in the "/etc/aide.conf" file, or extended attributes are not being checked by another file integrity tool, this is a finding.SRG-OS-000278-GPOS-00108<GroupDescription></GroupDescription>SLES-12-010540The SUSE operating system file integrity tool must be configured to protect the integrity of the audit tools.<VulnDiscussion>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.
Audit tools include but are not limited to vendor-provided and open-source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.
It is not uncommon for attackers to replace the audit tools or inject code into the existing tools to provide the capability to hide or erase system activity from the audit logs.
To address this risk, audit tools must be cryptographically signed 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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-001496Configure the SUSE operating system file integrity tool to protect the integrity of the audit tools.
Add or update the following lines to "/etc/aide.conf" to protect the integrity of the audit tools:
# audit tools
/usr/sbin/auditctl p+i+n+u+g+s+b+acl+selinux+xattrs+sha512
/usr/sbin/auditd p+i+n+u+g+s+b+acl+selinux+xattrs+sha512
/usr/sbin/ausearch p+i+n+u+g+s+b+acl+selinux+xattrs+sha512
/usr/sbin/aureport p+i+n+u+g+s+b+acl+selinux+xattrs+sha512
/usr/sbin/autrace p+i+n+u+g+s+b+acl+selinux+xattrs+sha512
/usr/sbin/audispd p+i+n+u+g+s+b+acl+selinux+xattrs+sha512
/usr/sbin/augenrules p+i+n+u+g+s+b+acl+selinux+xattrs+sha512Verify that the SUSE operating system file integrity tool is configured to protect the integrity of the audit tools.
Check that AIDE is properly configured to protect the integrity of the audit tools by running the following command:
# sudo cat /etc/aide.conf | grep /usr/sbin/au
/usr/sbin/auditctl p+i+n+u+g+s+b+acl+selinux+xattrs+sha512
/usr/sbin/auditd p+i+n+u+g+s+b+acl+selinux+xattrs+sha512
/usr/sbin/ausearch p+i+n+u+g+s+b+acl+selinux+xattrs+sha512
/usr/sbin/aureport p+i+n+u+g+s+b+acl+selinux+xattrs+sha512
/usr/sbin/autrace p+i+n+u+g+s+b+acl+selinux+xattrs+sha512
/usr/sbin/audispd p+i+n+u+g+s+b+acl+selinux+xattrs+sha512
/usr/sbin/augenrules p+i+n+u+g+s+b+acl+selinux+xattrs+sha512
If AIDE is configured properly to protect the integrity of the audit tools, all lines listed above will be returned from the command.
If one or more lines are missing, this is a finding.SRG-OS-000366-GPOS-00153<GroupDescription></GroupDescription>SLES-12-010550The SUSE operating system tool zypper must have gpgcheck enabled.<VulnDiscussion>Changes to any software components can have significant effects on the overall security of the SUSE operating system. This requirement ensures the software has not been tampered with and has been provided by a trusted vendor.
Accordingly, patches, service packs, device drivers, or SUSE operating system components must be signed with a certificate recognized and approved by the organization.
Verifying the authenticity of the software prior to installation validates the integrity of the patch or upgrade received from a vendor. This ensures the software has not been tampered with and that it has been provided by a trusted vendor. Self-signed certificates are disallowed by this requirement. The SUSE operating system should not have to verify the software again. This requirement does not mandate DoD certificates for this purpose; however, the certificate used to verify the software must be from an approved Certification Authority (CA).</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-001749Configure that the SUSE operating system tool zypper to enable pgpcheck by editing or adding the following line to "/etc/zypp/zypp.conf":
gpgcheck = 1Verify that the SUSE operating system tool zypper has pgpcheck enabled.
Check that zypper has gpgcheck enabled with the following command:
# cat /etc/zypp/zypp.conf | grep -i gpgcheck
gpgcheck = 1
If "gpgcheck" is set to "0", "off", "no", or "false", this is a finding.SRG-OS-000437-GPOS-00194<GroupDescription></GroupDescription>SLES-12-010570The SUSE operating system must remove all outdated software components after updated versions have been installed.<VulnDiscussion>Previous versions of software components that are not removed from the information system after updates have been installed may be exploited by adversaries. Some information technology products may remove older versions of software automatically from the information system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-002617Configure the SUSE operating system to remove all outdated software components after an update by editing the following line in "/etc/zypp/zypp.conf" to match the one provided below:
solver.upgradeRemoveDroppedPackages = trueVerify the SUSE operating system removes all outdated software components after updated version have been installed by running the following command:
# grep -i upgraderemovedroppedpackages /etc/zypp/zypp.conf
solver.upgradeRemoveDroppedPackages = true
If "solver.upgradeRemoveDroppedPackages" is commented out, is set to "false", or is missing completely, this is a finding.SRG-OS-000378-GPOS-00163<GroupDescription></GroupDescription>SLES-12-010580The SUSE operating system must disable the USB mass storage kernel module.<VulnDiscussion>Without identifying devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity.
Peripherals include but are not limited to such devices as flash drives, external storage, and printers.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-001958Configure the SUSE operating system to prevent USB mass storage devices from automounting when connected to the host.
Add or update the following line to the "/etc/modprobe.d/50-blacklist.conf" file:
blacklist usb-storageVerify the SUSE operating system does not automount USB mass storage devices when connected to the host.
Check that "usb-storage" is blacklisted in the "/etc/modprobe.d/50-blacklist.conf" file with the following command:
# grep usb-storage /etc/modprobe.d/50-blacklist.conf
blacklist usb-storage
If nothing is output from the command, this is a finding.SRG-OS-000114-GPOS-00059<GroupDescription></GroupDescription>SLES-12-010590The SUSE operating system must disable the file system automounter unless required.<VulnDiscussion>Automatically mounting file systems permits easy introduction of unknown devices, thereby facilitating malicious activity.
Satisfies: SRG-OS-000114-GPOS-00059, SRG-OS-000378-GPOS-00163, SRG-OS-000480-GPOS-00227</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366CCI-000778CCI-001958Configure the SUSE operating system to disable the ability to automount devices.
Turn off the automount service with the following command:
# systemctl stop autofs
# systemctl disable autofs
If "autofs" is required for Network File System (NFS), it must be documented with the ISSO.Verify the SUSE operating system disables the ability to automount devices.
Check to see if automounter service is active with the following command:
# systemctl status autofs
autofs.service - Automounts filesystems on demand
Loaded: loaded (/usr/lib/systemd/system/autofs.service; disabled)
Active: inactive (dead)
If the "autofs" status is set to "active" and is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.SRG-OS-000312-GPOS-00122<GroupDescription></GroupDescription>SLES-12-010600The SUSE operating system Apparmor tool must be configured to control whitelisted applications and user home directory access control.<VulnDiscussion>Using a whitelist provides a configuration management method for allowing the execution of only authorized software. Using only authorized software decreases risk by limiting the number of potential vulnerabilities.
The organization must identify authorized software programs and permit execution of authorized software by adding each authorized program to the "pam_apparmor" exception policy. The process used to identify software programs that are authorized to execute on organizational information systems is commonly referred to as whitelisting.
Verification of whitelisted software occurs prior to execution or at system startup.
Users' home directories/folders may contain information of a sensitive nature. Nonprivileged users should coordinate any sharing of information with a System Administrator (SA) through shared resources.
Apparmor can confine users to their home directory, not allowing them to make any changes outside of their own home directories. Confining users to their home directory will minimize the risk of sharing information.
Satisfies: SRG-OS-000312-GPOS-00122, SRG-OS-000312-GPOS-00123SRG-OS-000312-GPOS-00124, SRG-OS-000324-GPOS-00125, SRG-OS-000326-GPOS-00126, SRG-OS-000370-GPOS-00155, SRG-OS-000480-GPOS-00230</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-001774CCI-002165CCI-002233CCI-002235Configure the SUSE operating system to blacklist all applications by default and permit by whitelist.
Install "pam_apparmor" (if it is not installed) with the following command:
# sudo zypper in pam_apparmor
Enable/activate "Apparmor" (if it is not already active) with the following command:
# sudo systemctl enable apparmor.service
Start "Apparmor" with the following command:
# sudo systemctl start apparmor.service
Note: "pam_apparmor" must have properly configured profiles. All configurations will be based on the actual system setup and organization. See the "pam_apparmor" documentation for more information on configuring profiles.Verify that the SUSE operating system Apparmor tool is configured to control whitelisted applications and user home directory access control.
Check that "pam_apparmor" is installed on the system with the following command:
# zypper se pam_apparmor
If the package "pam_apparmor" is not installed on the system, this is a finding.
Check that the "apparmor" daemon is running with the following command:
# systemctl status apparmor.service | grep -i active
Active: active (exited) since Fri 2017-01-13 01:01:01 GMT; 1day 1h ago
If something other than "Active: active" is returned, this is a finding.
Note: "pam_apparmor" must have properly configured profiles. All configurations will be based on the actual system setup and organization. See the "pam_apparmor" documentation for more information on configuring profiles.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-010610The SUSE operating system must disable the x86 Ctrl-Alt-Delete key sequence.<VulnDiscussion>A locally logged-on user who presses Ctrl-Alt-Delete, when at the console, can reboot the system. If accidentally pressed, as could happen in the case of a mixed OS environment, this can create the risk of short-term loss of availability of systems due to unintentional reboot. In the GNOME graphical environment, risk of unintentional reboot from the Ctrl-Alt-Delete sequence is reduced because the user will be prompted before any action is taken.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the system to disable the Ctrl-Alt-Delete sequence for the command line with the following command:
# sudo systemctl mask ctrl-alt-del.target
And reload the daemon to take effect
# sudo systemctl daemon-reload
If GNOME is active on the system, create a database to contain the system-wide setting (if it does not already exist) with the following command:
# cat /etc/dconf/db/local.d/00-disable-CAD
Add the setting to disable the Ctrl-Alt-Delete sequence for GNOME:
[org/gnome/settings-daemon/plugins/media-keys]
logout=''Verify the SUSE operating system is not configured to reboot the system when Ctrl-Alt-Delete is pressed.
Check that the ctrl-alt-del.service is not active with the following command:
# systemctl status ctrl-alt-del.target
reboot.target - Reboot
Loaded: loaded (/usr/lib/systemd/system/reboot.target; disabled)
Active: inactive (dead)
Docs: man:systemd.special(7)
If the ctrl-alt-del.service is active, this is a finding.SRG-OS-000480-GPOS-00228<GroupDescription></GroupDescription>SLES-12-010620The SUSE operating system default permissions must be defined in such a way that all authenticated users can only read and modify their own files.<VulnDiscussion>Setting the most restrictive default permissions ensures that when new accounts are created, they do not have unnecessary access.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system to define the default permissions for all authenticated users in such a way that the users can only read and modify their own files.
Add or edit the "UMASK" parameter in the "/etc/login.defs" file to match the example below:
UMASK 077Verify the SUSE operating system defines default permissions for all authenticated users in such a way that the users can only read and modify their own files.
Check the system default permissions with the following command:
# grep -i "umask" /etc/login.defs
UMASK 077
If the "UMASK" variable is set to "000", the severity is raised to a CAT I, and this is a finding.
If the value of "UMASK" is not set to "077", "UMASK" is commented out, or "UMASK" is missing completely, this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-010630The SUSE operating system must not have unnecessary accounts.<VulnDiscussion>Accounts providing no operational purpose provide additional opportunities for system compromise. Unnecessary accounts include user accounts for individuals not requiring access to the system and application accounts for applications not installed on the system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system so all accounts on the system are assigned to an active system, application, or user account.
Remove accounts that do not support approved system activities or that allow for a normal user to perform administrative-level actions.
Document all authorized accounts on the system.Verify all SUSE operating system accounts are assigned to an active system, application, or user account.
Obtain the list of authorized system accounts from the Information System Security Officer (ISSO).
Check the system accounts on the system with the following command:
# more /etc/passwd
root:x:0:0:root:/root:/bin/bash
...
games:x:12:100:Games account:/var/games:/bin/bash
Accounts such as "games" and "gopher" are not authorized accounts as they do not support authorized system functions.
If the accounts on the system do not match the provided documentation, this is a finding.SRG-OS-000104-GPOS-00051<GroupDescription></GroupDescription>SLES-12-010640The SUSE operating system must not have duplicate User IDs (UIDs) for interactive users.<VulnDiscussion>To assure accountability and prevent unauthenticated access, interactive users must be identified and authenticated to prevent potential misuse and compromise of the system.
Interactive users include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors). Interactive users (and processes acting on behalf of users) must be uniquely identified and authenticated to all accesses, except for the following:
1) Accesses explicitly identified and documented by the organization. Organizations document specific user actions that can be performed on the information system without identification or authentication; and
2) Accesses that occur through authorized use of group authenticators without individual authentication. Organizations may require unique identification of individuals in group accounts (e.g., shared privilege accounts) or for detailed accountability of individual activity.
Satisfies: SRG-OS-000104-GPOS-00051, SRG-OS-000121-GPOS-00062</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000764CCI-000804Configure the SUSE operating system to contain no duplicate UIDs for interactive users.
Edit the file "/etc/passwd" and provide each interactive user account that has a duplicate UID with a unique UID.Verify the SUSE operating system contains no duplicate UIDs for interactive users.
Check that the SUSE operating system contains no duplicate UIDs for interactive users by running the following command:
# awk -F ":" 'list[$3]++{print $1, $3}' /etc/passwd
If output is produced, this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-010650The SUSE operating system root account must be the only account having unrestricted access to the system.<VulnDiscussion>If an account other than root also has a User Identifier (UID) of "0", it has root authority, giving that account unrestricted access to the entire SUSE operating system. Multiple accounts with a UID of "0" afford an opportunity for potential intruders to guess a password for a privileged account.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Change the UID of any account on the SUSE operating system, other than the root account, that has a UID of "0".
If the account is associated with system commands or applications, the UID should be changed to one greater than "0" but less than "1000". Otherwise, assign a UID of greater than "1000" that has not already been assigned.Verify that the SUSE operating system root account is the only account with unrestricted access to the system.
Check the system for duplicate UID "0" assignments with the following command:
# awk -F: '$3 == 0 {print $1}' /etc/passwd
root
If any accounts other than root have a UID of "0", this is a finding.SRG-OS-000380-GPOS-00165<GroupDescription></GroupDescription>SLES-12-010660Temporary passwords for SUSE operating system logons must require an immediate change to a permanent password.<VulnDiscussion>Without providing this capability, an account may be created without a password. Nonrepudiation cannot be guaranteed once an account is created if a user is not forced to change the temporary password upon initial logon.
Temporary passwords are typically used to allow access when new accounts are created or passwords are changed. It is common practice for administrators to create temporary passwords for user accounts that allow the users to log on, yet force them to change the password once they have successfully authenticated.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-002041Configure the SUSE operating system to allow the use of a temporary password for system logons with an immediate change to a permanent password.
Using one of the acceptable methods listed below, force a user to change their password on their next logon by replacing "[UserName]" in the one of the following commands:
# chage -d 0 [UserName]
# passwd -e [UserName]Verify that a policy exists that ensures when a user is created, it is creating using a method that forces a user to change their password upon their next login.
If a policy does not exist, then this is a finding.SRG-OS-000383-GPOS-00166<GroupDescription></GroupDescription>SLES-12-010670If Network Security Services (NSS) is being used by the SUSE operating system it must prohibit the use of cached authentications after one day.<VulnDiscussion>If cached authentication information is out of date, the validity of the authentication information may be questionable.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-002007Configure NSS, if used by the SUSE operating system, to prohibit the use of cached authentications after one day.
Add or change the following line in "/etc/sssd/sssd.conf" just below the line "[nss]":
memcache_timeout = 86400If Network Security Services (NSS) is being used by the SUSE operating system verify that it prohibits the use of cached authentications after one day.
Check that cached authentications cannot be used after one day with the following command:
# sudo grep -i "memcache_timeout" /etc/sssd/sssd.conf
memcache_timeout = 86400
If "memcache_timeout" has a value greater than "86400", or is missing, this is a finding.SRG-OS-000383-GPOS-00166<GroupDescription></GroupDescription>SLES-12-010680The SUSE operating system must configure the Linux Pluggable Authentication Modules (PAM) to prohibit the use of cached offline authentications after one day.<VulnDiscussion>If cached authentication information is out of date, the validity of the authentication information may be questionable.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-002007Configure the SUSE operating system PAM to prohibit the use of cached authentications after one day.
Add or change the following line in "/etc/sssd/sssd.conf" just below the line "[pam]":
offline_credentials_expiration = 1Verify that the SUSE operating system Pluggable Authentication Modules (PAM) prohibits the use of cached off line authentications after one day.
Check that cached off line authentications cannot be used after one day with the following command:
# sudo grep "offline_credentials_expiration" /etc/sssd/sssd.conf
offline_credentials_expiration = 1
If "offline_credentials_expiration" is not set to a value of "1", this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-010690All SUSE operating system files and directories must have a valid owner.<VulnDiscussion>Unowned files and directories may be unintentionally inherited if a user is assigned the same User Identifier (UID) as the UID of the unowned files.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-002165Either remove all files and directories from the SUSE operating system that do not have a valid user, or assign a valid user to all unowned files and directories on the system with the "chown" command:
# sudo chown <user> <file>Verify that all SUSE operating system files and directories on the system have a valid owner.
Check the owner of all files and directories with the following command:
Note: The value after -fstype must be replaced with the filesystem type. XFS is used as an example.
# find / -fstype xfs -nouser
If any files on the system do not have an assigned owner, this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-010700All SUSE operating system files and directories must have a valid group owner.<VulnDiscussion>Files without a valid group owner may be unintentionally inherited if a group is assigned the same Group Identifier (GID) as the GID of the files without a valid group owner.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-002165Either remove all files and directories from the SUSE operating system that do not have a valid group, or assign a valid group to all files and directories on the system with the "chgrp" command:
# sudo chgrp <group> <file>Verify all SUSE operating system files and directories on the system have a valid group.
Check the owner of all files and directories with the following command:
Note: The value after -fstype must be replaced with the filesystem type. XFS is used as an example.
# find / -fstype xfs -nogroup
If any files on the system do not have an assigned group, this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-010710All SUSE operating system local interactive users must have a home directory assigned in the /etc/passwd file.<VulnDiscussion>If local interactive users are not assigned a valid home directory, there is no place for the storage and control of files they should own.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Assign home directories to all SUSE operating system local interactive users that currently do not have a home directory assigned.
Assign a home directory to users via the usermod command:
# usermod -d /home/smithj smithjVerify SUSE operating system local interactive users on the system have a home directory assigned.
Check for missing local interactive user home directories with the following command:
# sudo pwck -r
user 'smithj': directory '/home/smithj' does not exist
Ask the System Administrator (SA) if any users found without home directories are local interactive users. If the SA is unable to provide a response, check for users with a User Identifier (UID) of 1000 or greater with the following command:
# sudo cut -d: -f 1,3 /etc/passwd | egrep ":[1-4][0-9]{2}$|:[0-9]{1,2}$"
If any interactive users do not have a home directory assigned, this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-010720All SUSE operating system local interactive user accounts, upon creation, must be assigned a home directory.<VulnDiscussion>If local interactive users are not assigned a valid home directory, there is no place for the storage and control of files they should own.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system to assign home directories to all new local interactive users by setting the "CREATE_HOME" parameter in "/etc/login.defs" to "yes" as follows.
CREATE_HOME yesVerify all SUSE operating system local interactive users on the system are assigned a home directory upon creation.
Check to see if the system is configured to create home directories for local interactive users with the following command:
# grep -i create_home /etc/login.defs
CREATE_HOME yes
If the value for "CREATE_HOME" parameter is not set to "yes", the line is missing, or the line is commented out, this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-010730All SUSE operating system local interactive user home directories defined in the /etc/passwd file must exist.<VulnDiscussion>If a local interactive user has a home directory defined that does not exist, the user may be given access to the / directory as the current working directory upon logon. This could create a Denial of Service because the user would not be able to access their logon configuration files, and it may give them visibility to system files they normally would not be able to access.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Create home directories to all SUSE operating system local interactive users that currently do not have a home directory assigned. Use the following commands to create the user home directory assigned in "/etc/ passwd":
Note: The example will be for the user smithj, who has a home directory of "/home/smithj", a UID of "smithj", and a Group Identifier (GID) of "users assigned" in "/etc/passwd".
# mkdir /home/smithj
# chown smithj /home/smithj
# chgrp users /home/smithj
# chmod 0750 /home/smithjVerify the assigned home directory of all SUSE operating system local interactive users on the system exists.
Check the home directory assignment for all local interactive non-privileged users on the system with the following command:
# egrep ':[1-9][0-9]{3,4}' /etc/passwd | cut -d: -f1,6
smithj /home/smithj
Note: This may miss interactive users that have been assigned a privileged UID. Evidence of interactive use may be obtained from a number of log files containing system logon information.
Check that all referenced home directories exist with the following command:
# pwck -r
user 'smithj': directory '/home/smithj' does not exist
If any home directories referenced in "/etc/passwd" are returned as not defined, this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-010740All SUSE operating system local interactive user home directories must have mode 0750 or less permissive.<VulnDiscussion>Excessive permissions on local interactive user home directories may allow unauthorized access to user files by other users.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Change the mode of SUSE operating system local interactive user's home directories to "0750". To change the mode of a local interactive user's home directory, use the following command:
Note: The example will be for the user "smithj".
# chmod 0750 /home/smithjVerify the assigned home directory of all SUSE operating system local interactive users has a mode of "0750" or less permissive.
Check the home directory assignment for all non-privileged users on the system with the following command:
Note: This may miss interactive users that have been assigned a privileged User Identifier (UID). Evidence of interactive use may be obtained from a number of log files containing system logon information.
# ls -ld $(egrep ':[0-9]{4}' /etc/passwd | cut -d: -f6)
-rwxr-x--- 1 smithj users 18 Mar 5 17:06 /home/smithj
If home directories referenced in "/etc/passwd" do not have a mode of "0750" or less permissive, this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-010750All SUSE operating system local interactive user home directories must be group-owned by the home directory owners primary group.<VulnDiscussion>If the Group Identifier (GID) of a local interactive user’s home directory is not the same as the primary GID of the user, this would allow unauthorized access to the user’s files, and users that share the same group may not be able to access files that they legitimately should.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Change the group owner of a SUSE operating system local interactive user's home directory to the group found in "/etc/passwd". To change the group owner of a local interactive user's home directory, use the following command:
Note: The example will be for the user "smithj", who has a home directory of "/home/smithj", and has a primary group of users.
# chgrp users /home/smithjVerify the assigned home directory of all SUSE operating system local interactive users is group-owned by that user's primary GID.
Check the home directory assignment for all non-privileged users on the system with the following command:
Note: This may miss local interactive users that have been assigned a privileged UID. Evidence of interactive use may be obtained from a number of log files containing system logon information. The returned directory "/home/smithj" is used as an example.
# egrep ':[0-9]{4}' /etc/passwd | cut -d: -f4,6
250:/home/smithj
Check the user's primary group with the following command:
# grep users /etc/group
users:x:250:smithj,jonesj,jacksons
If the user home directory referenced in "/etc/passwd" is not group-owned by that user's primary GID, this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-010760All SUSE operating system local initialization files must have mode 0740 or less permissive.<VulnDiscussion>Local initialization files are used to configure the user's shell environment upon logon. Malicious modification of these files could compromise accounts upon logon.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Set the mode of SUSE operating system local initialization files to "0740" with the following command:
Note: The example will be for the smithj user, who has a home directory of "/home/smithj".
# chmod 0740 /home/smithj/.<INIT_FILE>Verify that all SUSE operating system local initialization files have a mode of "0740" or less permissive.
Check the mode on all SUSE operating system local initialization files with the following command:
Note: The example will be for the user "smithj", who has a home directory of "/home/smithj".
# ls -al /home/smithj/.* | more
-rwxr-xr-x 1 smithj users 896 Mar 10 2011 .profile
-rwxr-xr-x 1 smithj users 497 Jan 6 2007 .login
-rwxr-xr-x 1 smithj users 886 Jan 6 2007 .something
If any local initialization files have a mode more permissive than "0740", this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-010770All SUSE operating system local interactive user initialization files executable search paths must contain only paths that resolve to the users home directory.<VulnDiscussion>The executable search path (typically the PATH environment variable) contains a list of directories for the shell to search to find executables. If this path includes the current working directory (other than the user's home directory), executables in these directories may be executed instead of system commands. This variable is formatted as a colon-separated list of directories. If there is an empty entry, such as a leading or trailing colon or two consecutive colons, this is interpreted as the current working directory. If deviations from the default system search path for the local interactive user are required, they must be documented with the Information System Security Officer (ISSO).</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Edit the SUSE operating system local interactive user initialization files to change any PATH variable statements for executables that reference directories other than their home directory. If a local interactive user requires path variables to reference a directory owned by the application, it must be documented with the ISSO.Verify that all SUSE operating system local interactive user initialization files executable search path statements do not contain statements that will reference a working directory other than the user's home directory.
Check the executable search path statement for all operating system local interactive user initialization files in the users' home directory with the following commands:
Note: The example will be for the user "smithj", who has a home directory of "/home/smithj".
# sudo grep -i path /home/smithj/.*
/home/smithj/.bash_profile:PATH=$PATH:$HOME/.local/bin:$HOME/bin
/home/smithj/.bash_profile:export PATH
If any local interactive user initialization files have executable search path statements that include directories outside of their home directory, and the additional path statements are not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-010780All SUSE operating system local initialization files must not execute world-writable programs.<VulnDiscussion>If user start-up files execute world-writable programs, especially in unprotected directories, they could be maliciously modified to destroy user files or otherwise compromise the system at the user level. If the system is compromised at the user level, it is easier to elevate privileges to eventually compromise the system at the root and network level.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Remove the world-writable permission of files referenced by SUSE operating system local initialization scripts, or remove the references to these files in the local initialization scripts.Verify that SUSE operating system local initialization files do not execute world-writable programs.
For each home directory on the system make a list of files referenced within any local initialization script. Show the mode for each file and its parent directory.
# FILES=".bashrc .bash_login .bash_logout .bash_profile .cshrc .kshrc .login .logout .profile .tcshrc .env .dtprofile .dispatch .emacs .exrc";
# for HOMEDIR in `cut -d: -f6 /etc/passwd|sort|uniq`;do for INIFILE in $FILES;do REFLIST=`egrep " [\"~]?/" ${HOMEDIR}/${INIFILE} 2>/dev/null|sed "s/.*\([~ \"]\/[\.0-9A-Za-z_\/\-]*\).*/\1/"`;for REFFILE in $REFLIST;do FULLREF=`echo $REFFILE|sed "s:\~:${HOMEDIR}:g"|sed "s:^\s*::g"`;dirname $FULLREF|xargs stat -c "dir:%a:%n";stat -c "file:%:%n" $FULLREF;done;done;
done|sort|uniq
If any local initialization file executes a world-writable program or script or a script from a world-writable directory, this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-010790SUSE operating system file systems that contain user home directories must be mounted to prevent files with the setuid and setgid bit set from being executed.<VulnDiscussion>The "nosuid" mount option causes the system to not execute setuid and setgid files with owner privileges. This option must be used for mounting any file system not containing approved setuid and setguid files. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system "/etc/fstab" file to use the "nosuid" option on file systems that contain user home directories for interactive users.
Re-mount the filesystems.
# mount -o remount /homeVerify that SUSE operating system file systems that contain user home directories are mounted with the "nosuid" option.
Print the currently active file system mount options of the file system(s) that contain the user home directories with the following command:
# for X in `egrep "^[^:]{1,}:x:[1-4][0-9]{3}:" /etc/passwd | cut -d: -f6`; do findmnt -nkT $X; done | sort -r
/home /dev/mapper/system-home ext4 rw,nosuid,relatime,data=ordered
If a file system containing user home directories is not mounted with the FSTYPE OPTION nosuid, this is a finding.
Note: If a separate file system has not been created for the user home directories (user home directories are mounted under "/"), this is not a finding as the "nosuid" option cannot be used on the "/" system.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-010800SUSE operating system file systems that are used with removable media must be mounted to prevent files with the setuid and setgid bit set from being executed.<VulnDiscussion>The "nosuid" mount option causes the system to not execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system "/etc/fstab" file to use the "nosuid" option on file systems that are associated with removable media.Verify that SUSE operating system file systems that are used for removable media are mounted with the "nouid" option.
Check the file systems that are mounted at boot time with the following command:
# more /etc/fstab
UUID=2bc871e4-e2a3-4f29-9ece-3be60c835222 /mnt/usbflash vfat noauto,owner,ro,nosuid 0 0
If a file system found in "/etc/fstab" refers to removable media and it does not have the "nosuid" option set, this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-010810SUSE operating system file systems that are being imported via Network File System (NFS) must be mounted to prevent files with the setuid and setgid bit set from being executed.<VulnDiscussion>The "nosuid" mount option causes the system to not execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system "/etc/fstab" file to use the "nosuid" option on file systems that are being exported via NFS.Verify SUSE operating system file systems that are being NFS exported are mounted with the "nosuid" option.
Find the file system(s) that contain the directories being exported with the following command:
# more /etc/fstab | grep nfs
UUID=e06097bb-cfcd-437b-9e4d-a691f5662a7d /store nfs rw,nosuid 0 0
If a file system found in "/etc/fstab" refers to NFS and it does not have the "nosuid" option set, this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-010820SUSE operating system file systems that are being imported via Network File System (NFS) must be mounted to prevent binary files from being executed.<VulnDiscussion>The "noexec" mount option causes the system to not execute binary files. This option must be used for mounting any file system not containing approved binary files as they may be incompatible. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system "/etc/fstab" file to use the "noexec" option on file systems that are being exported via NFS.Verify the SUSE operating system file systems that are being NFS exported are mounted with the "noexec" option.
Find the file system(s) that contain the directories being exported with the following command:
# more /etc/fstab | grep nfs
UUID=e06097bb-cfcd-437b-9e4d-a691f5662a7d /store nfs rw,noexec 0 0
If a file system found in "/etc/fstab" refers to NFS and it does not have the "noexec" option set, and use of NFS exported binaries is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-010830All SUSE operating system world-writable directories must be group-owned by root, sys, bin, or an application group.<VulnDiscussion>If a world-writable directory has the sticky bit set and is not group-owned by a privileged Group Identifier (GID), unauthorized users may be able to modify files created by others.
The only authorized public directories are those temporary directories supplied with the system or those designed to be temporary file repositories. The setting is normally reserved for directories used by the system and by users for temporary file storage, (e.g., /tmp), and for directories requiring global read/write access.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Change the group of the SUSE operating system world-writable directories to root with the following command:
# chgrp root <directory>Verify all SUSE operating system world-writable directories are group-owned by root, sys, bin, or an application group.
Check the system for world-writable directories with the following command:
Note: The value after -fstype must be replaced with the filesystem type. XFS is used as an example.
# find / -xdev -perm -002 -type d -fstype xfs -exec ls -lLd {} \;
drwxrwxrwt. 2 root root 40 Aug 26 13:07 /dev/mqueue
drwxrwxrwt. 2 root root 220 Aug 26 13:23 /dev/shm
drwxrwxrwt. 14 root root 4096 Aug 26 13:29 /tmp
If any world-writable directories are not owned by root, sys, bin, or an application group associated with the directory, this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-010840SUSE operating system kernel core dumps must be disabled unless needed.<VulnDiscussion>Kernel core dumps may contain the full contents of system memory at the time of the crash. Kernel core dumps may consume a considerable amount of disk space and may result in denial of service by exhausting the available space on the target file system partition.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366If SUSE operating system kernel core dumps are not required, disable the "kdump" service with the following command:
# systemctl disable kdump.service
If kernel core dumps are required, document the need with the ISSO.Verify that SUSE operating system kernel core dumps are disabled unless needed.
Check the status of the "kdump" service with the following command:
# systemctl status kdump.service
Loaded: not-found (Reason: No such file or directory)
Active: inactive (dead)
If the "kdump" service is active, ask the System Administrator if the use of the service is required and documented with the Information System Security Officer (ISSO).
If the service is active and is not documented, this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-010850A separate file system must be used for SUSE operating system user home directories (such as /home or an equivalent).<VulnDiscussion>The use of separate file systems for different paths can protect the system from failures resulting from a file system becoming full or failing.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Create a separate file system/partition for SUSE operating system non-privileged local interactive user home directories.
Migrate the non-privileged local interactive user home directories onto the separate file system/partition.Verify that a separate file system/partition has been created for SUSE operating system non-privileged local interactive user home directories.
Check the home directory assignment for all non-privileged users (those with a UID greater than 1000) on the system with the following command:
# cut -d: -f 1,3,6,7 /etc/passwd | egrep ":[1-4][0-9]{3}" | tr ":" "\t"
adamsj 1002 /home/adamsj /bin/bash
jacksonm 1003 /home/jacksonm /bin/bash
smithj 1001 /home/smithj /bin/bash
The output of the command will give the directory/partition that contains the home directories for the non-privileged users on the system (in this example, /home) and user's shell. All accounts with a valid shell (such as /bin/bash) are considered interactive users.
Check that a file system/partition has been created for the non-privileged interactive users with the following command:
Note: The partition of /home is used in the example.
# grep /home /etc/fstab
UUID=333ada18 /home ext4 noatime,nobarrier,nodev 1 2
If a separate entry for the file system/partition that contains the non-privileged interactive users' home directories does not exist, this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-010860The SUSE operating system must use a separate file system for /var.<VulnDiscussion>The use of separate file systems for different paths can protect the system from failures resulting from a file system becoming full or failing.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Create a separate file system/partition on the SUSE operating system for "/var".
Migrate "/var" onto the separate file system/partition.Verify that the SUSE operating system has a separate file system/partition for "/var".
Check that a file system/partition has been created for "/var" with the following command:
# grep /var /etc/fstab
UUID=c274f65f /var ext4 noatime,nobarrier 1 2
If a separate entry for "/var" is not in use, this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-010870The SUSE operating system must use a separate file system for the system audit data path.<VulnDiscussion>The use of separate file systems for different paths can protect the system from failures resulting from a file system becoming full or failing.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Migrate the SUSE operating system audit data path onto a separate file system.Verify that the SUSE operating system has a separate file system/partition for the system audit data path.
Check that a file system/partition has been created for the system audit data path with the following command:
Note: "/var/log/audit" is used as the example as it is a common location.
#grep /var/log/audit /etc/fstab
UUID=3645951a /var/log/audit ext4 defaults 1 2
If a separate entry for the system audit data path (in this example the "/var/log/audit" path) does not exist, ask the System Administrator if the system audit logs are being written to a different file system/partition on the system and then grep for that file system/partition.
If a separate file system/partition does not exist for the system audit data path, this is a finding.SRG-OS-000259-GPOS-00100<GroupDescription></GroupDescription>SLES-12-010880SUSE operating system commands and libraries must have the proper permissions to protect from unauthorized access.<VulnDiscussion>If the SUSE operating system were to allow any user to make changes to software libraries, those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.
This requirement applies to SUSE operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs that execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components to initiate changes, including upgrades and modifications.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-001499Configure the SUSE operating system to prevent unauthorized users from accessing system command and library files.
Set the correct permissions with the following command:
# sudo chkstat --set --systemVerify that the SUSE operating system prevents unauthorized users from accessing system command and library files.
Check that all of the audit information files and folders have the correct permissions with the following command:
# sudo chkstat --warn --system
If the command returns any output, this is a finding.SRG-OS-000206-GPOS-00084<GroupDescription></GroupDescription>SLES-12-010890The SUSE operating system must prevent unauthorized users from accessing system error messages.<VulnDiscussion>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 SUSE operating system or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives.
The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-001314Configure the SUSE operating system to prevent unauthorized users from accessing system error messages.
Add or update the following rules in "/etc/permissions.local":
/var/log/messages root:root 640
Set the correct permissions with the following command:
# sudo chkstat --set --systemVerify that the SUSE operating system prevents unauthorized users from accessing system error messages.
Check that "permissions.local" file contains the correct permissions rules with the following command:
# grep -i messages /etc/permissions.local
/var/log/messages root:root 640
If the command does not return any output, this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-010910The SUSE operating system must be configured to not overwrite Pluggable Authentication Modules (PAM) configuration on package changes.<VulnDiscussion>"pam-config" is a command line utility that automatically generates a system PAM configuration as packages are installed, updated or removed from the system. "pam-config" removes configurations for PAM modules and parameters that it does not know about. It may render ineffective PAM configuration by the system administrator and thus impact system security.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Remove the SUSE operating system soft links for the PAM configuration files with the following command:
# find /etc/pam.d/ -type l -iname "common-*" -delete
Copy the PAM configuration files to their static locations:
# for X in /etc/pam.d/common-*-pc; do cp -ivp $X ${X:0:-3}; done
Additional information on the configuration of multifactor authentication on the SUSE operating system can be found at https://www.suse.com/communities/blog/configuring-smart-card-authentication-suse-linux-enterprise/.Verify the SUSE operating system is configured to not overwrite Pluggable Authentication Modules (PAM) configuration on package changes.
Check that soft links between PAM configuration files are removed with the following command:
# find /etc/pam.d/ -type l -iname "common-*"
If any results are returned, this is a finding.SRG-OS-000337-GPOS-00129<GroupDescription></GroupDescription>SLES-12-020000The SUSE operating system must have the auditing package installed.<VulnDiscussion>Without establishing what type of events occurred, the source of events, where events occurred, and the outcome of events, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack.
Audit record content that may be necessary to satisfy this requirement includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked.
Associating event types with detected events in the SUSE operating system audit logs provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured SUSE operating system.
Satisfies: SRG-OS-000337-GPOS-00129, SRG-OS-000348-GPOS-00136, SRG-OS-000349-GPOS-00137, SRG-OS-000350-GPOS-00138, SRG-OS-000351-GPOS-00139, SRG-OS-000352-GPOS-00140, SRG-OS-000353-GPOS-00141, SRG-OS-000354-GPOS-00142, SRG-OS-000358-GPOS-00145, SRG-OS-000359-GPOS-00146, SRG-OS-000365-GPOS-00152, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000172CCI-001814CCI-001875CCI-001877CCI-001878CCI-001879CCI-001880CCI-001881CCI-001882CCI-001889CCI-001914The SUSE operating system auditd package must be installed on the system. If it is not installed, use the following command to install it:
# sudo zypper in auditdVerify the SUSE operating system auditing package is installed.
Check that the "audit" package is installed by performing the following command:
# zypper se audit
i | audit | User Space Tools for 2.6 Kernel Auditing
If the package "audit" is not installed on the system, then this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020010SUSE operating system audit records must contain information to establish what type of events occurred, the source of events, where events occurred, and the outcome of events.<VulnDiscussion>Without establishing what type of events occurred, the source of events, where events occurred, and the outcome of events, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack.
Audit record content that may be necessary to satisfy this requirement includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked.
Associating event types with detected events in the SUSE operating system audit logs provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured SUSE operating system.
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000038-GPOS-00016, SRG-OS-000039-GPOS-00017, SRG-OS-000040-GPOS-00018, SRG-OS-000041-GPOS-00019, SRG-OS-000042-GPOS-00021, SRG-OS-000051-GPOS-00024, SRG-OS-000054-GPOS-00025, SRG-OS-000122-GPOS-00063, SRG-OS-000254-GPOS-00095, SRG-OS-000255-GPOS-00096, SRG-OS-000392-GPOS-00172, SRG-OS-000480-GPOS-00227</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000131CCI-000132CCI-000133CCI-000134CCI-000135CCI-000154CCI-000158CCI-000366CCI-001464CCI-001487CCI-001876CCI-002884Enable the SUSE operating system auditd service by performing the following commands:
# sudo systemctl enable auditd.service
# sudo systemctl start auditd.serviceVerify the SUSE operating system produces audit records.
Check that the SUSE operating system produces audit records by running the following command to determine the current status of the auditd service:
# systemctl status auditd.service
If the service is enabled, the returned message must contain the following text:
Active: active (running)
If the service is not running, this is a finding.SRG-OS-000341-GPOS-00132<GroupDescription></GroupDescription>SLES-12-020020The SUSE operating system must allocate audit record storage capacity to store at least one weeks worth of audit records when audit records are not immediately sent to a central audit record storage facility.<VulnDiscussion>To ensure SUSE operating systems have a sufficient storage capacity in which to write the audit logs, SUSE operating systems need to be able to allocate audit record storage capacity.
The task of allocating audit record storage capacity is usually performed during initial installation of the SUSE operating system.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-001849Allocate enough storage capacity for at least one week's worth of SUSE operating system audit records when audit records are not immediately sent to a central audit record storage facility.
If audit records are stored on a partition made specifically for audit records, use the "YaST2 - Partitioner" program (installation and configuration tool for Linux) to resize the partition with sufficient space to contain one week's worth of audit records.
If audit records are not stored on a partition made specifically for audit records, a new partition with sufficient amount of space will need be to be created. The new partition can be created using the "YaST2 - Partitioner" program on the system.Verify the SUSE operating system allocates audit record storage capacity to store at least one week's worth of audit records when audit records are not immediately sent to a central audit record storage facility.
Determine which partition the audit records are being written to with the following command:
# sudo grep log_file /etc/audit/auditd.conf
log_file = /var/log/audit/audit.log
Check the size of the partition that audit records are written to (with the example being /var/log/audit/) with the following command:
# df -h /var/log/audit/
/dev/sda2 24G 10.4G 13.6G 43% /var/log/audit
If the audit records are not written to a partition made specifically for audit records (/var/log/audit is a separate partition), determine the amount of space being used by other files in the partition with the following command:
#du -sh [audit_partition]
1.8G /var/log/audit
The partition size needed to capture a week's worth of audit records is based on the activity level of the system and the total storage capacity available. In normal circumstances, 10.0 GB of storage space for audit records will be sufficient.
If the audit record partition is not allocated sufficient storage capacity, this is a finding.SRG-OS-000343-GPOS-00134<GroupDescription></GroupDescription>SLES-12-020030The SUSE operating system auditd service must notify the System Administrator (SA) and Information System Security Officer (ISSO) immediately when audit storage capacity is 75 percent full.<VulnDiscussion>If security personnel are not notified immediately when storage volume reaches 75 percent utilization, they are unable to plan for audit record storage capacity expansion.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-001855Edit the SUSE operating system "/etc/audit/auditd.conf" by adding or editing the following line:
space_left = 75Determine if the SUSE operating system auditd is configured to notify the System Administrator (SA) and Information System Security Officer (ISSO) when the audit record storage volume reaches 75 percent of the storage capacity:
# sudo grep space_left /etc/audit/auditd.conf
space_left = 75
If "space_left" is not set to "75", this is a finding.SRG-OS-000046-GPOS-00022<GroupDescription></GroupDescription>SLES-12-020040The Information System Security Officer (ISSO) and System Administrator (SA), at a minimum, must be alerted of a SUSE operating system audit processing failure event.<VulnDiscussion>It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without this notification, the security personnel may be unaware of an impending failure of the audit capability, and system operation may be adversely affected.
Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded.
This requirement applies to each audit data storage repository (i.e., distinct information system component where audit records are stored), the centralized audit storage capacity of organizations (i.e., all audit data storage repositories combined), or both.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000139Configure the auditd service to notify the administrators in the event of a SUSE operating system audit processing failure.
Edit the following line in "/etc/audit/auditd.conf" to ensure that administrators are notified via email for those situations:
action_mail_acct = rootVerify the administrators are notified in the event of a SUSE operating system audit processing failure by inspecting "/etc/audit/auditd.conf".
Check if the system is configured to send email to an account when it needs to notify an administrator with the following command:
sudo grep action_mail /etc/audit/auditd.conf
action_mail_acct = root
If the value of the "action_mail_acct" keyword is not set to "root" and/or other accounts for security personnel, the "action_mail_acct" keyword is missing, or the returned line is commented out, this is a finding.SRG-OS-000046-GPOS-00022<GroupDescription></GroupDescription>SLES-12-020050The Information System Security Officer (ISSO) and System Administrator (SA), at a minimum, must have mail aliases to be notified of a SUSE operating system audit processing failure.<VulnDiscussion>It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without this notification, the security personnel may be unaware of an impending failure of the audit capability, and system operation may be adversely affected.
Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded.
This requirement applies to each audit data storage repository (i.e., distinct information system component where audit records are stored), the centralized audit storage capacity of organizations (i.e., all audit data storage repositories combined), or both.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000139Configure the auditd service to notify the administrators in the event of a SUSE operating system audit processing failure.
Configure "/etc/aliases" to define a value for root (if it does not already exist). Add the following line in "/etc/aliases":
postmaster: rootVerify the administrators are notified in the event of a SUSE operating system audit processing failure by checking that "/etc/aliases" has a defined value for root.
# grep postmaster /etc/aliases
postmaster: root
If the above command does not return a value of "root", this is a finding.SRG-OS-000047-GPOS-00023<GroupDescription></GroupDescription>SLES-12-020060The SUSE operating system audit system must take appropriate action when the audit storage volume is full.<VulnDiscussion>It is critical that when the SUSE operating system is at risk of failing to process audit logs as required, it takes action to mitigate the failure. Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. Responses to audit failure depend on the nature of the failure mode.
When availability is an overriding concern, other approved actions in response to an audit failure are as follows:
1) If the failure was caused by the lack of audit record storage capacity, the SUSE operating system must continue generating audit records if possible (automatically restarting the audit service if necessary), overwriting the oldest audit records in a first-in-first-out manner.
2) If audit records are sent to a centralized collection server and communication with this server is lost or the server fails, the SUSE operating system must queue audit records locally until communication is restored or until the audit records are retrieved manually. Upon restoration of the connection to the centralized collection server, action should be taken to synchronize the local audit data with the collection server.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000140Configure the SUSE operating system to shut down by default upon audit failure (unless availability is an overriding concern).
Add or update the following line (depending on configuration "disk_full_action" can be set to "SYSLOG", "SINGLE", or "HALT" depending on configuration) in "/etc/audit/auditd.conf" file:
disk_full_action = HALTVerify the SUSE operating system takes the appropriate action when the audit storage volume is full.
Check that the SUSE operating system takes the appropriate action when the audit storage volume is full with the following command:
# sudo grep disk_full_action /etc/audit/auditd.conf
disk_full_action = SYSLOG
If the value of the "disk_full_action" option is not "SYSLOG", "SINGLE", or "HALT", or the line is commented out, this is a finding.SRG-OS-000342-GPOS-00133<GroupDescription></GroupDescription>SLES-12-020070The audit-audispd-plugins must be installed on the SUSE operating system.<VulnDiscussion>Information stored in one location is vulnerable to accidental or incidental deletion or alteration.
Off-loading is a common process in information systems with limited audit storage capacity.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-001851Install the "audit-audispd-plugins" package on the SUSE operating system by running the following command:
# sudo zypper install audit-audispd-pluginsVerify that the "audit-audispd-plugins" package is installed on the SUSE operating.
Check that the "audit-audispd-plugins" package is installed on the SUSE operating system with the following command:
# zypper se audit-audispd-plugins
If the "audit-audispd-plugins" package is not installed, this is a finding.SRG-OS-000342-GPOS-00133<GroupDescription></GroupDescription>SLES-12-020080The SUSE operating system audit event multiplexor must be configured to use Kerberos.<VulnDiscussion>Information stored in one location is vulnerable to accidental or incidental deletion or alteration.
Allowing devices and users to connect to or from the system without first authenticating them allows untrusted access and can lead to a compromise or attack. Audit events may include sensitive data must be encrypted prior to transmission. Kerberos provides a mechanism to provide both authentication and encryption for audit event records.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-001851Configure the SUSE operating system audit event multiplexor to use Kerberos by editing the "/etc/audisp/audisp-remote.conf" file.
Edit or add the following line to match the text below:
enable_krb5 = yesDetermine if the SUSE operating system audit event multiplexor is configured to use Kerberos by running the following command:
# sudo cat /etc/audisp/audisp-remote.conf | grep enable_krb5
enable_krb5 = yes
If "enable-krb5" is not set to "yes", this is a finding.SRG-OS-000342-GPOS-00133<GroupDescription></GroupDescription>SLES-12-020090Audispd must off-load audit records onto a different system or media from the SUSE operating system being audited.<VulnDiscussion>Information stored in one location is vulnerable to accidental or incidental deletion or alteration.
Off-loading is a common process in information systems with limited audit storage capacity.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-001851Configure the SUSE operating system "/etc/audisp/audisp-remote.conf" file to off-load audit records onto a different system or media by adding or editing the following line with the correct IP address:
remote_server = [IP ADDRESS]Verify "audispd" off-loads audit records onto a different system or media from the SUSE operating system being audited.
Check if "audispd" is configured to off-load audit records onto a different system or media from the SUSE operating system by running the following command:
# sudo cat /etc/audisp/audisp-remote.conf | grep remote_server
remote_server = 192.168.1.101
If "remote_server" is not set to an external server or media, this is a finding.SRG-OS-000479-GPOS-00224<GroupDescription></GroupDescription>SLES-12-020100The SUSE operating system must off-load audit records onto a different system or media from the system being audited.<VulnDiscussion>Information stored in one location is vulnerable to accidental or incidental deletion or alteration.
Off-loading is a common process in information systems with limited audit storage capacity.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-001851Configure the SUSE operating system to take the appropriate action if it cannot off-load audit records to a different system or storage media from the system being audited due to a network failure.
Uncomment the "network_failure_action" option in "/etc/audisp/audisp-remote.conf" and set it to "syslog", "single", or "halt". See the example below:
network_failure_action = syslogVerify what action the audit system takes if it cannot off-load audit records to a different system or storage media from the SUSE operating system being audited.
Check the action that the audit system takes in the event of a network failure with the following command:
# sudo grep -i "network_failure_action" /etc/audisp/audisp-remote.conf
network_failure_action = syslog
If the "network_failure_action" option is not set to "syslog", "single", or "halt" or the line is commented out, this is a finding.SRG-OS-000479-GPOS-00224<GroupDescription></GroupDescription>SLES-12-020110Audispd must take appropriate action when the SUSE operating system audit storage is full.<VulnDiscussion>Information stored in one location is vulnerable to accidental or incidental deletion or alteration.
Off-loading is a common process in information systems with limited audit storage capacity.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-001851Configure the SUSE operating system to take the appropriate action if the audit storage is full.
Add, edit, or uncomment the "disk_full_action" option in "/etc/audisp/audisp-remote.conf". Set it to "syslog", "single" or "halt" as in the example below:
disk_full_action = syslogVerify the audit system off-loads audit records if the SUSE operating system storage volume becomes full.
Check that the records are properly off-loaded to a remote server with the following command:
# sudo grep -i "disk_full_action" /etc/audisp/audisp-remote.conf
disk_full_action = syslog
If "disk_full_action" is not set to "syslog", "single", or "halt" or the line is commented out, this is a finding.SRG-OS-000057-GPOS-00027<GroupDescription></GroupDescription>SLES-12-020120The SUSE operating system must protect audit rules from unauthorized modification.<VulnDiscussion>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.
Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000162CCI-000163CCI-000164Configure the SUSE operating system to protect audit rules from unauthorized modification.
Add or update the following rules in "/etc/permissions.local":
/var/log/audit root:root 600
/var/log/audit/audit.log root:root 600
/etc/audit/audit.rules root:root 640
Set the correct permissions with the following command:
# sudo chkstat --set /etc/permissions.localVerify that the SUSE operating system protects audit rules from unauthorized modification.
Check that "permissions.local" file contains the correct permissions rules with the following command:
# grep -i audit /etc/permissions.local
/var/log/audit root:root 600
/var/log/audit/audit.log root:root 600
/etc/audit/audit.rules root:root 640
If the command does not return any output, this is a finding.
Check that all of the audit information files and folders have the correct permissions with the following command:
# sudo chkstat /etc/permissions.local
If the command returns any output, this is a finding.SRG-OS-000256-GPOS-00097<GroupDescription></GroupDescription>SLES-12-020130The SUSE operating system audit tools must have the proper permissions configured to protect against unauthorized access.<VulnDiscussion>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.
SUSE operating systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys to make access decisions regarding the access to audit tools.
Audit tools include but are not limited to vendor-provided and open-source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.
Satisfies: SRG-OS-000256-GPOS-00097, SRG-OS-000257-GPOS-00098, SRG-OS-000258-GPOS-00099</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-001493CCI-001494CCI-001495Configure the SUSE operating system audit tools to have with proper permissions set in the permissions profile to protect from unauthorized access.
Edit the file "/etc/permissions.local" and insert the following text:
/usr/sbin/audispd root:root 0750
/usr/sbin/auditctl root:root 0750
/usr/sbin/auditd root:root 0750
/usr/sbin/ausearch root:root 0755
/usr/sbin/aureport root:root 0755
/usr/sbin/autrace root:root 0750
/usr/sbin/augenrules root:root 0750Set the correct permissions with the following command:
# sudo chkstat --set /etc/permissions.localVerify that the SUSE operating system audit tools have the proper permissions configured in the permissions profile to protect from unauthorized access.
Check that "permissions.local" file contains the correct permissions rules with the following command:
grep "^/usr/sbin/au" /etc/permissions.local
/usr/sbin/audispd root:root 0750
/usr/sbin/auditctl root:root 0750
/usr/sbin/auditd root:root 0750
/usr/sbin/ausearch root:root 0755
/usr/sbin/aureport root:root 0755
/usr/sbin/autrace root:root 0750
/usr/sbin/augenrules root:root 0750
If the command does not return any output, this is a finding.SRG-OS-000004-GPOS-00004<GroupDescription></GroupDescription>SLES-12-020200The SUSE operating system must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/passwd.<VulnDiscussion>Once an attacker establishes initial access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to simply create a new account. Auditing of account creation mitigates this risk.
To address access requirements, many SUSE operating systems may be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.
Satisfies: SRG-OS-000004-GPOS-00004, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000304-GPOS-00121, SRG-OS-000470-GPOS-00214, SRG-OS-000476-GPOS-00221</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000018CCI-000172CCI-001403CCI-002130CCI-002132Configure the SUSE operating system to generate an audit record when all modifications to the "/etc/passwd" file occur.
Add or update the following rule to "/etc/audit/audit.rules":
-w /etc/passwd -p wa -k account_mod
The audit daemon must be restarted for any changes to take effect.Verify the SUSE operating system generates an audit record when all modifications occur to the "/etc/passwd" file.
Check that the following file is being watched by performing the following command on the system rules in "/etc/audit/audit.rules":
# sudo grep /etc/passwd /etc/audit/audit.rules
-w /etc/passwd -p wa -k account_mod
If the command does not return any output, this is a finding.SRG-OS-000004-GPOS-00004<GroupDescription></GroupDescription>SLES-12-020210The SUSE operating system must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/group.<VulnDiscussion>Once an attacker establishes initial access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to simply create a new account. Auditing of account creation mitigates this risk.
To address access requirements, many SUSE operating systems may be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.
Satisfies: SRG-OS-000004-GPOS-00004, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000476-GPOS-00221</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000018CCI-000172CCI-001403CCI-002130CCI-002132Configure the SUSE operating system to generate an audit record when all modifications to the "/etc/group" file occur.
Add or update the following rule to "/etc/audit/audit.rules":
-w /etc/group -p wa -k account_mod
The audit daemon must be restarted for any changes to take effect.Verify the SUSE operating system generates an audit record when modifications occur to the "/etc/group" file.
Check that the following file is being watched by performing the following command on the system rules in "/etc/audit/audit.rules":
# sudo grep /etc/group /etc/audit/audit.rules
-w /etc/group -p wa -k account_mod
If the command does not return any output, this is a finding.SRG-OS-000004-GPOS-00004<GroupDescription></GroupDescription>SLES-12-020220The SUSE operating system must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/shadow.<VulnDiscussion>Once an attacker establishes initial access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to simply create a new account. Auditing of account creation mitigates this risk.
To address access requirements, many SUSE operating systems may be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.
Satisfies: SRG-OS-000004-GPOS-00004, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000476-GPOS-00221</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000018CCI-000172CCI-001403CCI-002130CCI-002132Configure the SUSE operating system to generate an audit record when all modifications to the "/etc/shadow" file occur.
Add or update the following rule to "/etc/audit/audit.rules":
-w /etc/shadow -p wa -k account_mod
The audit daemon must be restarted for any changes to take effect.Verify the SUSE operating system generates an audit record when modifications occur to the "/etc/shadow" file.
Check that the following file is being watched by performing the following command on the system rules in "/etc/audit/audit.rules":
# sudo grep /etc/shadow /etc/audit/audit.rules
-w /etc/shadow -p wa -k account_mod
If the command does not return a line, or the line is commented out, this is a finding.SRG-OS-000004-GPOS-00004<GroupDescription></GroupDescription>SLES-12-020230The SUSE operating system must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/opasswd.<VulnDiscussion>Once an attacker establishes initial access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to simply create a new account. Auditing of account creation mitigates this risk.
To address access requirements, many SUSE operating systems may be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.
Satisfies: SRG-OS-000004-GPOS-00004, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000476-GPOS-00221</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000018CCI-000172CCI-001403CCI-002130CCI-002132Configure the SUSE operating system to generate an audit record when all modifications to the "/etc/security/opasswd" file occur.
Add or update the following rule to "/etc/audit/audit.rules":
-w /etc/security/opasswd -p wa -k account_mod
The audit daemon must be restarted for any changes to take effect.Verify the SUSE operating system generates an audit record when modifications occur to the "/etc/security/opasswd" file.
Check that the following file is being watched by performing the following command on the system rules in "/etc/audit/audit.rules":
# grep /etc/security/opasswd /etc/audit/audit.rules
-w /etc/security/opasswd -p wa -k account_mod
If the command does not return any output, this is a finding.SRG-OS-000327-GPOS-00127<GroupDescription></GroupDescription>SLES-12-020240The SUSE operating system must generate audit records for all uses of the privileged functions.<VulnDiscussion>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.
Satisfies: SRG-OS-000327-GPOS-00127, SRG-OS-000337-GPOS-00129, SRG-OS-000348-GPOS-00136, SRG-OS-000349-GPOS-00137, SRG-OS-000350-GPOS-00138, SRG-OS-000351-GPOS-00139, SRG-OS-000352-GPOS-00140, SRG-OS-000353-GPOS-00141, SRG-OS-000354-GPOS-00142, SRG-OS-000358-GPOS-00145, SRG-OS-000359-GPOS-00146, SRG-OS-000365-GPOS-00152</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-001814CCI-001875CCI-001877CCI-001878CCI-001879CCI-001880CCI-001881CCI-001882CCI-001889CCI-001914CCI-002234Configure the SUSE operating system to generate an audit record for all uses of privileged functions.
Find relevant setuid programs using the following command once for each local system partition, replacing "[PARTITION]" with each local system partition:
# sudo find [PARTITION] -xdev -type f \( -perm -4000 -o -perm -2000 \) 2>/dev/null
For every setuid program not covered by an audit rule for a subdirectory, add a line for each setuid program in "/etc/audit/audit.rules", replacing "[SETUID_FILE_PATH]" with the full path to the setuid program from the list above:
-w [SETUID_FILE_PATH] -p wa -k privilege_functionVerify the SUSE operating system generates an audit record when privileged functions are executed.
Find relevant setuid programs using the following command once for each local system partition, replacing "[PARTITION]" with each local system partition:
# sudo find [PARTITION] -xdev -type f \( -perm -4000 -o -perm -2000 \) 2>/dev/null
Verify all of the programs found with the command above are listed in the audit file by running the following command for every program found, replacing "[FILE_PATH]" with each program to include the full path:
# grep [FILE_PATH] /etc/audit/audit.rules
-w [SETUID_FILE_PATH] -p wa -k privilege_function
All setuid programs on the system must have a corresponding audit rule, or there must be an audit rule for the subdirectory that contains the setuid file.
If any of the setuid programs/files on the system do not have an audit rule, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020250The SUSE operating system must generate audit records for all uses of the su command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "su" command.
Add or update the following rules in the "/etc/audit/audit.rules" file:
-a always,exit -F -arch=b32 path=/usr/bin/su -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-priv_change
-a always,exit -F -arch=b64 path=/usr/bin/su -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-priv_change
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify the SUSE operating system generates an audit record for any use of the "su" command.
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo egrep "\/usr\/bin\/su\s" /etc/audit/audit.rules
-a always,exit -F -arch=b32 path=/usr/bin/su -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-priv_change
-a always,exit -F -arch=b64 path=/usr/bin/su -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-priv_change
If command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020260The SUSE operating system must generate audit records for all uses of the sudo command.<VulnDiscussion>Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.
At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "sudo" command.
Add or update the following rule to "/etc/audit/audit.rules":
-a always,exit -F -arch=b32 path=/usr/bin/sudo -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-sudo
-a always,exit -F -arch=b64 path=/usr/bin/sudo -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-sudo
The audit daemon must be restarted for any changes to take effect.Verify the SUSE operating system generates an audit record for any use of the "sudo" command.
Check that the following command call is being audited by performing the following command on the system rules in "/etc/audit/audit.rules":
# sudo grep -i sudo /etc/audit/audit.rules
-a always,exit -F -arch=b32 path=/usr/bin/sudo -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-sudo
-a always,exit -F -arch=b64 path=/usr/bin/sudo -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-sudo
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020270The SUSE operating system must generate audit records for all uses of the sudoedit command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "sudoedit" command.
Add or update the following rules in the "/etc/audit/audit.rules" file:
-a always,exit -F -arch=b32 path=/usr/bin/sudoedit -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-sudoedit
-a always,exit -F -arch=b64 path=/usr/bin/sudoedit -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-sudoedit
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify an audit record is generated for all uses of the "sudoedit" command.
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i 'sudoedit' /etc/audit/audit.rules
-a always,exit -F -arch=b32 path=/usr/bin/sudoedit -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-sudoedit
-a always,exit -F -arch=b64 path=/usr/bin/sudoedit -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-sudoedit
If command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020280The SUSE operating system must generate audit records for all uses of the chfn command.<VulnDiscussion>Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.
At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses the "chfn" command.
Add or update the following rule to "/etc/audit/audit.rules":
-a always,exit -F -arch=b32 path=/usr/bin/chfn -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-chfn
-a always,exit -F -arch=b64 path=/usr/bin/chfn -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-chfn
The audit daemon must be restarted for any changes to take effect.Verify the SUSE operating system generates an audit record for all uses of the "chfn" command.
Check that the following command call is being audited by performing the following command on the system rules in "/etc/audit/audit.rules":
# sudo grep -i chfn /etc/audit/audit.rules
-a always,exit -F -arch=b32 path=/usr/bin/chfn -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-chfn
-a always,exit -F -arch=b64 path=/usr/bin/chfn -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-chfn
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020290The SUSE operating system must generate audit records for all uses of the mount command.<VulnDiscussion>Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.
At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses the "mount" command.
Add or update the following rule to "/etc/audit/audit.rules":
-a always,exit -F arch=32 -S mount -F auid>=1000 -F auid!=4294967295 -k privileged-mount
-a always,exit -F arch=64 -S mount -F auid>=1000 -F auid!=4294967295 -k privileged-mount
The audit daemon must be restarted for any changes to take effect.Verify the SUSE operating system generates an audit record for all uses of the "mount" command.
Check that the following command call is being audited by performing the following command on the system rules in "/etc/audit/audit.rules":
# sudo grep -i mount /etc/audit/audit.rules
-a always,exit -F arch=32 -S mount -F auid>=1000 -F auid!=4294967295 -k privileged-mount
-a always,exit -F arch=64 -S mount -F auid>=1000 -F auid!=4294967295 -k privileged-mount
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020300The SUSE operating system must generate audit records for all uses of the umount command.<VulnDiscussion>Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.
At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses the "umount" command.
Add or update the following rule to "/etc/audit/audit.rules":
-a always,exit -F arch=32 -S umount -F auid>=1000 -F auid!=4294967295 -k privileged-umount
-a always,exit -F arch=64 -S umount -F auid>=1000 -F auid!=4294967295 -k privileged-umount
The audit daemon must be restarted for any changes to take effect.Verify the SUSE operating system generates an audit record for all uses of the "umount" command.
Check that the following command call is being audited by performing the following command on the system rules in "/etc/audit/audit.rules":
# sudo grep -i umount /etc/audit/audit.rules
-a always,exit -F arch=32 -S umount -F auid>=1000 -F auid!=4294967295 -k privileged-umount
-a always,exit -F arch=64 -S umount -F auid>=1000 -F auid!=4294967295 -k privileged-umount
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020310The SUSE operating system must generate audit records for all uses of the ssh-agent command.<VulnDiscussion>Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.
At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses the "ssh-agent" command.
Add or update the following rule to "/etc/audit/audit.rules":
-a always,exit -F arch=32 path=/usr/bin/ssh-agent -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-ssh-agent
-a always,exit -F arch=64 path=/usr/bin/ssh-agent -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-ssh-agent
The audit daemon must be restarted for any changes to take effect.Verify the SUSE operating system generates an audit record for all uses of the "ssh-agent" command.
Check that the following command call is being audited by performing the following command on the system rules in "/etc/audit/audit.rules":
# sudo grep -i ssh-agent /etc/audit/audit.rules
-a always,exit -F arch=32 path=/usr/bin/ssh-agent -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-ssh-agent
-a always,exit -F arch=64 path=/usr/bin/ssh-agent -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-ssh-agent
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020320The SUSE operating system must generate audit records for all uses of the ssh-keysign command.<VulnDiscussion>Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.
At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses the "ssh-keysign" command.
Add or update the following rule to "/etc/audit/audit.rules":
-a always,exit -F arch=32 path=/usr/lib/ssh/ssh-keysign -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-ssh-keysign
-a always,exit -F arch=64 path=/usr/lib/ssh/ssh-keysign -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-ssh-keysign
The audit daemon must be restarted for any changes to take effect.Verify the SUSE operating system generates an audit record for all uses of the "ssh-keysign" command.
Check that the following command call is being audited by performing the following command on the system rules in "/etc/audit/audit.rules":
# sudo grep -i ssh-keysign /etc/audit/audit.rules
-a always,exit -F arch=32 path=/usr/lib/ssh/ssh-keysign -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-ssh-keysign
-a always,exit -F arch=64 path=/usr/lib/ssh/ssh-keysign -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-ssh-keysign
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020330The SUSE operating system must generate audit records for all uses of the insmod command.<VulnDiscussion>Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records.
DoD has defined the following list of events for which the SUSE operating system will provide an audit record generation capability:
1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);
2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system;
3) All account creations, modifications, disabling, and terminations; and
4) All kernel module load, unload, and restart actions.
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000471-GPOS-00216, SRG-OS-000477-GPOS-00222</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to audit the execution of the module management program "insmod" by adding the following line to "/etc/audit/audit.rules":
-w /sbin/insmod -p x -k modulesVerify the SUSE operating system is generates an audit record for all uses of the "insmod" command.
Check that the following command call is being audited by performing the following command on the system rules in "/etc/audit/audit.rules":
# sudo grep insmod /etc/audit/audit.rules
-w /sbin/insmod -p x -k modules
If the system is configured to audit the execution of the module management program "insmod", the command will return a line.
If the command does not return a line, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020340The SUSE operating system must generate audit records for all uses of the rmmod command.<VulnDiscussion>Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records.
DoD has defined the following list of events for which the SUSE operating system will provide an audit record generation capability:
1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);
2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system;
3) All account creations, modifications, disabling, and terminations; and
4) All kernel module load, unload, and restart actions.
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to audit the execution of the module management program "rmmod" by adding the following line to "/etc/audit/audit.rules":
-w /sbin/rmmod -p x -k modulesVerify the SUSE operating system generates an audit record for all uses of the "rmmod" command.
Check that the following command call is being audited by performing the following command on the system rules in "/etc/audit/audit.rules":
# sudo grep rmmod /etc/audit/audit.rules
-w /sbin/rmmod -p x -k modules
If the system is configured to audit the execution of the module management program "rmmod", the command will return a line.
If the command does not return a line, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020350The SUSE operating system must generate audit records for all uses of the modprobe command.<VulnDiscussion>Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records.
DoD has defined the following list of events for which the SUSE operating system will provide an audit record generation capability:
1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);
2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system;
3) All account creations, modifications, disabling, and terminations; and
4) All kernel module load, unload, and restart actions.
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to audit the execution of the module management program "modprobe" by adding the following line to "/etc/audit/audit.rules":
-w /sbin/modprobe -p x -k modulesVerify the SUSE operating system generates an audit record for all uses of the "modprobe" command.
Check that the following command call is being audited by performing the following command on the system rules in "/etc/audit/audit.rules":
# sudo grep modprobe /etc/audit/audit.rules
-w /sbin/modprobe -p x -k modules
If the system is configured to audit the execution of the module management program "modprobe", the command will return a line.
If the command does not return a line, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020360The SUSE operating system must generate audit records for all uses of the kmod command.<VulnDiscussion>Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records.
DoD has defined the following list of events for which the SUSE operating system will provide an audit record generation capability:
1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);
2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system;
3) All account creations, modifications, disabling, and terminations; and
4) All kernel module load, unload, and restart actions.
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to audit the execution of the module management program "kmod" by adding the following line to "/etc/audit/audit.rules":
-w /usr/bin/kmod -p x -k modulesVerify the SUSE operating system generates an audit record for all uses of the "kmod" command.
Check that the following command call is being audited by performing the following command on the system rules in "/etc/audit/audit.rules":
# sudo grep kmod /etc/audit/audit.rules
-w /usr/bin/kmod -p x -k modules
If the system is configured to audit the execution of the module management program "kmod", the command will return a line.
If the command does not return a line, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020370The SUSE operating system must generate audit records for all uses of the setxattr command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "setxattr" command.
Add or update the following rule in the "/etc/audit/audit.rules" file:
-a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify the SUSE operating system generates an audit record for all uses of the "setxattr" command.
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i setxattr /etc/audit/audit.rules
-a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020380The SUSE operating system must generate audit records for all uses of the fsetxattr command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "fsetxattr" command.
Add or update the following rule in the "/etc/audit/audit.rules" file:
-a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify the SUSE operating system generates an audit record for all uses of the "fsetxattr" command.
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i fsetxattr /etc/audit/audit.rules
-a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020390The SUSE operating system must generate audit records for all uses of the removexattr command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "removexattr" command.
Add or update the following rule in the "/etc/audit/audit.rules" file:
-a always,exit -F arch=b32 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify the SUSE operating system generates an audit record for all uses of the "removexattr" command.
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i removexattr /etc/audit/audit.rules
-a always,exit -F arch=b32 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020400The SUSE operating system must generate audit records for all uses of the lremovexattr command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "lremovexattr" command.
Add or update the following rule in the "/etc/audit/audit.rules" file:
-a always,exit -F arch=b32 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify the SUSE operating system generates an audit record for all uses of the "lremovexattr" command.
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i lremovexattr /etc/audit/audit.rules
-a always,exit -F arch=b32 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020410The SUSE operating system must generate audit records for all uses of the fremovexattr command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "fremovexattr" command.
Add or update the following rules in the "/etc/audit/audit.rules" file:
-a always,exit -F arch=b32 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify the SUSE operating system generates an audit record for all uses of the "fremovexattr" command.
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i fremovexattr /etc/audit/audit.rules
-a always,exit -F arch=b32 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020420The SUSE operating system must generate audit records for all uses of the chown command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "chown" command.
Add or update the following rules in the "/etc/audit/audit.rules" file:
-a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=4294967295 -k perm_mod
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify the SUSE operating system generates an audit record for all uses of the "chown" command.
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i chown /etc/audit/audit.rules
-a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020430The SUSE operating system must generate audit records for all uses of the fchown command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "fchown" command.
Add or update the following rules in the "/etc/audit/audit.rules" file:
-a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_mod
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify the SUSE operating system generates an audit record for all uses of the "fchown" command.
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i fchown /etc/audit/audit.rules
-a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020440The SUSE operating system must generate audit records for all uses of the lchown command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "lchown" command.
Add or update the following rules in the "/etc/audit/audit.rules" file:
-a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify the SUSE operating system generates an audit record for all uses of the "lchown" command.
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i lchown /etc/audit/audit.rules
-a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020450The SUSE operating system must generate audit records for all uses of the fchownat command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "fchownat" command.
Add or update the following rules in the "/etc/audit/audit.rules" file:
-a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=4294967295 -k perm_mod
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify the SUSE operating system generates an audit record for all uses of the "fchownat" command.
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i fchownat /etc/audit/audit.rules
-a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020460The SUSE operating system must generate audit records for all uses of the chmod command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "chmod" command.
Add or update the following rule in the "/etc/audit/audit.rules" file:
-a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=4294967295 -k perm_mod
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify the SUSE operating system generates an audit record for all uses of the "chmod" command.
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i chmod /etc/audit/audit.rules
-a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020470The SUSE operating system must generate audit records for all uses of the fchmod command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "fchmod" command.
Add or update the following rule in the "/etc/audit/audit.rules" file:
-a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=4294967295 -k perm_mod
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify the SUSE operating system generates an audit record for all uses of the "fchmod" command.
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i fchmod /etc/audit/audit.rules
-a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020480The SUSE operating system must generate audit records for all uses of the fchmodat command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "fchmodat" command.
Add or update the following rule in the "/etc/audit/audit.rules" file:
-a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify the SUSE operating system generates an audit record for all uses of the "fchmodat" command.
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i fchmodat /etc/audit/audit.rules
-a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020490The SUSE operating system must generate audit records for all uses of the open command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "open" command.
Add or update the following rules in the "/etc/audit/audit.rules" file:
-a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify the SUSE operating system generates an audit record for all uses of the "open" command.
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i open /etc/audit/audit.rules
-a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access
If the command does not return any output, this is a finding.SRG-OS-000064-GPOS-00033<GroupDescription></GroupDescription>SLES-12-020500The SUSE operating system must generate audit records for all uses of the truncate command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000458-GPOS-00203</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000172Configure the SUSE operating system to generate an audit record for all uses of the "truncate" command.
Add or update the following rules in the "/etc/audit/audit.rules" file:
-a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify the SUSE operating system generates an audit record for all uses of the "truncate" command.
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i truncate /etc/audit/audit.rules
-a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020510The SUSE operating system must generate audit records for all uses of the ftruncate command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "ftruncate" command.
Add or update the following rules in the "/etc/audit/audit.rules" file:
-a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify the SUSE operating system generates an audit record for all uses of the "ftruncate" command.
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i ftruncate /etc/audit/audit.rules
-a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020520The SUSE operating system must generate audit records for all uses of the creat command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "creat" command.
Add or update the following rules in the "/etc/audit/audit.rules" file:
-a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify the SUSE operating system generates an audit record for all uses of the "creat" command.
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i creat /etc/audit/audit.rules
-a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020530The SUSE operating system must generate audit records for all uses of the openat command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "openat" command.
Add or update the following rules in the "/etc/audit/audit.rules" file:
-a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify the SUSE operating system generates an audit record for all uses of the "openat" command.
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i openat /etc/audit/audit.rules
-a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020540The SUSE operating system must generate audit records for all uses of the open_by_handle_at command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "open_by_handle_at" command.
Add or update the following rules in the "/etc/audit/audit.rules" file:
-a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify the SUSE operating system generates an audit record for all uses of the "open_by_handle_at" command.
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i open_by_handle_at /etc/audit/audit.rules
-a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020550The SUSE operating system must generate audit records for all uses of the passwd command.<VulnDiscussion>Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.
At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses the "passwd" command.
Add or update the following rule to "/etc/audit/audit.rules":
-a always,exit -F arch=b32 path=/usr/bin/passwd -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-passwd
-a always,exit -F arch=b64 path=/usr/bin/passwd -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-passwd
The audit daemon must be restarted for any changes to take effect.Verify the SUSE operating system generates an audit record for all uses of the "passwd" command.
Check that the following command call is being audited by performing the following command on the system rules in "/etc/audit/audit.rules":
# sudo grep -i /usr/bin/passwd /etc/audit/audit.rules
-a always,exit -F arch=b32 path=/usr/bin/passwd -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-passwd
-a always,exit -F arch=b64 path=/usr/bin/passwd -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-passwd
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020560The SUSE operating system must generate audit records for all uses of the gpasswd command.<VulnDiscussion>Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.
At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses the "gpasswd" command.
Add or update the following rule to "/etc/audit/audit.rules":
-a always,exit -F arch=b32 path=/usr/bin/gpasswd -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-gpasswd
-a always,exit -F arch=b64 path=/usr/bin/gpasswd -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-gpasswd
The audit daemon must be restarted for any changes to take effect.Verify the SUSE operating system generates an audit record for all uses of the "gpasswd" command.
Check that the following command call is being audited by performing the following command on the system rules in "/etc/audit/audit.rules":
# sudo grep -i gpasswd /etc/audit/audit.rules
-a always,exit -F arch=b32 path=/usr/bin/gpasswd -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-gpasswd
-a always,exit -F arch=b64 path=/usr/bin/gpasswd -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-gpasswd
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020570The SUSE operating system must generate audit records for all uses of the newgrp command.<VulnDiscussion>Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.
At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses the "newgrp" command.
Add or update the following rule to "/etc/audit/audit.rules":
-a always,exit -F arch=b32 path=/usr/bin/newgrp -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-newgrp
-a always,exit -F arch=b64 path=/usr/bin/newgrp -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-newgrp
The audit daemon must be restarted for any changes to take effect.Verify the SUSE operating system generates an audit record for all uses of the "newgrp" command.
Check that the following command call is being audited by performing the following command on the system rules in "/etc/audit/audit.rules":
# sudo grep -i newgrp /etc/audit/audit.rules
-a always,exit -F arch=b32 path=/usr/bin/newgrp -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-newgrp
-a always,exit -F arch=b64 path=/usr/bin/newgrp -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-newgrp
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020580The SUSE operating system must generate audit records for a uses of the chsh command.<VulnDiscussion>Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.
At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses the "chsh" command.
Add or update the following rule to "/etc/audit/audit.rules":
-a always,exit -F arch=b32 path=/usr/bin/chsh -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-chsh
-a always,exit -F arch=b64 path=/usr/bin/chsh -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-chsh
The audit daemon must be restarted for any changes to take effect.Verify the SUSE operating system generates an audit record for all uses of the "chsh" command.
Check that the following command call is being audited by performing the following command on the system rules in "/etc/audit/audit.rules":
# sudo grep -i chsh /etc/audit/audit.rules
-a always,exit -F arch=b32 path=/usr/bin/chsh -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-chsh
-a always,exit -F arch=b64 path=/usr/bin/chsh -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-chsh
If the command does not return any output, this is a finding.SRG-OS-000004-GPOS-00004<GroupDescription></GroupDescription>SLES-12-020590The SUSE operating system must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/gshadow.<VulnDiscussion>Once an attacker establishes initial access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to simply create a new account. Auditing of account creation mitigates this risk.
To address access requirements, many SUSE operating systems may be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.
Satisfies: SRG-OS-000004-GPOS-00004, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000476-GPOS-00221</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000018CCI-000172CCI-001403CCI-002130Configure the SUSE operating system to generate an audit record when all modifications to the "/etc/gshadow" file occur.
Add or update the following rule to "/etc/audit/audit.rules":
-w /etc/gshadow -p wa -k account_mod
The audit daemon must be restarted for any changes to take effect.Verify the SUSE operating system generates an audit record when all modifications occur to the "/etc/gshadow" file.
Check that the following file is being watched by performing the following command on the system rules in "/etc/audit/audit.rules":
# sudo grep /etc/gshadow /etc/audit/audit.rules
-w /etc/gshadow -p wa -k account_mod
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020600The SUSE operating system must generate audit records for all uses of the chmod command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "chmod" command.
Add or update the following rules in the "/etc/audit/audit.rules" file:
-a always,exit -F arch=b32 path=/usr/bin/chmod -F perm=x -F auid>=500 -F auid!=4294967295 -k prim_mod
-a always,exit -F arch=b64 path=/usr/bin/chmod -F perm=x -F auid>=500 -F auid!=4294967295 -k prim_mod
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify the SUSE operating system generates an audit record for all uses of the "chmod" command.
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i chmod /etc/audit/audit.rules
-a always,exit -F arch=b32 path=/usr/bin/chmod -F perm=x -F auid>=500 -F auid!=4294967295 -k prim_mod
-a always,exit -F arch=b64 path=/usr/bin/chmod -F perm=x -F auid>=500 -F auid!=4294967295 -k prim_mod
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020610The SUSE operating system must generate audit records for all uses of the setfacl command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "setfacl" command.
Add or update the following rules in the "/etc/audit/audit.rules" file:
-a always,exit -F arch=b32 path=/usr/bin/setfacl -F perm=x -F auid>=500 -F auid!=4294967295 -k prim_mod
-a always,exit -F arch=b64 path=/usr/bin/setfacl -F perm=x -F auid>=500 -F auid!=4294967295 -k prim_mod
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify the SUSE operating system generates an audit record for all uses of the "setfacl" command.
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i setfacl /etc/audit/audit.rules
-a always,exit -F arch=b32 path=/usr/bin/setfacl -F perm=x -F auid>=500 -F auid!=4294967295 -k prim_mod
-a always,exit -F arch=b64 path=/usr/bin/setfacl -F perm=x -F auid>=500 -F auid!=4294967295 -k prim_mod
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020620The SUSE operating system must generate audit records for all uses of the chacl command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "chacl" command.
Add or update the following rules in the "/etc/audit/audit.rules" file:
-a always,exit -F arch=b32 path=/usr/bin/chacl -F perm=x -F auid>=500 -F auid!=4294967295 -k prim_mod
-a always,exit -F arch=b64 path=/usr/bin/chacl -F perm=x -F auid>=500 -F auid!=4294967295 -k prim_mod
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify the SUSE operating system generates an audit record for all uses of the "chacl" command.
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i chacl /etc/audit/audit.rules
-a always,exit -F arch=b32 path=/usr/bin/chacl -F perm=x -F auid>=500 -F auid!=4294967295 -k prim_mod
-a always,exit -F arch=b64 path=/usr/bin/chacl -F perm=x -F auid>=500 -F auid!=4294967295 -k prim_mod
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020630Successful/unsuccessful attempts to modify categories of information (e.g., classification levels) must generate audit records.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate audit records when successful/unsuccessful attempts to modify categories of information (e.g., classification levels) occur.
Add or update the following rule in the "/etc/audit/audit.rules" file:
-a always,exit -F arch=b32 path=/usr/bin/chcon -F perm=x -F auid>=500 -F auid!=4294967295 -k prim_mod
-a always,exit -F arch=b64 path=/usr/bin/chcon -F perm=x -F auid>=500 -F auid!=4294967295 -k prim_mod
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify audit records are generated when successful/unsuccessful attempts to modify categories of information (e.g., classification levels) occur.
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i 'chcon' /etc/audit/audit.rules
-a always,exit -F arch=b32 path=/usr/bin/chcon -F perm=x -F auid>=500 -F auid!=4294967295 -k prim_mod
-a always,exit -F arch=b64 path=/usr/bin/chcon -F perm=x -F auid>=500 -F auid!=4294967295 -k prim_mod
If command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020640The SUSE operating system must generate audit records for all uses of the rm command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "rm" command.
Add or update the following rules in the "/etc/audit/audit.rules" file:
-a always,exit -F arch=b32 path=/usr/bin/rm -F perm=x -F auid>=500 -F auid!=4294967295 -k prim_mod
-a always,exit -F arch=b64 path=/usr/bin/rm -F perm=x -F auid>=500 -F auid!=4294967295 -k prim_mod
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify the SUSE operating system generates an audit record for all uses of the "rm" command.
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i rm /etc/audit/audit.rules
-a always,exit -F arch=b32 path=/usr/bin/rm -F perm=x -F auid>=500 -F auid!=4294967295 -k prim_mod
-a always,exit -F arch=b64 path=/usr/bin/rm -F perm=x -F auid>=500 -F auid!=4294967295 -k prim_mod
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020650The SUSE operating system must generate audit records for all modifications to the tallylog file must generate an audit record.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000473-GPOS-00218</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for any all modifications to the "tallylog" file occur.
Add or update the following rules in the "/etc/audit/audit.rules" file:
-w /var/log/tallylog -p wa -k logins
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify the SUSE operating system generates an audit record when all modifications to the "tallylog" file occur.
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i tallylog /etc/audit/audit.rules
-w /var/log/tallylog -p wa -k logins
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020660The SUSE operating system must generate audit records for all modifications to the lastlog file.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for any all modifications to the "lastlog" file occur.
Add or update the following rules in the "/etc/audit/audit.rules" file:
-w /var/log/lastlog -p wa -k logins
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify the SUSE operating system generates an audit record when all modifications to the "lastlog" file occur.
Check that the following is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i lastlog /etc/audit/audit.rules
-w /var/log/lastlog -p wa -k logins
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020670The SUSE operating system must generate audit records for all uses of the passmass command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "passmass" command.
Add or update the following rules in the "/etc/audit/audit.rules" file:
-a always,exit -F arch=b32 path=/usr/bin/passmass -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-passmass
-a always,exit -F arch=b64 path=/usr/bin/passmass -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-passmass
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify the SUSE operating system generates an audit record for all uses of the "passmass" command.
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i passmass /etc/audit/audit.rules
-a always,exit -F arch=b32 path=/usr/bin/passmass -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-passmass
-a always,exit -F arch=b64 path=/usr/bin/passmass -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-passmass
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020680The SUSE operating system must generate audit records for all uses of the unix_chkpwd command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "unix_chkpwd" command.
Add or update the following rules in the "/etc/audit/audit.rules" file:
-a always,exit -F arch=b32 path=/sbin/unix_chkpwd -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-unix-chkpwd
-a always,exit -F arch=b64 path=/sbin/unix_chkpwd -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-unix-chkpwd
-a always,exit -F arch=b32 path=/sbin/unix2_chkpwd -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-unix2-chkpwd
-a always,exit -F arch=b64 path=/sbin/unix2_chkpwd -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-unix2-chkpwd
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify an audit record is generated for all uses of the "unix_chkpwd" command.
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo egrep -i '(unix_chkpwd|unix2_chkpwd)' /etc/audit/audit.rules
-a always,exit -F arch=b32 path=/sbin/unix_chkpwd -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-unix-chkpwd
-a always,exit -F arch=b64 path=/sbin/unix_chkpwd -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-unix-chkpwd
-a always,exit -F arch=b32 path=/sbin/unix2_chkpwd -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-unix2-chkpwd
-a always,exit -F arch=b64 path=/sbin/unix2_chkpwd -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-unix2-chkpwd
If command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020690The SUSE operating system must generate audit records for all uses of the chage command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "chage" command.
Add or update the following rules in the "/etc/audit/audit.rules" file:
-a always,exit -F arch=b32 path=/usr/bin/chage -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-chage
-a always,exit -F arch=b64 path=/usr/bin/chage -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-chage
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify an audit record is generated for all uses of the "chage" command. Perform the verification by running the following command:
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i 'chage' /etc/audit/audit.rules
-a always,exit -F arch=b32 path=/usr/bin/chage -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-chage
-a always,exit -F arch=b64 path=/usr/bin/chage -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-chage
If command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020700The SUSE operating system must generate audit records for all uses of the usermod command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "usermod" command.
Add or update the following rules in the "/etc/audit/audit.rules" file:
-a always,exit -F arch=b32 path=/usr/sbin/usermod -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-usermod
-a always,exit -F arch=b64 path=/usr/sbin/usermod -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-usermod
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify an audit record is generated for all uses of the "usermod" command.
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i 'usermod' /etc/audit/audit.rules
-a always,exit -F arch=b32 path=/usr/sbin/usermod -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-usermod
-a always,exit -F arch=b64 path=/usr/sbin/usermod -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-usermod
If command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020710The SUSE operating system must generate audit records for all uses of the crontab command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "crontab" command.
Add or update the following rules to "/etc/audit/audit.rules":
-a always,exit -F arch=b32 path=/usr/bin/crontab -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-crontab
-a always,exit -F arch=b64 path=/usr/bin/crontab -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-crontab
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify an audit record is generated for all uses of the "crontab" command.
Check for the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i 'crontab' /etc/audit/audit.rules
-a always,exit -F arch=b32 path=/usr/bin/crontab -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-crontab
-a always,exit -F arch=b64 path=/usr/bin/crontab -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-crontab
If command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020720The SUSE operating system must generate audit records for all uses of the pam_timestamp_check command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "pam_timestamp_check" command. Add or update the following rules in the "/etc/audit/audit.rules" file:
Add or update the following rules to "/etc/audit/audit.rules":
-a always,exit -F arch=b32 path=/sbin/pam_timestamp_check -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-pam_timestamp_check
-a always,exit -F arch=b64 path=/sbin/pam_timestamp_check -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-pam_timestamp_check
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify an audit record is generated for all uses of the "pam_timestamp_check" command.
Check for the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i 'pam_timestamp_check' /etc/audit/audit.rules
-a always,exit -F arch=b32 path=/sbin/pam_timestamp_check -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-pam_timestamp_check
-a always,exit -F arch=b64 path=/sbin/pam_timestamp_check -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-pam_timestamp_check
If command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020730The SUSE operating system must generate audit records for all uses of the delete_module command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "delete_module" command.
Add or update the following rule in the "/etc/audit/audit.rules" file:
-a always,exit -F arch=b32 -S delete_module -F auid>=1000 -F auid!=4294967295 -k unload_module
-a always,exit -F arch=b64 -S delete_module -F auid>=1000 -F auid!=4294967295 -k unload_module
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify the SUSE operating system generates an audit record for all uses of the "delete_module" command.
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i delete_module /etc/audit/audit.rules
-a always,exit -F arch=b32 -S delete_module -F auid>=1000 -F auid!=4294967295 -k unload_module
-a always,exit -F arch=b64 -S delete_module -F auid>=1000 -F auid!=4294967295 -k unload_module
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020740The SUSE operating system must generate audit records for all uses of the finit_module command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "finit_module" command.
Add or update the following rule in the "/etc/audit/audit.rules" file:
-a always,exit -F arch=b32 -S finit_module -F auid>=1000 -F auid!=4294967295 -k module-load
-a always,exit -F arch=b64 -S finit_module -F auid>=1000 -F auid!=4294967295 -k module-load
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify the SUSE operating system generates an audit record for all uses of the "finit_module" command.
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i finit_module /etc/audit/audit.rules
-a always,exit -F arch=b32 -S finit_module -F auid>=1000 -F auid!=4294967295 -k module-load
-a always,exit -F arch=b64 -S finit_module -F auid>=1000 -F auid!=4294967295 -k module-load
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020750The SUSE operating system must generate audit records for all uses of the init_module command.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for all uses of the "init_module" command.
Add or update the following rule in the "/etc/audit/audit.rules" file:
-a always,exit -F arch=b32 -S init_module -F auid>=1000 -F auid!=4294967295 -k module-load
-a always,exit -F arch=b64 -S init_module -F auid>=1000 -F auid!=4294967295 -k module-load
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify the SUSE operating system generates an audit record for all uses of the "init_module" command.
Check that the following command call is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i init_module /etc/audit/audit.rules
-a always,exit -F arch=b32 -S init_module -F auid>=1000 -F auid!=4294967295 -k module-load
-a always,exit -F arch=b64 -S init_module -F auid>=1000 -F auid!=4294967295 -k module-load
If the command does not return any output, this is a finding.SRG-OS-000037-GPOS-00015<GroupDescription></GroupDescription>SLES-12-020760The SUSE operating system must generate audit records for all modifications to the faillog file.<VulnDiscussion>Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000130CCI-000169CCI-000172CCI-002884Configure the SUSE operating system to generate an audit record for any all modifications to the "faillog" file occur.
Add or update the following rules in the "/etc/audit/audit.rules" file:
-w /var/log/faillog -p wa -k logins
The audit daemon must be restarted for the changes to take effect.
# sudo systemctl restart auditd.serviceVerify the SUSE operating system generates an audit record when all modifications to the "faillog" file occur.
Check that the following is being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":
# sudo grep -i faillog /etc/audit/audit.rules
-w /var/log/faillog -p wa -k logins
If the command does not return any output, this is a finding.SRG-OS-000074-GPOS-00042<GroupDescription></GroupDescription>SLES-12-030000The SUSE operating system must not have the telnet-server package installed.<VulnDiscussion>It is detrimental for SUSE operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors.
SUSE operating systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions and functions).
Examples of nonessential capabilities include but are not limited to games, software packages, tools, and demonstration software not related to requirements or providing a wide array of functionality not required for every mission but which cannot be disabled.
Satisfies: SRG-OS-000074-GPOS-00042, SRG-OS-000095-GPOS-00049</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000197CCI-000381Remove the telnet-server package from the SUSE operating system by running the following command:
# sudo zypper remove telnet-serverVerify the telnet-server package is not installed on the SUSE operating system.
Check that the telnet-server package is not installed on the SUSE operating system by running the following command:
# zypper se telnet-server
If the telnet-server package is installed, this is a finding.SRG-OS-000023-GPOS-00006<GroupDescription></GroupDescription>SLES-12-030010The SUSE operating system must display the Standard Mandatory DoD Notice and Consent Banner before granting access via SFTP/FTP.<VulnDiscussion>Display of a standardized and approved use notification before granting access to the SUSE operating system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.
System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist.
The banner must be formatted in accordance with applicable DoD policy. Use the following verbiage for SUSE operating systems that can accommodate banners of 1300 characters:
"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.
By using this IS (which includes any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.
-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000048Configure the SUSE operating system to display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system via VSFTP by running the following commands:
Edit the "vsftpd.conf" file:
# sudo sed -i 's/^.*\bftpd_banner\b.*$/ftpd_banner=\/etc\/issue/' /etc/vsftpd.conf
Restart the vsftp daemon:
# sudo systemctl restart vsftpd.service
If "/etc/issue" does not contain the Standard Mandatory DoD banner, add the following text to "/etc/issue":
"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.
By using this IS (which includes any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.
-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."Verify the SUSE operating system displays the Standard Mandatory DoD Notice and Consent Banner before granting access to the system via VSFTP.
Check the issue file to verify that it contains one of the DoD-required banners. If it does not, this is a finding.
# more /etc/issue
The output must display the following DoD-required banner text.
"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.
By using this IS (which includes any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.
-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."
If the output does not display the banner text, this is a finding.
Check the banner setting in vsftpd.conf:
# sudo grep "ftpd_banner" /etc/vsftpd.conf
The output must show the value of "ftpd_banner" set to "/etc/issue". An example is shown below:
# sudo grep Banner" /etc/vsftpd.conf
ftpd_banner=/etc/issue
If the output does not show the value of "ftpd_banner" set to "/etc/issue", this is a finding.SRG-OS-000024-GPOS-00007<GroupDescription></GroupDescription>SLES-12-030020The SUSE operating system file /etc/gdm/banner must contain the Standard Mandatory DoD Notice and Consent banner text.<VulnDiscussion>The banner must be acknowledged by the user prior to allowing the user access to the SUSE operating system. This provides assurance that the user has seen the message and accepted the conditions for access. If the consent banner is not acknowledged by the user, DoD will not be in compliance with system use notifications required by law.
To establish acceptance of the application usage policy, a click-through banner at system logon is required. The system must prevent further activity until the user executes a positive action to manifest agreement by clicking on a box indicating "OK".</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000050Configure the SUSE operating system file "/etc/gdm/banner" to contain the Standard Mandatory DoD Notice and Consent Banner by running the following commands:
# sudo vi /etc/gdm/banner
Add the following information to the file:
"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.
By using this IS (which includes any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.
-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."Verify the SUSE operating system file "/etc/gdm/banner" contains the Standard Mandatory DoD Notice and Consent Banner text by running the following command:
# more /etc/gdm/banner
If the file does not contain the following text, this is a finding.
"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.
By using this IS (which includes any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.
-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."SRG-OS-000096-GPOS-00050<GroupDescription></GroupDescription>SLES-12-030030The SUSE operating system must be configured to prohibit or restrict the use of functions, ports, protocols, and/or services as defined in the Ports, Protocols, and Services Management (PPSM) Category Assignments List (CAL) and vulnerability assessments.<VulnDiscussion>To prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types), organizations must disable or restrict unused or unnecessary physical and logical ports/protocols on information systems.
SUSE operating systems are capable of providing a wide variety of functions and services. Some of the functions and services provided by default may not be necessary to support essential organizational operations. Additionally, it is sometimes convenient to provide multiple services from a single component (e.g., VPN and IPS); however, doing so increases risk over limiting the services provided by any one component.
To support the requirements and principles of least functionality, the SUSE operating system must support the organizational requirements, providing only essential capabilities and limiting the use of ports, protocols, and/or services to only those required, authorized, and approved to conduct official business or address authorized quality-of-life issues.
Satisfies: SRG-OS-000096-GPOS-00050, SRG-OS-000297-GPOS-00115, SRG-OS-000480-GPOS-00231, SRG-OS-000480-GPOS-00232</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000382CCI-002080CCI-002314Configure the SUSE operating system is configured to prohibit or restrict the use of functions, ports, protocols, and/or services as defined in the Ports, Protocols, and Services Management (PPSM) Category Assignments List (CAL) and vulnerability assessments.
Add/modify /etc/sysconfig/SuSEfirewall2 file to comply with the Ports, Protocols, and Services Management (PPSM) Category Assignments List (CAL).
Enable the "SuSEfirewall2.service" by running the following command:
# systemctl enable SuSEfirewall2.service
Start the "SuSEfirewall2.service" by running the following command:
# systemctl start SuSEfirewall2.serviceVerify the SUSE operating system is configured to prohibit or restrict the use of functions, ports, protocols, and/or services as defined in the Ports, Protocols, and Services Management (PPSM) Category Assignments List (CAL) and vulnerability assessments.
Check that the "SuSEfirewall2.service" is enabled and running by running the following command:
# systemctl status SuSEfirewall2.service
* SuSEfirewall2.service - SuSEfirewall2 phase 2
Loaded: loaded (/usr/lib/systemd/system/SuSEfirewall2.service; enabled; vendor preset: disabled)
Active: active (exited) since Thu 2017-03-09 17:33:29 UTC; 6 days ago
Main PID: 2533 (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 512)
Memory: 0B
CPU: 0
CGroup: /system.slice/SuSEfirewall2.service
If the service is not enabled, this is a finding.
If the service is not active, this is a finding.
Check the firewall configuration for any unnecessary or prohibited functions, ports, protocols, and/or services by running the following command:
# grep ^FW_ /etc/sysconfig/SuSEfirewall2
Ask the System Administrator for the site or program PPSM Component Local Services Assessment (Component Local Services Assessment (CLSA). Verify the services allowed by the firewall match the PPSM CLSA.
If there are any additional ports, protocols, or services that are not included in the PPSM CLSA, this is a finding.
If there are any ports, protocols, or services that are prohibited by the PPSM CAL, this is a finding.SRG-OS-000420-GPOS-00186<GroupDescription></GroupDescription>SLES-12-030040SuSEfirewall2 must protect against or limit the effects of Denial-of-Service (DoS) attacks on the SUSE operating system by implementing rate-limiting measures on impacted network interfaces.<VulnDiscussion>DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity.
This requirement addresses the configuration of the SUSE operating system to mitigate the impact on system availability of DoS attacks that have occurred or are ongoing. For each system, known and potential DoS attacks must be identified and solutions for each type implemented. A variety of technologies exist to limit or, in some cases, eliminate the effects of DoS attacks (e.g., limiting processes or establishing memory partitions). Employing increased capacity and bandwidth, combined with service redundancy, may reduce the susceptibility to some DoS attacks.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-002385Configure "SuSEfirewall2" to protect the SUSE operating system against or limit the effects of DoS attacks by implementing rate-limiting measures on impacted network interfaces.
Add or replace the following line in "/etc/sysconfig/SuSEfirewall2":
FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"
The firewall must be restarted in order for the changes to take effect.
# sudo systemctl restart SuSEfirewall2.serviceVerify "SuSEfirewall2" is configured to protect the SUSE operating system against or limit the effects of DoS attacks.
Run the following command:
# grep -i fw_services_accept_ext /etc/sysconfig/SuSEfirewall2
FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"
If the "FW_SERVICES_ACCEPT_EXT" rule does not contain both the "hitcount" and "blockseconds" parameters, this is a finding.SRG-OS-000023-GPOS-00006<GroupDescription></GroupDescription>SLES-12-030050The SUSE operating system must display the Standard Mandatory DoD Notice and Consent Banner before granting access via SSH.<VulnDiscussion>Display of a standardized and approved use notification before granting access to the SUSE operating system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.
System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist.
The banner must be formatted in accordance with applicable DoD policy. Use the following verbiage for SUSE operating systems that can accommodate banners of 1300 characters:
"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.
By using this IS (which includes any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.
-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000048Configure the SUSE operating system to display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system by running the following commands:
Edit the "sshd_config" file and edit the Banner flag to be the following:
Banner /etc/issue/
Restart the sshd daemon:
# sudo systemctl restart sshd.service
To configure the system logon banner, edit the "/etc/issue" file. Replace the default text inside with the Standard Mandatory DoD banner text:
"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.
By using this IS (which includes any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.
-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."Verify the SUSE operating system displays the Standard Mandatory DoD Notice and Consent Banner before granting access to the system via SSH.
Check the issue file to verify that it contains one of the DoD required banners. If it does not, this is a finding.
# more /etc/issue
The output must display the following DoD-required banner text.
"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.
By using this IS (which includes any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.
-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."
If the output does not display the banner text, this is a finding.
Check the banner setting for sshd_config:
# sudo grep "Banner" /etc/ssh/sshd_config
The output must show the value of "Banner" set to "/etc/issue". An example is shown below:
# sudo grep "Banner" /etc/ssh/sshd_config
Banner /etc/issue
If it does not, this is a finding.SRG-OS-000423-GPOS-00187<GroupDescription></GroupDescription>SLES-12-030100All networked SUSE operating systems must have and implement SSH to protect the confidentiality and integrity of transmitted and received information, as well as information during preparation for transmission.<VulnDiscussion>Without protection of the transmitted information, confidentiality and integrity may be compromised because unprotected communications can be intercepted and either read or altered.
This requirement applies to both internal and external networks and all types of information system components from which information can be transmitted (e.g., servers, mobile devices, notebook computers, printers, copiers, scanners, and facsimile machines). Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification.
Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, logical means (cryptography) do not have to be employed, and vice versa.
Satisfies: SRG-OS-000423-GPOS-00187, SRG-OS-000424-GPOS-00188, SRG-OS-000425-GPOS-00189, SRG-OS-000426-GPOS-00190</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-002418CCI-002420CCI-002421CCI-002422Note: If the system is not networked this requirement is Not Applicable.
Configure the SUSE operating system to implement SSH to protect the confidentiality and integrity of transmitted and received information, as well as information during preparation for transmission.
Install the OpenSSH package on the SUSE operating system with the following command:
# sudo zypper in openssh
Enable the OpenSSH service to start automatically on reboot with the following command:
# sudo systemctl enable sshd.service
For the changes to take effect immediately, start the service with the following command:
# sudo systemctl restart sshd.serviceNote: If the system is not networked this requirement is Not Applicable.
Verify that the SUSE operating system implements SSH to protect the confidentiality and integrity of transmitted and received information, as well as information during preparation for transmission.
Check that the OpenSSH package is installed on the SUSE operating system with the following command:
# zypper se openssh
S | Name | Summary | Type
--+---------------- --+------------------------------------------------------+--------
i | openssh | Secure Shell Client and Server (Remote L-> | package
If the OpenSSH package is not installed, this is a finding.
Check that the OpenSSH service active on the SUSE operating system with the following command:
# systemctl status sshd.service | grep -i "active:"
Active: active (running) since Thu 2017-01-12 15:03:38 UTC; 1 months 4 days ago
If OpenSSH service is not active, this is a finding.SRG-OS-000032-GPOS-00013<GroupDescription></GroupDescription>SLES-12-030110The SUSE operating system must log SSH connection attempts and failures to the server.<VulnDiscussion>Remote access services, such as those providing remote access to network devices and information systems, which lack automated monitoring capabilities, increase risk and make remote user access management difficult at best.
Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, nonorganization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless.
Automated monitoring of remote access sessions allows organizations to detect cyber attacks and also ensure ongoing compliance with remote access policies by auditing connection activities of remote access capabilities, such as Remote Desktop Protocol (RDP), on a variety of information system components (e.g., servers, workstations, notebook computers, smartphones, and tablets).</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000067Configure SSH to verbosely log connection attempts and failed logon attempts to the SUSE operating system.
Add or update the following line in the "/etc/ssh/sshd_config" file:
LogLevel VERBOSE
The SSH service will need to be restarted in order for the changes to take effect.Verify SSH is configured to verbosely log connection attempts and failed logon attempts to the SUSE operating system.
Check that the SSH daemon configuration verbosely logs connection attempts and failed logon attempts to the server with the following command:
# sudo grep -i loglevel /etc/ssh/sshd_config
The output message must contain the following text:
LogLevel VERBOSE
If the output message does not contain "VERBOSE", the LogLevel keyword is missing, or the line is commented out, this is a finding.SRG-OS-000228-GPOS-00088<GroupDescription></GroupDescription>SLES-12-030120The SUSE operating system must be configured to display the Standard Mandatory DoD Notice and Consent Banner immediately prior to, or as part of, SSH logon prompts.<VulnDiscussion>Display of a standardized and approved use notification before granting access to the publicly accessible SUSE operating system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.
System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist.
The banner must be formatted in accordance with applicable DoD policy. Use the following verbiage for SUSE operating systems that can accommodate banners of 1300 characters:
"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.
By using this IS (which includes any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.
-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-001384CCI-001385CCI-001386CCI-001387CCI-001388Configure the SUSE operating system to display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system via the SSH.
Edit the "/etc/ssh/sshd_config" file to uncomment the banner keyword and configure it to point to a file that will contain the logon banner (this file may be named differently or be in a different location if using a version of SSH that is provided by a third-party vendor). An example configuration line is:
Banner=/etc/issue
Either create the file containing the banner or replace the text in the file with the Standard Mandatory DoD Notice and Consent Banner. The DoD required text is:
"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access controls) to protect USG interests -- not for your personal benefit or privacy.
-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."Verify all remote connections via SSH to the SUSE operating system display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system.
Check for the location of the file containing the Standard Mandatory DoD Notice and Consent Banner being used by performing the following command:
# sudo grep -i banner /etc/ssh/sshd_config
Banner=/etc/issue
The command will return the "Banner" keyword and the path of the file that contains the Standard Mandatory DoD Notice and Consent Banner. It is standard practice for this to be stored in "/etc/issue". If the line is commented out, this is a finding.
Check the file that was specified by the "Banner" keyword above and check that it matches the Standard Mandatory DoD Notice and Consent Banner text exactly:
"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access controls) to protect USG interests-not for your personal benefit or privacy.
-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."
If the text in the file does not match the Standard Mandatory DoD Notice and Consent Banner exactly, this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-030130The SUSE operating system must display the date and time of the last successful account logon upon an SSH logon.<VulnDiscussion>Providing users with feedback on when account accesses via SSH last occurred facilitates user recognition and reporting of unauthorized account use.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system to provide users with feedback on when account accesses last occurred.
Add or edit the following lines in the "/etc/ssh/sshd_config" file:
PrintLastLog yesVerify all remote connections via SSH to the SUSE operating system display feedback on when account accesses last occurred.
Check that "PrintLastLog" keyword in the sshd daemon configuration file is used and set to "yes" with the following command:
# sudo grep -i printlastlog /etc/ssh/sshd_config
PrintLastLog yes
If the "PrintLastLog" keyword is set to "no", is missing, or is commented out, this is a finding.SRG-OS-000109-GPOS-00056<GroupDescription></GroupDescription>SLES-12-030140The SUSE operating system must deny direct logons to the root account using remote access via SSH.<VulnDiscussion>To assure individual accountability and prevent unauthorized access, organizational users must be individually identified and authenticated.
A group authenticator is a generic account used by multiple individuals. Use of a group authenticator alone does not uniquely identify individual users. Examples of the group authenticator is the UNIX OS "root" user account, the Windows "Administrator" account, the "sa" account, or a "helpdesk" account.
For example, the UNIX and Windows SUSE operating systems offer a "switch user" capability, allowing users to authenticate with their individual credentials and, when needed, "switch" to the administrator role. This method provides for unique individual authentication prior to using a group authenticator.
Users (and any processes acting on behalf of users) need to be uniquely identified and authenticated for all accesses other than those accesses explicitly identified and documented by the organization, which outlines specific user actions that can be performed on the SUSE operating system without identification or authentication.
Requiring individuals to be authenticated with an individual authenticator prior to using a group authenticator allows for traceability of actions, as well as adding an additional level of protection of the actions that can be taken with group account knowledge.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000770Configure the SUSE operating system to deny direct logons to the root account using remote access via SSH.
Edit the appropriate "/etc/ssh/sshd_config" file, add or uncomment the line for "PermitRootLogin" and set its value to "no" (this file may be named differently or be in a different location):
PermitRootLogin noVerify the SUSE operating system denies direct logons to the root account using remote access via SSH.
Check that SSH denies any user trying to log on directly as root with the following command:
# sudo grep -i permitrootlogin /etc/ssh/sshd_config
PermitRootLogin no
If the "PermitRootLogin" keyword is set to "yes", is missing, or is commented out, this is a finding.SRG-OS-000480-GPOS-00229<GroupDescription></GroupDescription>SLES-12-030150The SUSE operating system must not allow unattended or automatic logon via SSH.<VulnDiscussion>Failure to restrict system access via SSH to authenticated users negatively impacts SUSE operating system security.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system disables unattended or automatic logon via SSH.
Add or edit the following lines in the "/etc/ssh/sshd_config" file:
PermitEmptyPasswords no
PermitUserEnvironment noVerify the SUSE operating system disables unattended or automatic logon via SSH.
Check that unattended or automatic logon via SSH is disabled with the following command:
# sudo egrep '(Permit(.*?)(Passwords|Environment))' /etc/ssh/sshd_config
PermitEmptyPasswords no
PermitUserEnvironment no
If "PermitEmptyPasswords" or "PermitUserEnvironment" keywords are not set to "no", are missing completely, or are commented out, this is a finding.SRG-OS-000033-GPOS-00014<GroupDescription></GroupDescription>SLES-12-030170The SUSE operating system must implement DoD-approved encryption to protect the confidentiality of SSH remote connections.<VulnDiscussion>Without confidentiality protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session.
Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, nonorganization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless.
Encryption provides a means to secure the remote connection to prevent unauthorized access to the data traversing the remote access connection (e.g., RDP), thereby providing a degree of confidentiality. The encryption strength of a mechanism is selected based on the security categorization of the information.
Satisfies: SRG-OS-000033-GPOS-00014, SRG-OS-000120-GPOS-00061, SRG-OS-000125-GPOS-00065, SRG-OS-000250-GPOS-00093, SRG-OS-000393-GPOS-00173</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000068CCI-000366CCI-000803CCI-002890Edit the SSH daemon configuration (/etc/ssh/sshd_config) and remove any ciphers not starting with "aes" and remove any ciphers ending with "cbc". If necessary, add a "Ciphers" line:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr
Restart the SSH daemon:
# sudo systemctl restart sshd.serviceVerify that the SUSE operating system implements DoD-approved encryption to protect the confidentiality of SSH remote connections.
Check the SSH daemon configuration for allowed ciphers with the following command:
# sudo grep -i ciphers /etc/ssh/sshd_config | grep -v '^#'
Ciphers aes128-ctr,aes192-ctr,aes256-ctr
If any ciphers other than "aes128-ctr", "aes192-ctr", or "aes256-ctr" are listed, the "Ciphers" keyword is missing, or the returned line is commented out, this is a finding.SRG-OS-000125-GPOS-00065<GroupDescription></GroupDescription>SLES-12-030180The SUSE operating system SSH daemon must be configured to only use Message Authentication Codes (MACs) employing FIPS 140-2 approved cryptographic hash algorithms.<VulnDiscussion>Without cryptographic integrity protections, information can be altered by unauthorized users without detection.
Remote access (e.g., RDP) is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, nonorganization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless.
Cryptographic mechanisms used for protecting the integrity of information include, for example, signed hash functions using asymmetric cryptography enabling distribution of the public key to verify the hash information while maintaining the confidentiality of the secret key used to generate the hash.
Satisfies: SRG-OS-000125-GPOS-00065, SRG-OS-000394-GPOS-00174</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000877CCI-001453CCI-003123Configure the SUSE operating system SSH daemon to only use MACs that employ FIPS 140-2 approved ciphers.
Edit the "/etc/ssh/sshd_config" file to uncomment or add the line for the "MACs" keyword and set its value to "hmac-sha2-256" and/or "hmac-sha2-512" (The file might be named differently or be in a different location):
MACs hmac-sha2-256,hmac-sha2-512Verify the SUSE operating system SSH daemon is configured to only use MACs that employ FIPS 140-2 approved ciphers.
Check that the SSH daemon is configured to only use MACs that employ FIPS 140-2 approved ciphers with the following command:
# sudo grep -i macs /etc/ssh/sshd_config
MACs hmac-sha2-256,hmac-sha2-512
If any ciphers other than "hmac-sha2-256" or "hmac-sha2-512" are listed or the returned line is commented out, this is a finding.SRG-OS-000126-GPOS-00066<GroupDescription></GroupDescription>SLES-12-030190The SUSE operating system SSH daemon must be configured with a timeout interval.<VulnDiscussion>Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. In addition, quickly terminating an idle session will also free up resources committed by the managed network element.
Terminating network connections associated with communications sessions includes, for example, deallocating associated TCP/IP address/port pairs at the SUSE operating system level, and deallocating networking assignments at the application level if multiple application sessions are using a single SUSE operating system-level network connection. This does not mean that the SUSE operating system terminates all sessions or network access; it only ends the inactive session and releases the resources associated with that session.
Satisfies: SRG-OS-000126-GPOS-00066, SRG-OS-000163-GPOS-00072, SRG-OS-000279-GPOS-00109</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000879CCI-001133CCI-002361Configure the SUSE operating system SSH daemon to timeout idle sessions.
Add or modify (to match exactly) the following line in the "/etc/ssh/sshd_config" file:
ClientAliveInterval 600
The SSH daemon must be restarted in order for any changes to take effect.Verify the SUSE operating system SSH daemon is configured to timeout idle sessions.
Check that the "ClientAliveInterval" parameter is set to a value of "600" with the following command:
# sudo grep -i clientalive /etc/ssh/sshd_config
ClientAliveInterval 600
If "ClientAliveInterval" is not set to "600" in "/etc/ssh/sshd_config", this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-030200The SUSE operating system SSH daemon must be configured to not allow authentication using known hosts authentication.<VulnDiscussion>Configuring this setting for the SSH daemon provides additional assurance that remote logon via SSH will require a password, even in the event of misconfiguration elsewhere.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system SSH daemon to not allow authentication using known hosts authentication.
Add the following line in "/etc/ssh/sshd_config", or uncomment the line and set the value to "yes":
IgnoreUserKnownHosts yesVerify the SUSE operating system SSH daemon is configured to not allow authentication using known hosts authentication.
To determine how the SSH daemon's "IgnoreUserKnownHosts" option is set, run the following command:
# sudo grep -i IgnoreUserKnownHosts /etc/ssh/sshd_config
IgnoreUserKnownHosts yes
If the value is returned as "no", the returned line is commented out, or no output is returned, this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-030210The SUSE operating system SSH daemon public host key files must have mode 0644 or less permissive.<VulnDiscussion>If a public host key file is modified by an unauthorized user, the SSH service may be compromised.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system SSH daemon public host key files have mode "0644" or less permissive.
Note: SSH public key files may be found in other directories on the system depending on the installation.
Change the mode of public host key files under "/etc/ssh" to "0644" with the following command:
# chmod 0644 /etc/ssh/*.key.pubVerify the SUSE operating system SSH daemon public host key files have mode "0644" or less permissive.
Note: SSH public key files may be found in other directories on the system depending on the installation.
The following command will find all SSH public key files on the system:
# sudo find /etc/ssh -name '*.pub' -exec ls -lL {} \;
-rw-r--r-- 1 root wheel 618 Nov 28 06:43 ssh_host_dsa_key.pub
-rw-r--r-- 1 root wheel 347 Nov 28 06:43 ssh_host_key.pub
-rw-r--r-- 1 root wheel 238 Nov 28 06:43 ssh_host_rsa_key.pub
If any file has a mode more permissive than "0644", this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-030220The SUSE operating system SSH daemon private host key files must have mode 0600 or less permissive.<VulnDiscussion>If an unauthorized user obtains the private SSH host key file, the host could be impersonated.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the mode of the SUSE operating system SSH daemon private host key files under "/etc/ssh" to "0600" with the following command:
# chmod 0600 /etc/ssh/ssh_host*keyVerify the SUSE operating system SSH daemon private host key files have mode "0600" or less permissive.
The following command will find all SSH private key files on the system:
# sudo find / -name '*ssh_host*key' -exec ls -lL {} \;
Check the mode of the private host key files under "/etc/ssh" file with the following command:
# ls -lL /etc/ssh/*key
-rw------- 1 root wheel 668 Nov 28 06:43 ssh_host_dsa_key
-rw------- 1 root wheel 582 Nov 28 06:43 ssh_host_key
-rw------- 1 root wheel 887 Nov 28 06:43 ssh_host_rsa_key
If any file has a mode more permissive than "0600", this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-030230The SUSE operating system SSH daemon must perform strict mode checking of home directory configuration files.<VulnDiscussion>If other users have access to modify user-specific SSH configuration files, they may be able to log on to the system as another user.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system SSH daemon performs strict mode checking of home directory configuration files.
Uncomment the "StrictModes" keyword in "/etc/ssh/sshd_config" and set the value to "yes":
StrictModes yesVerify the SUSE operating system SSH daemon performs strict mode checking of home directory configuration files.
Check that the SSH daemon performs strict mode checking of home directory configuration files with the following command:
# sudo grep -i strictmodes /etc/ssh/sshd_config
StrictModes yes
If "StrictModes" is set to "no", is missing, or the returned line is commented out, this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-030240The SUSE operating system SSH daemon must use privilege separation.<VulnDiscussion>SSH daemon privilege separation causes the SSH process to drop root privileges when not needed, which would decrease the impact of software vulnerabilities in the unprivileged section.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system SSH daemon is configured to use privilege separation.
Uncomment the "UsePrivilegeSeparation" keyword in "/etc/ssh/sshd_config" and set the value to "yes":
UsePrivilegeSeparation yesVerify the SUSE operating system SSH daemon is configured to use privilege separation.
Check that the SUSE operating system SSH daemon performs privilege separation with the following command:
# sudo grep -i usepriv /etc/ssh/sshd_config
UsePrivilegeSeparation yes
If the "UsePrivilegeSeparation" keyword is set to "no", is missing, or the returned line is commented out, this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-030250The SUSE operating system SSH daemon must not allow compression or must only allow compression after successful authentication.<VulnDiscussion>If compression is allowed in an SSH connection prior to authentication, vulnerabilities in the compression software could result in compromise of the system from an unauthenticated connection, potentially with root privileges.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system SSH daemon performs compression after a user successfully authenticates.
Uncomment the "Compression" keyword in "/etc/ssh/sshd_config" on the system and set the value to "delayed" or "no":
Compression noVerify the SUSE operating system SSH daemon performs compression after a user successfully authenticates.
Check that the SSH daemon performs compression after a user successfully authenticates with the following command:
# sudo grep -i compression /etc/ssh/sshd_config
Compression delayed
If the "Compression" keyword is set to "yes", is missing, or the returned line is commented out, this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-030260The SUSE operating system SSH daemon must encrypt forwarded remote X connections for interactive users.<VulnDiscussion>Open X displays allow an attacker to capture keystrokes and execute commands remotely.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system SSH daemon to encrypt forwarded X connections for interactive users.
Edit the "/etc/ssh/sshd_config" file to uncomment or add the line for the "X11Forwarding" keyword and set its value to "yes" (this file may be named differently or be in a different location if using a version of SSH that is provided by a third-party vendor):
X11Forwarding yesVerify the SUSE operating system SSH daemon remote X forwarded connections for interactive users are encrypted.
Check that SSH remote X forwarded connections are encrypted with the following command:
# sudo grep -i x11forwarding /etc/ssh/sshd_config
X11Forwarding yes
If the "X11Forwarding" keyword is set to "no", is missing, or is commented out, this is a finding.SRG-OS-000355-GPOS-00143<GroupDescription></GroupDescription>SLES-12-030300The SUSE operating system clock must, for networked systems, be synchronized to an authoritative DoD time source at least every 24 hours.<VulnDiscussion>Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Sources outside the configured acceptable allowance (drift) may be inaccurate.
Synchronizing internal information system clocks provides uniformity of time stamps for information systems with multiple system clocks and systems connected over a network.
Organizations should consider endpoints that may not have regular access to the authoritative time server (e.g., mobile, teleworking, and tactical endpoints).
Satisfies: SRG-OS-000355-GPOS-00143, SRG-OS-000356-GPOS-00144</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-001891CCI-002046Configure the SUSE operating system clock must be configured to synchronize to an authoritative DoD time source when the time difference is greater than one second.
To configure the system clock to synchronize to an authoritative DoD time source at least every 24 hours, edit the file "/etc/ntp.conf". Add or correct the following lines by replacing "[time_source]" with an authoritative DoD time source:
server [time_source] maxpoll 17Verify the SUSE operating system clock must be configured to synchronize to an authoritative DoD time source when the time difference is greater than one second.
Check that the SUSE operating system clock must be configured to synchronize to an authoritative DoD time source when the time difference is greater than one second with the following command:
# sudo grep maxpoll /etc/ntp.conf
server 0.us.pool.ntp.mil maxpoll 17
If nothing is returned or "maxpoll" is greater than "17", this is a finding.
Verify the "ntp.conf" file is configured to an authoritative DoD time source by running the following command:
# sudo grep -i server /etc/ntp.conf
server 0.us.pool.ntp.mil
If the parameter "server" is not set or is not set to an authoritative DoD time source, this is a finding.SRG-OS-000359-GPOS-00146<GroupDescription></GroupDescription>SLES-12-030310The SUSE operating system must be configured to use Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT).<VulnDiscussion>If time stamps are not consistently applied and there is no common time reference, it is difficult to perform forensic analysis.
Time stamps generated by the SUSE operating system include date and time. Time is commonly expressed in UTC, a modern continuation of GMT, or local time with an offset from UTC.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-001890Configure the SUSE operating system is configured to use UTC or GMT.
To configure the system time zone to use UTC or GMT, run the following command, replacing [ZONE] with "UTC" or "GMT".
# sudo timedatectl set-timezone [ZONE]Verify that the SUSE operating system is configured to use UTC or GMT.
Check that the SUSE operating system is configured to use UTC or GMT with the following command:
# timedatectl status | grep -i timezone
Timezone: UTC (UTC, +0000)
If "Timezone" is not set to UTC or GMT, this is a finding.SRG-OS-000433-GPOS-00192<GroupDescription></GroupDescription>SLES-12-030320The SUSE operating system must implement kptr-restrict to prevent the leaking of internal kernel addresses.<VulnDiscussion>Some adversaries launch attacks with the intent of executing code in nonexecutable regions of memory or in memory locations that are prohibited. Security safeguards employed to protect memory include, for example, data execution prevention and address space layout randomization. Data execution prevention safeguards can either be hardware-enforced or software-enforced, with hardware providing the greater strength of mechanism.
Examples of attacks are buffer overflow attacks.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-002824Configure the SUSE operating system to prevent leaking of internal kernel addresses by running the following command:
# sudo echo 1 >> /proc/sys/kernel/kptr_restrict
After the line has been added, the kernel settings from all system configuration files must be reloaded before any of the changes will take effect. Run the following command to reload all of the kernel system configuration files:
# sudo sysctl --systemVerify the SUSE operating system prevents leaking of internal kernel addresses.
Check that the SUSE operating system prevents leaking of internal kernel addresses by running the following command:
# cat /proc/sys/kernel/kptr_restrict
1
If the above output does not return "1", this is a finding.SRG-OS-000433-GPOS-00193<GroupDescription></GroupDescription>SLES-12-030330Address space layout randomization (ASLR) must be implemented by the SUSE operating system to protect memory from unauthorized code execution.<VulnDiscussion>Some adversaries launch attacks with the intent of executing code in nonexecutable regions of memory or in memory locations that are prohibited. Security safeguards employed to protect memory include, for example, data execution prevention and address space layout randomization. Data execution prevention safeguards can either be hardware-enforced or software-enforced, with hardware providing the greater strength of mechanism.
Examples of attacks are buffer overflow attacks.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-002824Configure the SUSE operating system implements address space layout randomization (ASLR).
Remove the "kernel.randomize_va_space" entry found in the "/etc/sysctl.conf" file.
After the line has been removed, the kernel settings from all system configuration files must be reloaded before any of the changes will take effect. Run the following command to reload all of the kernel system configuration files:
# sudo sysctl --system
To check that "kernel.randomize_va_space" has been properly set to "2" after reloading the settings, run the following command:
# cat /proc/sys/kernel/randomize_va_spaceVerify the SUSE operating system implements address space layout randomization (ASLR).
Check that the SUSE operating system implements ASLR by running the following command:
# sudo sysctl kernel.randomize_va_space
kernel.randomize_va_space = 2
If nothing is returned, verify the kernel parameter "randomize_va_space" is equal to "2" in the current process by running the following command:
# cat /proc/sys/kernel/randomize_va_space
2
If "kernel.randomize_va_space" is not set to "2", this is a finding.SRG-OS-000479-GPOS-00224<GroupDescription></GroupDescription>SLES-12-030340The SUSE operating system must off-load rsyslog messages for networked systems in real time and off-load standalone systems at least weekly.<VulnDiscussion>Information stored in one location is vulnerable to accidental or incidental deletion or alteration.
Off-loading is a common process in information systems with limited audit storage capacity.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-001851Configure the SUSE operating system to off-load rsyslog messages for networked systems in real time.
For stand-alone systems establish a procedure to off-load log messages at least once a week.
For networked systems add a "@[Log_Server_IP_Address]" option to every active message label in "/etc/rsyslog.conf" that does not have one. Some examples are listed below:
*.*;mail.none;news.none -/var/log/messages
*.*;mail.none;news.none @192.168.1.101:514
An additional option is to capture all of the log messages and send them to a remote log host:
*.* @@loghost:514Verify that the SUSE operating system must off-load rsyslog messages for networked systems in real time and off-load standalone systems at least weekly.
For stand-alone hosts, verify with the System Administrator that the log files are off-loaded at least weekly.
For networked systems, check that rsyslog is sending log messages to a remote server with the following command:
# sudo grep "\*.\*" /etc/rsyslog.conf | grep "@" | grep -v "^#"
*.*;mail.none;news.none @192.168.1.101:514
If any active message labels in the file do not have a line to send log messages to a remote server, this is a finding.SRG-OS-000142-GPOS-00071<GroupDescription></GroupDescription>SLES-12-030350The SUSE operating system must be configured to use TCP syncookies.<VulnDiscussion>Denial of Service (DoS) is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity.
Managing excess capacity ensures that sufficient capacity is available to counter flooding attacks. Employing increased capacity and service redundancy may reduce the susceptibility to some DoS attacks. Managing excess capacity may include, for example, establishing selected usage priorities, quotas, or partitioning.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-001095Configure the SUSE operating system to use TCP syncookies by running the following command as an administrator:
# sudo sysctl -w net.ipv4.tcp_syncookies=1
If "1" is not the system's default value, add or update the following line in "/etc/sysctl.conf":
net.ipv4.tcp_syncookies = 1Verify the SUSE operating system is configured to use TCP syncookies.
Check to see if syncookies are used with the following command:
# sudo sysctl net.ipv4.tcp_syncookies
net.ipv4.tcp_syncookies = 1
If the value is not set to "1", this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-030360The SUSE operating system must not forward Internet Protocol version 4 (IPv4) source-routed packets.<VulnDiscussion>Source-routed packets allow the source of the packet to suggest that routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routed traffic, such as when IPv4 forwarding is enabled and the system is functioning as a router.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system to the required kernel parameter by adding the following line to "/etc/sysctl.conf" (or modify the line to have the required value):
net.ipv4.conf.all.accept_source_route = 0
Run the following command to apply this value:
# sysctl --systemVerify the SUSE operating system does not accept IPv4 source-routed packets.
Check the value of the accept source route variable with the following command:
# sysctl net.ipv4.conf.all.accept_source_route
net.ipv4.conf.all.accept_source_route = 0
If the returned line does not have a value of "0" this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-030370The SUSE operating system must not forward Internet Protocol version 4 (IPv4) source-routed packets by default.<VulnDiscussion>Source-routed packets allow the source of the packet to suggest that routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routed traffic, such as when IPv4 forwarding is enabled and the system is functioning as a router.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system to the required kernel parameter by adding the following line to "/etc/sysctl.conf" (or modify the line to have the required value):
net.ipv4.conf.default.accept_source_route = 0
Run the following command to apply this value:
# sysctl --systemVerify the SUSE operating system does not accept IPv4 source-routed packets by default.
Check the value of the default accept source route variable with the following command:
# sysctl net.ipv4.conf.default.accept_source_route
net.ipv4.conf.default.accept_source_route = 0
If the returned line does not have a value of "0" this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-030380The SUSE operating system must not respond to Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) echoes sent to a broadcast address.<VulnDiscussion>Responding to broadcast (ICMP) echoes facilitates network mapping and provides a vector for amplification attacks.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system to the required kernel parameter by adding the following line to "/etc/sysctl.conf" (or modify the line to have the required value):
net.ipv4.conf.all.accept_source_route = 0
Run the following command to apply this value:
# sysctl --systemVerify the SUSE operating system does not accept IPv4 source-routed packets.
Check the value of the accept source route variable with the following command:
# sysctl net.ipv4.conf.all.accept_source_route
net.ipv4.conf.all.accept_source_route = 0
If the returned line does not have a value of "0" this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-030390The SUSE operating system must prevent Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirect messages from being accepted.<VulnDiscussion>ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system to the required kernel parameter by adding the following line to "/etc/sysctl.conf" (or modify the line to have the required value):
net.ipv4.icmp_echo_ignore_broadcasts=1
Run the following command to apply this value:
# sysctl --systemVerify the SUSE operating system does not respond to IPv4 ICMP echoes sent to a broadcast address.
Check the value of the "icmp_echo_ignore_broadcasts" variable with the following command:
# sysctl net.ipv4.icmp_echo_ignore_broadcasts
net.ipv4.icmp_echo_ignore_broadcasts=1
If the returned line does not have a value of "1" this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-030400The SUSE operating system must not allow interfaces to accept Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirect messages by default.<VulnDiscussion>ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system ignores IPv4 ICMP redirect messages by adding the following line to "/etc/sysctl.conf" (or modify the line to have the required value):
net.ipv4.conf.all.accept_redirects = 0
Run the following command to apply this value:
# sysctl --systemVerify the SUSE operating system ignores IPv4 ICMP redirect messages.
Check the value of the "accept_redirects" variables with the following command:
# sysctl net.ipv4.conf.all.accept_redirects
net.ipv4.conf.all.accept_redirects = 0
If the returned line does not have a value of "0" this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-030410The SUSE operating system must not allow interfaces to send Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirect messages by default.<VulnDiscussion>ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages contain information from the system's route table, possibly revealing portions of the network topology.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system to not allow interfaces to perform IPv4 ICMP redirects by default.
Set the system to the required kernel parameter by adding the following line to "/etc/sysctl.conf" (or modify the line to have the required value):
net.ipv4.conf.default.send_redirects=0
Run the following command to apply this value:
# sysctl --systemVerify the SUSE operating system does not allow interfaces to perform IPv4 ICMP redirects by default.
Check the value of the "default send_redirects" variables with the following command:
# sysctl net.ipv4.conf.default.send_redirects
net.ipv4.conf.default.send_redirects = 0
If the returned line does not have a value of "0” this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-030420The SUSE operating system must not send Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirects.<VulnDiscussion>ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages contain information from the system's route table, possibly revealing portions of the network topology.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system to not allow interfaces to perform IPv4 ICMP redirects.
Set the system to the required kernel parameter by adding the following line to "/etc/sysctl.conf" (or modify the line to have the required value):
net.ipv4.conf.all.send_redirects=0
Run the following command to apply this value:
# sysctl --systemVerify the SUSE operating system does not send IPv4 ICMP redirect messages.
Check the value of the "all send_redirects" variables with the following command:
# sysctl net.ipv4.conf.default.send_redirects
net.ipv4.conf.default.send_redirects = 0
If the returned line does not have a value of "0” this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-030430The SUSE operating system must not be performing packet forwarding unless the system is a router.<VulnDiscussion>Routing protocol daemons are typically used on routers to exchange network topology information with other routers. If this software is used when not required, system network information may be unnecessarily transmitted across the network.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system to the required kernel parameter upon boot by adding the following line to "/etc/sysctl.conf" (or modify the line to have the required value):
net.ipv4.ip_forward=0
Run the following command to apply this value:
# sysctl --systemVerify the SUSE operating system is not performing packet forwarding, unless the system is a router.
Check to see if IP forwarding is enabled using the following command:
# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0
If IP forwarding value is "1" and the system is hosting any application, database, or web servers, this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-030440The SUSE operating system must not have network interfaces in promiscuous mode unless approved and documented.<VulnDiscussion>Network interfaces in promiscuous mode allow for the capture of all network traffic visible to the system. If unauthorized individuals can access these applications, it may allow then to collect information such as logon IDs, passwords, and key exchanges between systems.
If the system is being used to perform a network troubleshooting function, the use of these tools must be documented with the Information System Security Officer (ISSO) and restricted to only authorized personnel.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system network interfaces to turn off promiscuous mode unless approved by the ISSO and documented.
Set the promiscuous mode of an interface to off with the following command:
# ip link set dev <devicename> promisc offVerify the SUSE operating system network interfaces are not in promiscuous mode unless approved by the ISSO and documented.
Check for the status with the following command:
# ip link | grep -i promisc
If network interfaces are found on the system in promiscuous mode and their use has not been approved by the ISSO and documented, this is a finding.SRG-OS-000299-GPOS-00117<GroupDescription></GroupDescription>SLES-12-030450The SUSE operating system wireless network adapters must be disabled unless approved and documented.<VulnDiscussion>Without protection of communications with wireless peripherals, confidentiality and integrity may be compromised because unprotected communications can be intercepted and either read, altered, or used to compromise the SUSE operating system.
This requirement applies to wireless peripheral technologies (e.g., wireless mice, keyboards, displays, etc.) used with A SUSE operating system. Wireless peripherals (e.g., Wi-Fi/Bluetooth/IR Keyboards, Mice, and Pointing Devices and Near Field Communications [NFC]) present a unique challenge by creating an open, unsecured port on a computer. Wireless peripherals must meet DoD requirements for wireless data transmission and be approved for use by the AO. Even though some wireless peripherals, such as mice and pointing devices, do not ordinarily carry information that need to be protected, modification of communications with these wireless peripherals may be used to compromise the SUSE operating system. Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification.
Protecting the confidentiality and integrity of communications with wireless peripherals can be accomplished by physical means (e.g., employing physical barriers to wireless radio frequencies) 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. If the wireless peripheral is only passing telemetry data, encryption of the data may not be required.
Satisfies: SRG-OS-000299-GPOS-00117, SRG-OS-000300-GPOS-00118, SRG-OS-000481-GPOS-000481</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-001443CCI-001444CCI-002418Configure the SUSE operating system to disable all wireless network interfaces with the following command:
For each interface of type wireless, bring the interface into "down" state:
# wicked ifdown wlan0
For each interface of type wireless with a configuration of type "compat:suse:", remove the associated file:
# rm /etc/sysconfig/network/ifcfg-wlan0
For each interface of type wireless, for each configuration of type "wicked:xml:", remove the associated file or remove the interface configuration from the file.
# rm /etc/wicked/ifconfig/wlan0.xmlVerify that the SUSE operating system has no wireless network adapters enabled.
Check that there are no wireless interfaces configured on the system with the following command:
# wicked show all
lo up
link: #1, state up
type: loopback
config: compat:suse:/etc/sysconfig/network/ifcfg-lo
leases: ipv4 static granted
leases: ipv6 static granted
addr: ipv4 127.0.0.1/8 [static]
addr: ipv6 ::1/128 [static]
eth0 up
link: #2, state up, mtu 1500
type: ethernet, hwaddr 06:00:00:00:00:01
config: compat:suse:/etc/sysconfig/network/ifcfg-eth0
leases: ipv4 dhcp granted
leases: ipv6 dhcp granted, ipv6 auto granted
addr: ipv4 10.0.0.100/16 [dhcp]
route: ipv4 default via 10.0.0.1 proto dhcp
wlan0 up
link: #3, state up, mtu 1500
type: wireless, hwaddr 06:00:00:00:00:02
config: wicked:xml:/etc/wicked/ifconfig/wlan0.xml
leases: ipv4 dhcp granted
addr: ipv4 10.0.0.101/16 [dhcp]
route: ipv4 default via 10.0.0.1 proto dhcp
If a wireless interface is configured it must be documented and approved by the local Authorizing Official.
If a wireless interface is configured and has not been documented and approved, this is a finding.SRG-OS-000375-GPOS-00160<GroupDescription></GroupDescription>SLES-12-030500The SUSE operating system must have the packages required for multifactor authentication to be installed.<VulnDiscussion>Using an authentication device, such as a CAC or token that is separate from the information system, ensures that even if the information system is compromised, that compromise will not affect credentials stored on the authentication device.
Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification card and the DoD Common Access Card.
A privileged account is defined as an information system account with authorizations of a privileged user.
Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless.
This requirement only applies to components where this is specific to the function of the device or has the concept of an organizational user (e.g., VPN, proxy capability). This does not apply to authentication for the purpose of configuring the device itself (management).
Satisfies: SRG-OS-000375-GPOS-00160, SRG-OS-000376-GPOS-00161, SRG-OS-000377-GPOS-00162</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-001948CCI-001953CCI-001954Configure the SUSE operating system to implement multifactor authentication by installing the required packages.
Install the packages required to support multifactor authentication with the following commands:
#zypper install pam_pkcs11
#zypper install mozilla-nss
#zypper install mozilla-nss-tools
#zypper install pcsc-ccid
#zypper install pcsc-lite
#zypper install pcsc-tools
#zypper install opensc
#zypper install coolkey
Additional information on the configuration of multifactor authentication on the SUSE operating system can be found at https://www.suse.com/communities/blog/configuring-smart-card-authentication-suse-linux-enterprise/Verify the SUSE operating system has the packages required for multifactor authentication installed.
Check for the presence of the packages required to support multifactor authentication with the following commands:
# zypper se pam_pkcs11
i | pam_pkcs11 | PKCS #11 PAM Module | package
# zypper se mozilla-nss
i | mozilla-nss | Network Security Services | package
i | mozilla-nss-tools | Tools for developing, debugging, and managing applications t-> | package
# zypper se pcsc
i | pcsc-ccid | PCSC Driver for CCID Based Smart Card Readers and GemPC Twin -> | package
i | pcsc-lite | PCSC Smart Cards Library | package
i | pcsc-tools | PCSC Tools | package
# zypper se opensc
i | opensc | Smart Card Utilities | package
# zypper info coolkey | grep -i installed
Installed: Yes
If any of the packages required for multifactor authentication are not installed, this is a finding.SRG-OS-000375-GPOS-00160<GroupDescription></GroupDescription>SLES-12-030510The SUSE operating system must implement certificate status checking for multifactor authentication.<VulnDiscussion>Using an authentication device, such as a CAC or token that is separate from the information system, ensures that even if the information system is compromised, that compromise will not affect credentials stored on the authentication device.
Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification card and the DoD Common Access Card.
A privileged account is defined as an information system account with authorizations of a privileged user.
Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless.
This requirement only applies to components where this is specific to the function of the device or has the concept of an organizational user (e.g., VPN, proxy capability). This does not apply to authentication for the purpose of configuring the device itself (management).
Requires further clarification from NIST.
Satisfies: SRG-OS-000375-GPOS-00160, SRG-OS-000376-GPOS-00161, SRG-OS-000377-GPOS-00162</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-001948CCI-001953CCI-001954Configure the SUSE operating system to certificate status checking for PKI authentication.
Modify all of the cert_policy lines in "/etc/pam_pkcs11/pam_pkcs11.conf" to include "ocsp_on".
Note: OSCP allows sending request for certificate status information. Additional certificate validation polices are permitted.
Additional information on the configuration of multifactor authentication on the SUSE operating system can be found at https://www.suse.com/communities/blog/configuring-smart-card-authentication-suse-linux-enterprise/Verify the SUSE operating system implements certificate status checking for multifactor authentication.
Check that certificate status checking for multifactor authentication is implemented with the following command:
# grep use_pkcs11_module /etc/pam_pkcs11/pam_pkcs11.conf | awk '/pkcs11_module coolkey {/,/}/' /etc/pam_pkcs11/pam_pkcs11.conf | grep cert_policy
cert_policy = ca,oscp_on,signature,crl_auto;
If "cert_policy" is not set to include "ocsp", this is a finding.SRG-OS-000068-GPOS-00036<GroupDescription></GroupDescription>SLES-12-030520The SUSE operating system must implement multifactor authentication for access to privileged accounts via pluggable authentication modules (PAM).<VulnDiscussion>Using an authentication device, such as a CAC or token that is separate from the information system, ensures that even if the information system is compromised, that compromise will not affect credentials stored on the authentication device.
Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification card and the DoD Common Access Card.
A privileged account is defined as an information system account with authorizations of a privileged user.
Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless.
This requirement only applies to components where this is specific to the function of the device or has the concept of an organizational user (e.g., VPN, proxy capability). This does not apply to authentication for the purpose of configuring the device itself (management).
Satisfies: SRG-OS-000068-GPOS-00036, SRG-OS-000105-GPOS-00052, SRG-OS-000106-GPOS-00053, SRG-OS-000107-GPOS-00054, SRG-OS-000108-GPOS-00055, SRG-OS-000375-GPOS-00160, SRG-OS-000375-GPOS-00161, SRG-OS-000375-GPOS-00162</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000187CCI-000765CCI-000766CCI-000767CCI-000768CCI-001948CCI-001953CCI-001954Configure the SUSE operating system to implement multifactor authentication for remote access to privileged accounts via PAM.
Add or update "pam_pkcs11.so" in "/etc/pam.d/common-auth" to match the following line:
auth sufficient pam_pkcs11.soVerify the SUSE operating system implements multifactor authentication for remote access to privileged accounts via pluggable authentication modules (PAM).
Check that the "pam_pkcs11.so" option is configured in the "/etc/pam.d/common-auth" file with the following command:
# grep pam_pkcs11.so /etc/pam.d/common-auth
auth sufficient pam_pkcs11.so
If "pam_pkcs11.so" is not set in "/etc/pam.d/common-auth", this is a finding.SRG-OS-000066-GPOS-00034<GroupDescription></GroupDescription>SLES-12-030530The SUSE operating system, for PKI-based authentication, must validate certificates by constructing a certification path (which includes status information) to an accepted trust anchor.<VulnDiscussion>Without path validation, an informed trust decision by the relying party cannot be made when presented with any certificate not already explicitly trusted.
A trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates, and DNSSEC.
When there is a chain of trust, usually the top entity to be trusted becomes the trust anchor; it can be, for example, a Certification Authority (CA). A certification path starts with the subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted CA.
This requirement verifies that a certification path to an accepted trust anchor is used for certificate validation and that the path includes status information. Path validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted. Status information for certification paths includes certificate revocation lists or online certificate status protocol responses. Validation of the certificate status information is out of scope for this requirement.
Satisfies: SRG-OS-000066-GPOS-00034, SRG-OS-000384-GPOS-00167</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000185CCI-001991Configure the SUSE operating system, for PKI-based authentication, to validate certificates by constructing a certification path (which includes status information) to an accepted trust anchor.
Modify all of the cert_policy lines in "/etc/pam_pkcs11/pam_pkcs11.conf" to include "ca":
cert_policy = ca,signature,oscp_on;
Note: Additional certificate validation polices are permitted.
Additional information on the configuration of multifactor authentication on the SUSE operating system can be found at https://www.suse.com/communities/blog/configuring-smart-card-authentication-suse-linux-enterprise/Verify the SUSE operating system, for PKI-based authentication, had valid certificates by constructing a certification path (which includes status information) to an accepted trust anchor.
Check that the certification path to an accepted trust anchor for multifactor authentication is implemented with the following command:
# grep use_pkcs11_module /etc/pam_pkcs11/pam_pkcs11.conf | awk '/pkcs11_module coolkey {/,/}/' /etc/pam_pkcs11/pam_pkcs11.conf | grep cert_policy
cert_policy = ca,oscp_on,signature,crl_auto;
If "cert_policy" is not set to include "ca", this is a finding.SRG-OS-000329-GPOS-00128<GroupDescription></GroupDescription>SLES-12-010131Accounts on the SUSE operating system that are subject to three unsuccessful logon attempts within 15 minutes must be locked for the maximum configurable period.<VulnDiscussion>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.
Satisfies: SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-002238Configure the operating system to lock an account for the maximum period when three unsuccessful logon attempts in 15 minutes are made.
Modify the first three lines of the auth section and the first line of the account section of the "/etc/pam.d/system-auth" and "/etc/pam.d/password-auth" files to match the following lines:
auth required pam_faillock.so preauth silent audit deny=3 even_deny_root fail_interval=900 unlock_time=900
auth sufficient pam_unix.so try_first_pass
auth [default=die] pam_faillock.so authfail audit deny=3 even_deny_root fail_interval=900 unlock_time=900
account required pam_faillock.so
Note: Manual changes to the listed files may be overwritten by the "authconfig" program. The "authconfig" program should not be used to update the configurations listed in this requirement.Verify the operating system automatically locks an account for the maximum period for which the system can be configured.
Check that the system locks an account for the maximum period after three unsuccessful logon attempts within a period of 15 minutes with the following command:
# grep pam_faillock.so /etc/pam.d/password-auth
auth required pam_faillock.so preauth silent audit deny=3 even_deny_root fail_interval=900 unlock_time=900
auth [default=die] pam_faillock.so authfail audit deny=3 even_deny_root fail_interval=900 unlock_time=900
account required pam_faillock.so
If the "unlock_time" parameter is not set to "0", "never", or is set to a value less than "900" on both "auth" lines with the "pam_faillock.so" module, or is missing from these lines, this is a finding.
Note: The maximum configurable value for "unlock_time" is "604800".SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-010231The SUSE operating system must not be configured to allow blank or null passwords.<VulnDiscussion> 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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system to not allow blank or null passwords.
Remove any instances of the "nullok" option in "/etc/pam.d/system-auth" and "/etc/pam.d/password-auth" to prevent logons with empty passwords.Verify the SUSE operating is not configured to allow blank or null passwords.
Check that blank or null passwords cannot be used by running the following command:
# grep pam_unix.so /etc/pam.d/* | grep nullok
If this produces any output, it may be possible to log on with accounts with empty passwords.
If null passwords can be used, this is a finding.SRG-OS-000163-GPOS-00072<GroupDescription></GroupDescription>SLES-12-030191The SUSE operating system for all network connections associated with SSH traffic must immediately terminate at the end of the session or after 10 minutes of inactivity.<VulnDiscussion>Automatic session termination addresses the termination of user-initiated logical sessions in contrast to the termination of network connections that are associated with communications sessions (i.e., network disconnect). A logical session (for local, network, and remote access) is initiated whenever a user (or process acting on behalf of a user) accesses an organizational information system. Such user sessions can be terminated (and thus terminate user access) without terminating network sessions.
Session termination terminates all processes associated with a user's logical session except those processes that are specifically created by the user (i.e., session owner) to continue after the session is terminated.
Conditions or trigger events requiring automatic session termination can include, for example, organization-defined periods of user inactivity, targeted responses to certain types of incidents, and time-of-day restrictions on information system use.
This capability is typically reserved for specific Ubuntu operating system functionality where the system owner, data owner, or organization requires additional assurance.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000879CCI-001133CCI-002361Configure the SUSE operating system to automatically terminate all network connections associated with SSH traffic at the end of a session or after a "10" minute period of inactivity.
Modify or append the following lines in the "/etc/ssh/sshd_config" file:
ClientAliveCountMax 1
In order for the changes to take effect, the SSH daemon must be restarted.
# sudo systemctl restart sshd.serviceVerify that all network connections associated with SSH traffic are automatically terminated at the end of the session or after "10" minutes of inactivity.
Check that the "ClientAliveInterval" variable is set to a value of "600" or less by performing the following command:
# sudo grep -i clientalive /etc/ssh/sshd_config
ClientAliveInterval 600
ClientAliveCountMax 1
If "ClientAliveCountMax" does not exist or "ClientAliveCountMax" is not set to a value of "1" or greater in "/etc/ssh/sshd_config", or the line is commented out, this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-030361The SUSE operating system must not forward Internet Protocol version 6 (IPv6) source-routed packets.<VulnDiscussion>Source-routed packets allow the source of the packet to suggest that routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routed traffic, such as when IPv4 forwarding is enabled and the system is functioning as a router.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system to not accept IPv6 source-routed packets by adding the following line to "/etc/sysctl.conf" (or modify the line to have the required value):
net.ipv6.conf.all.accept_source_route = 0
Run the following command to apply this value:
# sysctl --systemVerify the SUSE operating system does not accept IPv6 source-routed packets.
Check the value of the accept source route variable with the following command:
# sudo sysctl net.ipv6.conf.all.accept_source_route
net.ipv6.conf.all.accept_source_route = 0
If the returned line does not have a value of "0", this is a finding.SRG-OS-000480-GPOS-00227<GroupDescription></GroupDescription>SLES-12-030401The SUSE operating system must not allow interfaces to accept Internet Protocol version 6 (IPv6) Internet Control Message Protocol (ICMP) redirect messages by default.<VulnDiscussion>ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target SLES 12DISADPMS TargetSLES 122903CCI-000366Configure the SUSE operating system to not allow IPv6 ICMP redirect messages by default.
Set the system to the required kernel parameter by adding the following line to "/etc/sysctl.conf" (or modify the line to have the required value):
net.ipv6.conf.default.accept_redirects=0
Run the following command to apply this value:
# sysctl –systemVerify the SUSE operating system does not allow IPv6 ICMP redirect messages by default.
Check the value of the "default accept_redirects" variables with the following command:
# sudo sysctl net.ipv6.conf.default.accept_redirects
net.ipv6.conf.default.accept_redirects = 0
If the returned line does not have a value of "0", this is a finding.