Group
Guide to the Secure Configuration of SUSE Linux Enterprise 15
Group contains 116 groups and 378 rules |
Group
System Settings
Group contains 61 groups and 219 rules |
[ref]
Contains rules that check correct system settings. |
Group
Installing and Maintaining Software
Group contains 7 groups and 21 rules |
[ref]
The following sections contain information on
security-relevant choices during the initial operating system
installation process and the setup of software
updates. |
Group
System and Software Integrity
Group contains 2 groups and 4 rules |
[ref]
System and software integrity can be gained by installing antivirus, increasing
system encryption strength with FIPS, verifying installed software, enabling SELinux,
installing an Intrusion Prevention System, etc. However, installing or enabling integrity
checking tools cannot prevent intrusions, but they can detect that an intrusion
may have occurred. Requirements for integrity checking may be highly dependent on
the environment in which the system will be used. Snapshot-based approaches such
as AIDE may induce considerable overhead in the presence of frequent software updates. |
Group
Software Integrity Checking
Group contains 1 group and 3 rules |
[ref]
Both the AIDE (Advanced Intrusion Detection Environment)
software and the RPM package management system provide
mechanisms for verifying the integrity of installed software.
AIDE uses snapshots of file metadata (such as hashes) and compares these
to current system files in order to detect changes.
The RPM package management system can conduct integrity
checks by comparing information in its metadata database with
files installed on the system. |
Group
Verify Integrity with AIDE
Group contains 3 rules |
[ref]
AIDE conducts integrity checks by comparing information about
files with previously-gathered information. Ideally, the AIDE database is
created immediately after initial system configuration, and then again after any
software update. AIDE is highly configurable, with further configuration
information located in /usr/share/doc/aide-VERSION
. |
Rule
Install AIDE
[ref] | The aide package can be installed with the following command:
$ sudo zypper install aide
| Rationale: | The AIDE package must be installed if it is to be available for integrity checking. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_aide_installed | Identifiers: | CCE-83289-9 | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 2, 3, 5, 7, 8, 9 | cjis | 5.10.1.3 | cobit5 | APO01.06, BAI01.06, BAI02.01, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS04.07, DSS05.02, DSS05.03, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | disa | CCI-002696, CCI-001744 | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4 | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 4.1, SR 6.2, SR 7.6 | ism | 1034, 1288, 1341, 1417 | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.1, A.12.4.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.14.2.7, A.15.2.1, A.8.2.3 | nist | CM-6(a) | nist-csf | DE.CM-1, DE.CM-7, PR.DS-1, PR.DS-6, PR.DS-8, PR.IP-1, PR.IP-3 | pcidss | Req-11.5 | os-srg | SRG-OS-000445-GPOS-00199 | stigid | SLES-15-010419 | cis | 1.4.1 | anssi | R76, R79 | pcidss4 | 11.5.2 | stigref | SV-255922r958794_rule |
| |
|
Rule
Build and Test AIDE Database
[ref] | Run the following command to generate a new database:
$ sudo /usr/bin/aide --init
By default, the database will be written to the file
/var/lib/aide/aide.db.new .
Storing the database, the configuration file /etc/aide.conf , and the binary
/usr/bin/aide
(or hashes of these files), in a secure location (such as on read-only media) provides additional assurance about their integrity.
The newly-generated database can be installed as follows:
$ sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db
To initiate a manual check, run the following command:
$ sudo /usr/bin/aide --check
If this check produces any unexpected output, investigate. | Rationale: | For AIDE to be effective, an initial database of "known-good" information about files
must be captured and it should be able to be verified against the installed files. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_aide_build_database | Identifiers: | CCE-85787-0 | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 2, 3, 5, 7, 8, 9 | cjis | 5.10.1.3 | cobit5 | APO01.06, BAI01.06, BAI02.01, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS04.07, DSS05.02, DSS05.03, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | disa | CCI-002696, CCI-001744 | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4 | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 4.1, SR 6.2, SR 7.6 | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.1, A.12.4.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.14.2.7, A.15.2.1, A.8.2.3 | nist | CM-6(a) | nist-csf | DE.CM-1, DE.CM-7, PR.DS-1, PR.DS-6, PR.DS-8, PR.IP-1, PR.IP-3 | pcidss | Req-11.5 | os-srg | SRG-OS-000445-GPOS-00199 | stigid | SLES-15-010419 | cis | 1.4.1 | anssi | R76, R79 | pcidss4 | 11.5.2 | stigref | SV-255922r958794_rule |
| |
|
Rule
Configure Systemd Timer Execution of AIDE
[ref] | At a minimum, AIDE should be configured to run a weekly scan.
To implement a systemd service and a timer unit to run the service periodically:
For example, if a systemd timer is expected to be started every day at 5AM
OnCalendar=*-*-* 05:00:0
[Timer] section in the timer unit and
a Unit section starting the AIDE check service unit should be referred. | Rationale: | AIDE provides a means to check if unauthorized changes are made to the system.
AIDE itself does not setup a periodic execution, so in order to detect unauthorized
changes a systemd service to run the check and a systemd timer to take care
of periodical execution of that systemd service should be defined. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_aide_periodic_checking_systemd_timer | Identifiers: | CCE-92516-4 | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 2, 3, 5, 7, 8, 9 | cjis | 5.10.1.3 | cobit5 | APO01.06, BAI01.06, BAI02.01, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS04.07, DSS05.02, DSS05.03, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | disa | CCI-001744, CCI-002699, CCI-002702 | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4 | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 4.1, SR 6.2, SR 7.6 | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.1, A.12.4.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.14.2.7, A.15.2.1, A.8.2.3 | nist | SI-6(d) | nist-csf | DE.CM-1, DE.CM-7, PR.DS-1, PR.DS-6, PR.DS-8, PR.IP-1, PR.IP-3 | pcidss | Req-11.5 | os-srg | SRG-OS-000363-GPOS-00150, SRG-OS-000446-GPOS-00200, SRG-OS-000447-GPOS-00201 | stigid | SLES-15-010570 | cis | 1.4.2 | anssi | R76 | pcidss4 | 11.5.2 | stigref | SV-234864r958948_rule |
| |
|
Rule
Disable Prelinking
[ref] | The prelinking feature changes binaries in an attempt to decrease their startup
time. In order to disable it, change or add the following line inside the file
/etc/sysconfig/prelink :
PRELINKING=no
Next, run the following command to return binaries to a normal, non-prelinked state:
$ sudo /usr/sbin/prelink -ua
| Rationale: | Because the prelinking feature changes binaries, it can interfere with the
operation of certain software and/or modes such as AIDE, FIPS, etc. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_disable_prelink | Identifiers: | CCE-91341-8 | References: | cis-csc | 11, 13, 14, 2, 3, 9 | cjis | 5.10.1.3 | cobit5 | APO01.06, BAI02.01, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS04.07, DSS05.03, DSS06.02, DSS06.06 | cui | 3.13.11 | disa | CCI-000803, CCI-002450 | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4 | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 4.1, SR 7.6 | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.8.2.3 | nerc-cip | CIP-003-8 R4.2, CIP-007-3 R5.1 | nist | SC-13, CM-6(a) | nist-csf | PR.DS-1, PR.DS-6, PR.DS-8, PR.IP-1 | pcidss | Req-11.5 | cis | 1.6.4 |
| |
|
Group
Disk Partitioning
Group contains 7 rules |
[ref]
To ensure separation and protection of data, there
are top-level system directories which should be placed on their
own physical partition or logical volume. The installer's default
partitioning scheme creates separate logical volumes for
/ , /boot , and swap .
- If starting with any of the default layouts, check the box to
\"Review and modify partitioning.\" This allows for the easy creation
of additional logical volumes inside the volume group already
created, though it may require making
/ 's logical volume smaller to
create space. In general, using logical volumes is preferable to
using partitions because they can be more easily adjusted
later. - If creating a custom layout, create the partitions mentioned in
the previous paragraph (which the installer will require anyway),
as well as separate ones described in the following sections.
If a system has already been installed, and the default
partitioning
scheme was used, it is possible but nontrivial to
modify it to create separate logical volumes for the directories
listed above. The Logical Volume Manager (LVM) makes this possible. |
Rule
Ensure /dev/shm is configured
[ref] | The /dev/shm is a traditional shared memory concept.
One program will create a memory portion, which other processes
(if permitted) can access. If /dev/shm is not configured,
tmpfs will be mounted to /dev/shm by systemd. Warning:
This rule does not have a remedation.
It is expected that this will be managed by systemd and will be a tmpfs partition. | Rationale: | Any user can upload and execute files inside the /dev/shm similar to
the /tmp partition. Configuring /dev/shm allows an administrator
to set the noexec option on the mount, making /dev/shm useless for an attacker to
install executable code. It would also prevent an attacker from establishing a
hardlink to a system setuid program and wait for it to be updated. Once the program
was updated, the hardlink would be broken and the attacker would have his own copy
of the program. If the program happened to have a security vulnerability, the attacker
could continue to exploit the known flaw. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_partition_for_dev_shm | Identifiers: | CCE-92477-9 | References: | | |
|
Rule
Ensure /home Located On Separate Partition
[ref] | If user home directories will be stored locally, create a separate partition
for /home at installation time (or migrate it later using LVM). If
/home will be mounted from another system such as an NFS server, then
creating a separate partition is not necessary at installation time, and the
mountpoint can instead be configured later. | Rationale: | Ensuring that /home is mounted on its own partition enables the
setting of more restrictive mount options, and also helps ensure that
users cannot trivially fill partitions used for log or audit data storage. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_partition_for_home | Identifiers: | CCE-85639-3 | References: | cis-csc | 12, 15, 8 | cobit5 | APO13.01, DSS05.02 | disa | CCI-000366 | isa-62443-2013 | SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6 | iso27001-2013 | A.13.1.1, A.13.2.1, A.14.1.3 | nist | CM-6(a), SC-5(2) | nist-csf | PR.PT-4 | os-srg | SRG-OS-000480-GPOS-00227 | stigid | SLES-15-040200 | cis | 1.1.17 | anssi | R28 | stigref | SV-235004r991589_rule |
| |
|
Rule
Ensure /tmp Located On Separate Partition
[ref] | The /tmp directory is a world-writable directory used
for temporary file storage. Ensure it has its own partition or
logical volume at installation time, or migrate it using LVM. | Rationale: | The /tmp partition is used as temporary storage by many programs.
Placing /tmp in its own partition enables the setting of more
restrictive mount options, which can help protect programs which use it. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_partition_for_tmp | Identifiers: | CCE-91179-2 | References: | cis-csc | 12, 15, 8 | cobit5 | APO13.01, DSS05.02 | disa | CCI-000366 | isa-62443-2013 | SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6 | iso27001-2013 | A.13.1.1, A.13.2.1, A.14.1.3 | nist | CM-6(a), SC-5(2) | nist-csf | PR.PT-4 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 1.1.2 |
| |
|
Rule
Ensure /var Located On Separate Partition
[ref] | The /var directory is used by daemons and other system
services to store frequently-changing data. Ensure that /var has its own partition
or logical volume at installation time, or migrate it using LVM. | Rationale: | Ensuring that /var is mounted on its own partition enables the
setting of more restrictive mount options. This helps protect
system services such as daemons or other programs which use it.
It is not uncommon for the /var directory to contain
world-writable directories installed by other software packages. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_partition_for_var | Identifiers: | CCE-85640-1 | References: | cis-csc | 12, 15, 8 | cobit5 | APO13.01, DSS05.02 | disa | CCI-000366 | isa-62443-2013 | SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6 | iso27001-2013 | A.13.1.1, A.13.2.1, A.14.1.3 | nist | CM-6(a), SC-5(2) | nist-csf | PR.PT-4 | os-srg | SRG-OS-000480-GPOS-00227 | stigid | SLES-15-040210 | cis | 1.1.10 | anssi | R28 | stigref | SV-235005r991589_rule |
| |
|
Rule
Ensure /var/log Located On Separate Partition
[ref] | System logs are stored in the /var/log directory.
Ensure that /var/log has its own partition or logical
volume at installation time, or migrate it using LVM. | Rationale: | Placing /var/log in its own partition
enables better separation between log files
and other files in /var/ . | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_partition_for_var_log | Identifiers: | CCE-91181-8 | References: | cis-csc | 1, 12, 14, 15, 16, 3, 5, 6, 8 | cobit5 | APO11.04, APO13.01, BAI03.05, DSS05.02, DSS05.04, DSS05.07, MEA02.01 | disa | CCI-000366 | isa-62443-2009 | 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6 | iso27001-2013 | A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3 | nerc-cip | CIP-007-3 R6.5 | nist | CM-6(a), AU-4, SC-5(2) | nist-csf | PR.PT-1, PR.PT-4 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 1.1.15 | anssi | R28 |
| |
|
Rule
Ensure /var/log/audit Located On Separate Partition
[ref] | Audit logs are stored in the /var/log/audit directory.
Ensure that /var/log/audit has its own partition or logical
volume at installation time, or migrate it using LVM.
Make absolutely certain that it is large enough to store all
audit logs that will be created by the auditing daemon. | Rationale: | Placing /var/log/audit in its own partition
enables better separation between audit files
and other files, and helps ensure that
auditing cannot be halted due to the partition running out
of space. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_partition_for_var_log_audit | Identifiers: | CCE-85618-7 | References: | cis-csc | 1, 12, 13, 14, 15, 16, 2, 3, 5, 6, 8 | cobit5 | APO11.04, APO13.01, BAI03.05, BAI04.04, DSS05.02, DSS05.04, DSS05.07, MEA02.01 | disa | CCI-000366, CCI-001849 | hipaa | 164.312(a)(2)(ii) | isa-62443-2009 | 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.2, SR 7.6 | iso27001-2013 | A.12.1.3, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.17.2.1 | nerc-cip | CIP-007-3 R6.5 | nist | CM-6(a), AU-4, SC-5(2) | nist-csf | PR.DS-4, PR.PT-1, PR.PT-4 | ospp | FMT_SMF_EXT.1 | os-srg | SRG-OS-000341-GPOS-00132, SRG-OS-000480-GPOS-00227 | app-srg-ctr | SRG-APP-000357-CTR-000800 | stigid | SLES-15-030810 | cis | 1.1.16 | anssi | R71 | stigref | SV-234980r991589_rule |
| |
|
Rule
Ensure /var/tmp Located On Separate Partition
[ref] | The /var/tmp directory is a world-writable directory used
for temporary file storage. Ensure it has its own partition or
logical volume at installation time, or migrate it using LVM. | Rationale: | The /var/tmp partition is used as temporary storage by many programs.
Placing /var/tmp in its own partition enables the setting of more
restrictive mount options, which can help protect programs which use it. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_partition_for_var_tmp | Identifiers: | CCE-91182-6 | References: | | |
|
Group
GNOME Desktop Environment
Group contains 3 rules |
[ref]
GNOME is a graphical desktop environment bundled with many Linux distributions that
allow users to easily interact with the operating system graphically rather than
textually. The GNOME Graphical Display Manager (GDM) provides login, logout, and user
switching contexts as well as display server management.
GNOME is developed by the GNOME Project and is considered the default
Red Hat Graphical environment.
For more information on GNOME and the GNOME Project, see https://www.gnome.org. |
Rule
Remove the GDM Package Group
[ref] |
By removing the gdm package, the system no longer has GNOME installed
installed. If X Windows is not installed then the system cannot boot into graphical user mode.
This prevents the system from being accidentally or maliciously booted into a graphical.target
mode. To do so, run the following command:
$ sudo yum remove gdm
| Rationale: | Unnecessary service packages must not be installed to decrease the attack surface of the system.
A graphical environment is unnecessary for certain types of systems including a virtualization
hypervisor. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_gdm_removed | Identifiers: | CCE-92502-4 | References: | nist | CM-7(a), CM-7(b), CM-6(a) | os-srg | SRG-OS-000480-GPOS-00227 | cis | 1.10 |
| |
|
Rule
Make sure that the dconf databases are up-to-date with regards to respective keyfiles
[ref] | By default, DConf uses a binary database as a data backend.
The system-level database is compiled from keyfiles in the /etc/dconf/db/
directory by the dconf update command. More specifically, content present
in the following directories:
/etc/dconf/db/gdm.d
/etc/dconf/db/local.d
| Rationale: | Unlike text-based keyfiles, the binary database is impossible to check by OVAL.
Therefore, in order to evaluate dconf configuration, both have to be true at the same time -
configuration files have to be compliant, and the database needs to be more recent than those keyfiles,
which gives confidence that it reflects them. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_dconf_db_up_to_date | Identifiers: | CCE-83288-1 | References: | | |
|
Rule
Configure GNOME3 DConf User Profile
[ref] | By default, DConf provides a standard user profile. This profile contains a list
of DConf configuration databases. The user profile and database always take the
highest priority. As such the DConf User profile should always exist and be
configured correctly.
To make sure that the user profile is configured correctly, the /etc/dconf/profile/gdm
should be set as follows:
user-db:user
system-db:gdm
| Rationale: | Failure to have a functional DConf profile prevents GNOME3 configuration settings
from being enforced for all users and allows various security risks. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_enable_dconf_user_profile | Identifiers: | CCE-83267-5 | References: | | |
|
Group
Sudo
Group contains 3 rules |
[ref]
Sudo , which stands for "su 'do'", provides the ability to delegate authority
to certain users, groups of users, or system administrators. When configured for system
users and/or groups, Sudo can allow a user or group to execute privileged commands
that normally only root is allowed to execute.
For more information on Sudo and addition Sudo configuration options, see
https://www.sudo.ws. |
Rule
Install sudo Package
[ref] | The sudo package can be installed with the following command:
$ sudo zypper install sudo
| Rationale: | sudo is a program designed to allow a system administrator to give
limited root privileges to users and log root activity. The basic philosophy
is to give as few privileges as possible but still allow system users to
get their work done.
| Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_sudo_installed | Identifiers: | CCE-91183-4 | References: | | |
|
Rule
Ensure Only Users Logged In To Real tty Can Execute Sudo - sudo use_pty
[ref] | The sudo use_pty tag, when specified, will only execute sudo
commands from users logged in to a real tty.
This should be enabled by making sure that the use_pty tag exists in
/etc/sudoers configuration file or any sudo configuration snippets
in /etc/sudoers.d/ . | Rationale: | Requiring that sudo commands be run in a pseudo-terminal can prevent an attacker from retaining
access to the user's terminal after the main program has finished executing. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sudo_add_use_pty | Identifiers: | CCE-91190-9 | References: | | |
|
Rule
Ensure Sudo Logfile Exists - sudo logfile
[ref] | A custom log sudo file can be configured with the 'logfile' tag. This rule configures
a sudo custom logfile at the default location suggested by CIS, which uses
/var/log/sudo.log. | Rationale: | A sudo log file simplifies auditing of sudo commands. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_sudo_custom_logfile | Identifiers: | CCE-91311-1 | References: | | |
|
Group
Updating Software
Group contains 4 rules |
[ref]
The zypper command line tool is used to install and
update software packages. The system also provides a graphical
software update tool in the System menu, in the Administration submenu,
called Software Update.
SUSE Linux Enterprise 15 systems contain an installed software catalog called
the RPM database, which records metadata of installed packages. Consistently using
zypper or the graphical Software Update for all software installation
allows for insight into the current inventory of installed software on the system.
|
Rule
Ensure GPG keys are configured
[ref] | The operation system or installed application can be successfully bootstrapped
without the GPG key being trusted. However, you cannot install new packages or
update them until the keys are trusted.
Most packages managers implement GPG key signing to verify package integrity
during installation.
To verify GPG keys are configured correctly for your package manager,
one of the following command groups may provide the needed information
depending on the package manager in use.
In SUSE Linux distributions, the administrators have to follow the next steps:
1. Log on to the system as a user with administrator rights.
2. Locate and download package, for example zoom_x86_64.rpm
3. Locate and download the public key (GPG) from the software download site, for
example the key for zoom package is package-signing-key-5-12-6.pub
4. Import the key public key:
$ sudo rpm --import package-signing-key-5-12-6.pub
5. List the keys, for example the command:
$ sudo rpm -qa gpg-pubkey*
will provide:
gpg-pubkey-dd79b481-62fe7502
6. Get more details about the key, via the command:
$ sudo rpm -qa gpg-pubkey-dd79b481-62fe7502
7. Check the GPG key, for example the command:
$ sudo rpm -q gpg-pubkey --qf '%{name}-%{version}-%{release} --> %{summary}\n'
will provide:
gpg-pubkey-dd79b481-62fe7502 --> gpg(Zoom Video Communications, Inc. <CryptoOpsCodeSignProd@zoom.us>)
| Rationale: | It is important to ensure that updates are obtained from a valid source to protect
against spoofing that could lead to the inadvertent installation of malware on the
system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_GPG_keys_are_configured | Identifiers: | CCE-92542-0 | References: | | |
|
Rule
Ensure gpgcheck Enabled In Main zypper Configuration
[ref] | The gpgcheck option controls whether
RPM packages' signatures are always checked prior to installation.
To configure zypper to check package signatures before installing
them, ensure the following line appears in /etc/zypp/zypp.conf in
the [main] section:
gpgcheck=1
| Rationale: | Changes to any software components can have significant effects on the
overall security of the operating system. This requirement ensures the
software has not been tampered with and that it has been provided by a
trusted vendor.
Accordingly, patches, service packs, device drivers, or operating system
components must be signed with a certificate recognized and approved by the
organization.
Verifying the authenticity of the software prior to installation
validates the integrity of the patch or upgrade received from a vendor.
This ensures the software has not been tampered with and that it has been
provided by a trusted vendor. Self-signed certificates are disallowed by
this requirement. Certificates used to verify the software must be from an
approved Certificate Authority (CA). | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_gpgcheck_globally_activated | Identifiers: | CCE-83290-7 | References: | cis-csc | 11, 2, 3, 9 | cjis | 5.10.4.1 | cobit5 | APO01.06, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS06.02 | cui | 3.4.8 | disa | CCI-003992 | hipaa | 164.308(a)(1)(ii)(D), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(e)(2)(i) | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4 | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 7.6 | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4 | nist | CM-5(3), SI-7, SC-12, SC-12(3), CM-6(a), SA-12, SA-12(10), CM-11(a), CM-11(b) | nist-csf | PR.DS-6, PR.DS-8, PR.IP-1 | ospp | FPT_TUD_EXT.1, FPT_TUD_EXT.2 | pcidss | Req-6.2 | os-srg | SRG-OS-000366-GPOS-00153 | stigid | SLES-15-010430 | cis | 1.2.3 | anssi | R59 | pcidss4 | 6.3.3, 6.3 | stigref | SV-234852r986469_rule |
| |
|
Rule
Ensure gpgcheck Enabled for All zypper Package Repositories
[ref] | To ensure signature checking is not disabled for
any repos, remove any lines from files in /etc/yum.repos.d of the form:
gpgcheck=0
| Rationale: | 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. Certificates used to verify the software must be from an
approved Certificate Authority (CA)." | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_gpgcheck_never_disabled | Identifiers: | CCE-85797-9 | References: | cis-csc | 11, 2, 3, 9 | cjis | 5.10.4.1 | cobit5 | APO01.06, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS06.02 | cui | 3.4.8 | disa | CCI-003992 | hipaa | 164.308(a)(1)(ii)(D), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(e)(2)(i) | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4 | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 7.6 | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4 | nist | CM-5(3), SI-7, SC-12, SC-12(3), CM-6(a), SA-12, SA-12(10), CM-11(a), CM-11(b) | nist-csf | PR.DS-6, PR.DS-8, PR.IP-1 | ospp | FPT_TUD_EXT.1, FPT_TUD_EXT.2 | pcidss | Req-6.2 | os-srg | SRG-OS-000366-GPOS-00153 | cis | 1.2.3 | anssi | R59 | pcidss4 | 6.3.3, 6.3 |
| |
|
Rule
Ensure package manager repositories are configured
[ref] | Systems need to have package manager repositories configured to ensure they receive the
latest patches and updates. | Rationale: | If the system's package repositories are misconfigured important patches may not be
identified or a rogue repository could introduce compromised software. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_package_repositories_are_configured | Identifiers: | CCE-92489-4 | References: | | |
|
Group
Account and Access Control
Group contains 16 groups and 65 rules |
[ref]
In traditional Unix security, if an attacker gains
shell access to a certain login account, they can perform any action
or access any file to which that account has access. Therefore,
making it more difficult for unauthorized people to gain shell
access to accounts, particularly to privileged accounts, is a
necessary part of securing a system. This section introduces
mechanisms for restricting access to accounts under
SUSE Linux Enterprise 15. |
Group
Warning Banners for System Accesses
Group contains 1 group and 14 rules |
[ref]
Each system should expose as little information about
itself as possible.
System banners, which are typically displayed just before a
login prompt, give out information about the service or the host's
operating system. This might include the distribution name and the
system kernel version, and the particular version of a network
service. This information can assist intruders in gaining access to
the system as it can reveal whether the system is running
vulnerable software. Most network services can be configured to
limit what information is displayed.
Many organizations implement security policies that require a
system banner provide notice of the system's ownership, provide
warning to unauthorized users, and remind authorized users of their
consent to monitoring. |
Group
Implement a GUI Warning Banner
Group contains 2 rules |
[ref]
In the default graphical environment, users logging
directly into the system are greeted with a login screen provided
by the GNOME Display Manager (GDM). The warning banner should be
displayed in this graphical environment for these users.
The following sections describe how to configure the GDM login
banner. |
Rule
Enable GNOME3 Login Warning Banner
[ref] | In the default graphical environment, displaying a login warning banner
in the GNOME Display Manager's login screen can be enabled on the login
screen by setting banner-message-enable to true .
To enable, add or edit banner-message-enable to
/etc/dconf/db/gdm.d/00-security-settings . For example:
[org/gnome/login-screen]
banner-message-enable=true
Once the setting has been added, add a lock to
/etc/dconf/db/gdm.d/locks/00-security-settings-lock to prevent user modification.
For example:
/org/gnome/login-screen/banner-message-enable
After the settings have been set, run dconf update .
The banner text must also be set. | Rationale: | Display of a standardized and approved use notification before granting access to the operating system
ensures privacy and security notification verbiage used is consistent with applicable federal laws,
Executive Orders, directives, policies, regulations, standards, and guidance.
For U.S. Government systems, system use notifications are required only for access via login interfaces
with human users and are not required when such human interfaces do not exist. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_dconf_gnome_banner_enabled | Identifiers: | CCE-83265-9 | References: | cis-csc | 1, 12, 15, 16 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | cui | 3.1.9 | disa | CCI-001387, CCI-001384, CCI-000048, CCI-001386, CCI-001388, CCI-001385 | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | nist | AC-8(a), AC-8(b), AC-8(c) | nist-csf | PR.AC-7 | os-srg | SRG-OS-000023-GPOS-00006, SRG-OS-000228-GPOS-00088 | stigid | SLES-15-010080 | cis | 1.10 | stigref | SV-234808r958586_rule |
| |
|
Rule
Set the GNOME3 Login Warning Banner Text
[ref] | In the default graphical environment, configuring the login warning banner text
in the GNOME Display Manager's login screen can be configured on the login
screen by setting banner-message-text to 'APPROVED_BANNER'
where APPROVED_BANNER is the approved banner for your environment.
To enable, add or edit banner-message-text to
/etc/dconf/db/gdm.d/00-security-settings . For example:
[org/gnome/login-screen]
banner-message-text='APPROVED_BANNER'
Once the setting has been added, add a lock to
/etc/dconf/db/gdm.d/locks/00-security-settings-lock to prevent user modification.
For example:
/org/gnome/login-screen/banner-message-text
After the settings have been set, run dconf update .
When entering a warning banner that spans several lines, remember
to begin and end the string with ' and use \n for new lines. | Rationale: | An appropriate warning message reinforces policy awareness during the logon
process and facilitates possible legal action against attackers. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_dconf_gnome_login_banner_text | Identifiers: | CCE-83266-7 | References: | cis-csc | 1, 12, 15, 16 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | cui | 3.1.9 | disa | CCI-000048, CCI-001384, CCI-001385, CCI-001386, CCI-001387, CCI-001388 | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | nist | AC-8(a), AC-8(c) | nist-csf | PR.AC-7 | os-srg | SRG-OS-000023-GPOS-00006, SRG-OS-000228-GPOS-00088 | stigid | SLES-15-010090 | cis | 1.10 | stigref | SV-234809r958586_rule |
| |
|
Rule
Modify the System Login Banner
[ref] |
To configure the system login banner edit /etc/issue . Replace the
default text with a message compliant with the local site policy or a legal
disclaimer.
The DoD required text is either:
You are accessing a U.S. Government (USG) Information System (IS) that
is provided for USG-authorized use only. By using this IS (which includes
any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS
for purposes including, but not limited to, penetration testing, COMSEC
monitoring, network operations and defense, personnel misconduct (PM), law
enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private,
are subject to routine monitoring, interception, and search, and may be
disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access
controls) to protect USG interests -- not for your personal benefit or
privacy.
-Notwithstanding the above, using this IS does not constitute consent
to PM, LE or CI investigative searching or monitoring of the content of
privileged communications, or work product, related to personal
representation or services by attorneys, psychotherapists, or clergy, and
their assistants. Such communications and work product are private and
confidential. See User Agreement for details.
OR:
I've read & consent to terms in IS user agreem't.
| Rationale: | Display of a standardized and approved use notification before granting
access to the operating system ensures privacy and security notification
verbiage used is consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance.
System use notifications are required only for access via login interfaces
with human users and are not required when such human interfaces do not
exist. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_banner_etc_issue | Identifiers: | CCE-83262-6 | References: | cis-csc | 1, 12, 15, 16 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | cui | 3.1.9 | disa | CCI-001387, CCI-001384, CCI-000048, CCI-001386, CCI-001388, CCI-001385 | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | nist | AC-8(a), AC-8(c) | nist-csf | PR.AC-7 | os-srg | SRG-OS-000023-GPOS-00006, SRG-OS-000228-GPOS-00088 | stigid | SLES-15-010020 | cis | 1.8.1.2 | stigref | SV-234803r958390_rule |
| |
|
Rule
Modify the System Login Banner for Remote Connections
[ref] | To configure the system login banner edit /etc/issue.net . Replace the
default text with a message compliant with the local site policy or a legal
disclaimer.
The DoD required text is either:
You are accessing a U.S. Government (USG) Information System (IS) that
is provided for USG-authorized use only. By using this IS (which includes
any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS
for purposes including, but not limited to, penetration testing, COMSEC
monitoring, network operations and defense, personnel misconduct (PM), law
enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private,
are subject to routine monitoring, interception, and search, and may be
disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access
controls) to protect USG interests -- not for your personal benefit or
privacy.
-Notwithstanding the above, using this IS does not constitute consent
to PM, LE or CI investigative searching or monitoring of the content of
privileged communications, or work product, related to personal
representation or services by attorneys, psychotherapists, or clergy, and
their assistants. Such communications and work product are private and
confidential. See User Agreement for details.
OR:
I've read & consent to terms in IS user agreem't.
| Rationale: | Display of a standardized and approved use notification before granting
access to the operating system ensures privacy and security notification
verbiage used is consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance.
System use notifications are required only for access via login interfaces
with human users and are not required when such human interfaces do not
exist. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_banner_etc_issue_net | Identifiers: | CCE-91350-9 | References: | disa | CCI-000048, CCI-001384, CCI-001385, CCI-001386, CCI-001387, CCI-001388 | os-srg | SRG-OS-000023-GPOS-00006, SRG-OS-000228-GPOS-00088 | cis | 1.8.1.3 |
| |
|
Rule
Modify the System Message of the Day Banner
[ref] | To configure the system message banner edit /etc/motd . Replace the
default text with a message compliant with the local site policy or a legal
disclaimer.
The DoD required text is either:
You are accessing a U.S. Government (USG) Information System (IS) that
is provided for USG-authorized use only. By using this IS (which includes
any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS
for purposes including, but not limited to, penetration testing, COMSEC
monitoring, network operations and defense, personnel misconduct (PM), law
enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private,
are subject to routine monitoring, interception, and search, and may be
disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access
controls) to protect USG interests -- not for your personal benefit or
privacy.
-Notwithstanding the above, using this IS does not constitute consent
to PM, LE or CI investigative searching or monitoring of the content of
privileged communications, or work product, related to personal
representation or services by attorneys, psychotherapists, or clergy, and
their assistants. Such communications and work product are private and
confidential. See User Agreement for details.
OR:
I've read & consent to terms in IS user agreem't.
| Rationale: | Display of a standardized and approved use notification before granting
access to the operating system ensures privacy and security notification
verbiage used is consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance.
System use notifications are required only for access via login interfaces
with human users and are not required when such human interfaces do not
exist. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_banner_etc_motd | Identifiers: | CCE-91349-1 | References: | | |
|
Rule
Verify Group Ownership of System Login Banner
[ref] |
To properly set the group owner of /etc/issue , run the command:
$ sudo chgrp root /etc/issue
| Rationale: | Display of a standardized and approved use notification before granting
access to the operating system ensures privacy and security notification
verbiage used is consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance.
Proper group ownership will ensure that only root user can modify the banner. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_etc_issue | Identifiers: | CCE-91355-8 | References: | | |
|
Rule
Verify Group Ownership of System Login Banner for Remote Connections
[ref] |
To properly set the group owner of /etc/issue.net , run the command:
$ sudo chgrp root /etc/issue.net
| Rationale: | Display of a standardized and approved use notification before granting
access to the operating system ensures privacy and security notification
verbiage used is consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance.
Proper group ownership will ensure that only root user can modify the banner. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_etc_issue_net | Identifiers: | CCE-91358-2 | References: | | |
|
Rule
Verify Group Ownership of Message of the Day Banner
[ref] |
To properly set the group owner of /etc/motd , run the command:
$ sudo chgrp root /etc/motd
| Rationale: | Display of a standardized and approved use notification before granting
access to the operating system ensures privacy and security notification
verbiage used is consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance.
Proper group ownership will ensure that only root user can modify the banner. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_etc_motd | Identifiers: | CCE-91352-5 | References: | | |
|
Rule
Verify ownership of System Login Banner
[ref] |
To properly set the owner of /etc/issue , run the command:
$ sudo chown root /etc/issue
| Rationale: | Display of a standardized and approved use notification before granting
access to the operating system ensures privacy and security notification
verbiage used is consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance.
Proper ownership will ensure that only root user can modify the banner. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_etc_issue | Identifiers: | CCE-91356-6 | References: | | |
|
Rule
Verify ownership of System Login Banner for Remote Connections
[ref] |
To properly set the owner of /etc/issue.net , run the command:
$ sudo chown root /etc/issue.net
| Rationale: | Display of a standardized and approved use notification before granting
access to the operating system ensures privacy and security notification
verbiage used is consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance.
Proper ownership will ensure that only root user can modify the banner. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_etc_issue_net | Identifiers: | CCE-91359-0 | References: | | |
|
Rule
Verify ownership of Message of the Day Banner
[ref] |
To properly set the owner of /etc/motd , run the command:
$ sudo chown root /etc/motd
| Rationale: | Display of a standardized and approved use notification before granting
access to the operating system ensures privacy and security notification
verbiage used is consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance.
Proper ownership will ensure that only root user can modify the banner. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_etc_motd | Identifiers: | CCE-91353-3 | References: | | |
|
Rule
Verify permissions on System Login Banner
[ref] |
To properly set the permissions of /etc/issue , run the command:
$ sudo chmod 0644 /etc/issue
| Rationale: | Display of a standardized and approved use notification before granting
access to the operating system ensures privacy and security notification
verbiage used is consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance.
Proper permissions will ensure that only root user can modify the banner. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_etc_issue | Identifiers: | CCE-91354-1 | References: | | |
|
Rule
Verify permissions on System Login Banner for Remote Connections
[ref] |
To properly set the permissions of /etc/issue.net , run the command:
$ sudo chmod 0644 /etc/issue.net
| Rationale: | Display of a standardized and approved use notification before granting
access to the operating system ensures privacy and security notification
verbiage used is consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance.
Proper permissions will ensure that only root user can modify the banner. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_etc_issue_net | Identifiers: | CCE-91357-4 | References: | | |
|
Rule
Verify permissions on Message of the Day Banner
[ref] |
To properly set the permissions of /etc/motd , run the command:
$ sudo chmod 0644 /etc/motd
| Rationale: | Display of a standardized and approved use notification before granting
access to the operating system ensures privacy and security notification
verbiage used is consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance.
Proper permissions will ensure that only root user can modify the banner. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_etc_motd | Identifiers: | CCE-91351-7 | References: | | |
|
Group
Protect Accounts by Configuring PAM
Group contains 4 groups and 11 rules |
[ref]
PAM, or Pluggable Authentication Modules, is a system
which implements modular authentication for Linux programs. PAM provides
a flexible and configurable architecture for authentication, and it should be configured
to minimize exposure to unnecessary risk. This section contains
guidance on how to accomplish that.
PAM is implemented as a set of shared objects which are
loaded and invoked whenever an application wishes to authenticate a
user. Typically, the application must be running as root in order
to take advantage of PAM, because PAM's modules often need to be able
to access sensitive stores of account information, such as /etc/shadow.
Traditional privileged network listeners
(e.g. sshd) or SUID programs (e.g. sudo) already meet this
requirement. An SUID root application, userhelper, is provided so
that programs which are not SUID or privileged themselves can still
take advantage of PAM.
PAM looks in the directory /etc/pam.d for
application-specific configuration information. For instance, if
the program login attempts to authenticate a user, then PAM's
libraries follow the instructions in the file /etc/pam.d/login
to determine what actions should be taken.
One very important file in /etc/pam.d is
/etc/pam.d/system-auth . This file, which is included by
many other PAM configuration files, defines 'default' system authentication
measures. Modifying this file is a good way to make far-reaching
authentication changes, for instance when implementing a
centralized authentication service. Warning:
Be careful when making changes to PAM's configuration files.
The syntax for these files is complex, and modifications can
have unexpected consequences. The default configurations shipped
with applications should be sufficient for most users. |
Group
Set Lockouts for Failed Password Attempts
Group contains 4 rules |
[ref]
The pam_faillock PAM module provides the capability to
lock out user accounts after a number of failed login attempts. Its
documentation is available in
/usr/share/doc/pam-VERSION/txts/README.pam_faillock .
Warning:
Locking out user accounts presents the
risk of a denial-of-service attack. The lockout policy
must weigh whether the risk of such a
denial-of-service attack outweighs the benefits of thwarting
password guessing attacks. |
Rule
Limit Password Reuse
[ref] | Do not allow users to reuse recent passwords. This can be
accomplished by using the remember option for the
pam_pwhistory PAM modules.
In the file /etc/pam.d/common-password , make sure the parameters
remember and use_authtok are present, and that the value
for the remember parameter is 5 or greater. For example:
password requisite pam_pwhistory.so ...existing_options... remember=5 use_authtok
The DoD STIG requirement is 5 passwords. | Rationale: | Preventing re-use of previous passwords helps ensure that a compromised password is not re-used by a user. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_pwhistory_remember | Identifiers: | CCE-91398-8 | References: | | |
|
Rule
Set Deny For Failed Password Attempts
[ref] | The SUSE Linux Enterprise 15 operating system must lock an account after - at most - 5
consecutive invalid access attempts. | Rationale: | 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.
To configure the operating system to lock an account after three
unsuccessful consecutive access attempts using pam_tally2.so ,
modify the content of both /etc/pam.d/login and
/etc/pam.d/common-account as follows:
| Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_passwords_pam_tally2 | Identifiers: | CCE-85554-4 | References: | | |
|
Rule
Configure the root Account lock for Failed Password Attempts via pam_tally2
[ref] | This rule configures the system to lock out the root account after a number of
incorrect login attempts using pam_tally2.so . | Rationale: | By limiting the number of failed logon attempts, the risk of unauthorized system access via
user password guessing, also known as brute-forcing, is reduced. Limits are imposed by locking
the account. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_passwords_pam_tally2_deny_root | Identifiers: | CCE-91281-6 | References: | cis-csc | 1, 12, 15, 16 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | disa | CCI-002238, CCI-000044 | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | ism | 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561 | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | nist | CM-6(a), AC-7(b), IA-5(c) | nist-csf | PR.AC-7 | os-srg | SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005 | cis | 5.3.2 | anssi | R31 |
| |
|
Rule
Set Lockout Time for Failed Password Attempts using pam_tally2
[ref] | This rule configures the system to lock out accounts during a specified time period after a
number of incorrect login attempts using pam_tally2.so . | Rationale: | By limiting the number of failed logon attempts, the risk of unauthorized system access via
user password guessing, also known as brute-forcing, is reduced. Limits are imposed by locking
the account. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_passwords_pam_tally2_unlock_time | Identifiers: | CCE-91282-4 | References: | cis-csc | 1, 12, 15, 16 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | disa | CCI-002238, CCI-000044 | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | ism | 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561 | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | nist | CM-6(a), AC-7(b), IA-5(c) | nist-csf | PR.AC-7 | pcidss | Req-8.1.7 | os-srg | SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005 | cis | 5.3.2 | anssi | R31 | pcidss4 | 8.3.4, 8.3 |
| |
|
Group
Set Password Quality Requirements
Group contains 1 group and 6 rules |
[ref]
The default pam_pwquality PAM module provides strength
checking for passwords. It performs a number of checks, such as
making sure passwords are not similar to dictionary words, are of
at least a certain length, are not the previous password reversed,
and are not simply a change of case from the previous password. It
can also require passwords to be in certain character classes. The
pam_pwquality module is the preferred way of configuring
password requirements.
The man pages pam_pwquality(8)
provide information on the capabilities and configuration of
each. |
Group
Set Password Quality Requirements, if using
pam_cracklib
Group contains 6 rules |
[ref]
The pam_cracklib PAM module can be configured to meet
requirements for a variety of policies.
For example, to configure pam_cracklib to require at least one uppercase
character, lowercase character, digit, and other (special)
character, locate the following line in /etc/pam.d/system-auth :
password requisite pam_cracklib.so try_first_pass retry=3
and then alter it to read:
password required pam_cracklib.so try_first_pass retry=3 maxrepeat=3 minlen=14 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 difok=4
If no such line exists, add one as the first line of the password section in /etc/pam.d/system-auth .
The arguments can be modified to ensure compliance with
your organization's security policy. Discussion of each parameter follows. Warning:
Note that the password quality requirements are not enforced for the
root account for some reason. |
Rule
Set Password Strength Minimum Digit Characters
[ref] | The pam_cracklib module's dcredit parameter controls requirements
for usage of digits in a password. When set to a negative number, any
password will be required to contain that many digits. When set to a
positive number, pam_cracklib will grant +1 additional length credit for
each digit. Add dcredit=-1 after pam_cracklib.so to require use of
a digit in passwords. | Rationale: | Requiring digits makes password guessing attacks more difficult by ensuring
a larger search space. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_cracklib_accounts_password_pam_dcredit | Identifiers: | CCE-85564-3 | References: | | |
|
Rule
Set Password Strength Minimum Lowercase Characters
[ref] | The pam_cracklib module's lcredit= parameter controls requirements
for usage of lowercase letters in a password. When set to a negative
number, any password will be required to contain that many lowercase
characters. When set to a positive number, pam_cracklib will grant +1
additional length credit for each lowercase character.
Add lcredit=-1 after pam_cracklib.so to require use of a
lowercase character in passwords. | Rationale: | Requiring a minimum number of lowercase characters makes password guessing
attacks more difficult by ensuring a larger search space. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_cracklib_accounts_password_pam_lcredit | Identifiers: | CCE-85676-5 | References: | | |
|
Rule
Set Password Minimum Length
[ref] | The pam_cracklib module's minlen parameter controls requirements for
minimum characters required in a password. Add minlen=14
to set minimum password length requirements. | Rationale: | Password length is one factor of several that helps to determine
strength and how long it takes to crack a password. Use of more characters in
a password helps to exponentially increase the time and/or resources
required to compromise the password. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_cracklib_accounts_password_pam_minlen | Identifiers: | CCE-85573-4 | References: | | |
|
Rule
Set Password Strength Minimum Special Characters
[ref] | The pam_cracklib module's ocredit= parameter controls requirements
for usage of special (or ``other'') characters in a password. When set to a
negative number, any password will be required to contain that many special
characters. When set to a positive number, pam_cracklib will grant +1
additional length credit for each special character.
Make sure the ocredit parameter for the pam_cracklib module is
set to less than or equal to -1 . For example, ocredit=-1
. | Rationale: | Requiring a minimum number of special characters makes password guessing
attacks more difficult by ensuring a larger search space. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_cracklib_accounts_password_pam_ocredit | Identifiers: | CCE-85574-2 | References: | | |
|
Rule
Set Password Retry Limit
[ref] | The pam_cracklib module's retry parameter controls the maximum
number of times to prompt the user for the password before returning
with error. Make sure it is configured with a value that is no more than
3. For example, retry=1 . | Rationale: | To reduce opportunities for successful guesses and brute-force attacks. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_cracklib_accounts_password_pam_retry | Identifiers: | CCE-85575-9 | References: | | |
|
Rule
Set Password Strength Minimum Uppercase Characters
[ref] | The pam_cracklib module's ucredit= parameter controls requirements
for usage of uppercase letters in a password. When set to a negative
number, any password will be required to contain that many uppercase
characters. When set to a positive number, pam_cracklib will grant +1
additional length credit for each uppercase character.
Add ucredit=-1 after pam_cracklib.so to require use of an upper
case character in passwords. | Rationale: | Requiring a minimum number of uppercase characters makes password guessing
attacks more difficult by ensuring a larger search space. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_cracklib_accounts_password_pam_ucredit | Identifiers: | CCE-85675-7 | References: | | |
|
Group
Set Password Hashing Algorithm
Group contains 1 rule |
[ref]
The system's default algorithm for storing password hashes in
/etc/shadow is SHA-512. This can be configured in several
locations. |
Rule
Set Password Hashing Algorithm in /etc/login.defs
[ref] | In /etc/login.defs , add or update the following line to ensure the system will use
SHA512 as the hashing algorithm:
ENCRYPT_METHOD SHA512
| Rationale: | 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. Passwords that are encrypted with a weak algorithm
are no more protected than if they are kept in plain text.
Using a stronger hashing algorithm makes password cracking attacks more difficult. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_set_password_hashing_algorithm_logindefs | Identifiers: | CCE-83279-0 | References: | cis-csc | 1, 12, 15, 16, 5 | cjis | 5.6.2.2 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.13.11 | disa | CCI-004062 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 0418, 1055, 1402 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-5(c), IA-5(1)(c), CM-6(a) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | pcidss | Req-8.2.1 | os-srg | SRG-OS-000073-GPOS-00041 | stigid | SLES-15-010260 | cis | 5.4.1.1 | pcidss4 | 8.3.2, 8.3 | stigref | SV-234825r971535_rule |
| |
|
Group
Protect Physical Console Access
Group contains 2 rules |
[ref]
It is impossible to fully protect a system from an
attacker with physical access, so securing the space in which the
system is located should be considered a necessary step. However,
there are some steps which, if taken, make it more difficult for an
attacker to quickly or undetectably modify a system from its
console. |
Rule
Require Authentication for Emergency Systemd Target
[ref] | Emergency mode is intended as a system recovery
method, providing a single user root access to the system
during a failed boot sequence.
By default, Emergency mode is protected by requiring a password and is set
in /usr/lib/systemd/system/emergency.service . | Rationale: | This prevents attackers with physical access from trivially bypassing security
on the machine and gaining root access. Such accesses are further prevented
by configuring the bootloader password. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_require_emergency_target_auth | Identifiers: | CCE-91347-5 | References: | cis-csc | 1, 11, 12, 14, 15, 16, 18, 3, 5 | cobit5 | DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.06, DSS06.10 | cui | 3.1.1, 3.4.5 | disa | CCI-000213 | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7 | ism | 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561 | iso27001-2013 | A.18.1.4, A.6.1.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5 | nist | IA-2, AC-3, CM-6(a) | nist-csf | PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7, PR.PT-3 | os-srg | SRG-OS-000080-GPOS-00048 | cis | 1.5.3 |
| |
|
Rule
Require Authentication for Single User Mode
[ref] | Single-user mode is intended as a system recovery
method, providing a single user root access to the system by
providing a boot option at startup.
By default, single-user mode is protected by requiring a password and is set
in /usr/lib/systemd/system/rescue.service . | Rationale: | This prevents attackers with physical access from trivially bypassing security
on the machine and gaining root access. Such accesses are further prevented
by configuring the bootloader password. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_require_singleuser_auth | Identifiers: | CCE-91428-3 | References: | cis-csc | 1, 11, 12, 14, 15, 16, 18, 3, 5 | cobit5 | DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.06, DSS06.10 | cui | 3.1.1, 3.4.5 | disa | CCI-000213 | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7 | ism | 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561 | iso27001-2013 | A.18.1.4, A.6.1.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.2.3, CIP-004-6 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.2, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3 | nist | IA-2, AC-3, CM-6(a) | nist-csf | PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7, PR.PT-3 | ospp | FIA_UAU.1 | os-srg | SRG-OS-000080-GPOS-00048 | cis | 1.5.3 |
| |
|
Group
Protect Accounts by Restricting Password-Based Login
Group contains 4 groups and 28 rules |
[ref]
Conventionally, Unix shell accounts are accessed by
providing a username and password to a login program, which tests
these values for correctness using the /etc/passwd and
/etc/shadow files. Password-based login is vulnerable to
guessing of weak passwords, and to sniffing and man-in-the-middle
attacks against passwords entered over a network or at an insecure
console. Therefore, mechanisms for accessing accounts by entering
usernames and passwords should be restricted to those which are
operationally necessary. |
Group
Set Account Expiration Parameters
Group contains 3 rules |
[ref]
Accounts can be configured to be automatically disabled
after a certain time period,
meaning that they will require administrator interaction to become usable again.
Expiration of accounts after inactivity can be set for all accounts by default
and also on a per-account basis, such as for accounts that are known to be temporary.
To configure automatic expiration of an account following
the expiration of its password (that is, after the password has expired and not been changed),
run the following command, substituting NUM_DAYS and USER appropriately:
$ sudo chage -I NUM_DAYS USER
Accounts, such as temporary accounts, can also be configured to expire on an explicitly-set date with the
-E option.
The file /etc/default/useradd controls
default settings for all newly-created accounts created with the system's
normal command line utilities. Warning:
This will only apply to newly created accounts |
Rule
Set Account Expiration Following Inactivity
[ref] | To specify the number of days after a password expires (which
signifies inactivity) until an account is permanently disabled, add or correct
the following line in /etc/default/useradd :
INACTIVE=30
If a password is currently on the verge of expiration, then
30
day(s) remain(s) until the account is automatically
disabled. However, if the password will not expire for another 60 days, then 60
days plus 30 day(s) could
elapse until the account would be automatically disabled. See the
useradd man page for more information. | Rationale: | Inactive identifiers pose a risk to systems and applications because attackers may exploit an inactive identifier and potentially obtain undetected access to the system.
Disabling inactive accounts ensures that accounts which may not have been responsibly removed are not available to attackers who may have compromised their credentials.
Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_account_disable_post_pw_expiration | Identifiers: | CCE-85558-5 | References: | cis-csc | 1, 12, 13, 14, 15, 16, 18, 3, 5, 7, 8 | cjis | 5.6.2.1.1 | cobit5 | DSS01.03, DSS03.05, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.5.6 | disa | CCI-003628, CCI-003627 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 6.2 | iso27001-2013 | A.12.4.1, A.12.4.3, A.18.1.4, A.6.1.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5 | nerc-cip | CIP-004-6 R2.2.2, CIP-004-6 R2.2.3, CIP-007-3 R.1.3, CIP-007-3 R5, CIP-007-3 R5.1.1, CIP-007-3 R5.1.3, CIP-007-3 R5.2.1, CIP-007-3 R5.2.3 | nist | IA-4(e), AC-2(3), CM-6(a) | nist-csf | DE.CM-1, DE.CM-3, PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7 | pcidss | Req-8.1.4 | os-srg | SRG-OS-000118-GPOS-00060 | stigid | SLES-15-020050 | cis | 5.4.1.5 | pcidss4 | 8.2.6, 8.2 | stigref | SV-234871r986475_rule |
| |
|
Rule
Ensure All Accounts on the System Have Unique Names
[ref] | Ensure accounts on the system have unique names.
To ensure all accounts have unique names, run the following command:
$ sudo getent passwd | awk -F: '{ print $1}' | uniq -d
If a username is returned, change or delete the username. | Rationale: | Unique usernames allow for accountability on the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_account_unique_name | Identifiers: | CCE-85845-6 | References: | | |
|
Rule
Ensure shadow Group is Empty
[ref] | The shadow group allows system programs which require access the ability
to read the /etc/shadow file. No users should be assigned to the shadow group. Warning:
This rule remediation will ensure the group membership is empty in /etc/group. To avoid any
disruption the remediation won't change the primary group of users in /etc/passwd if any
user has the shadow GID as primary group. | Rationale: | Any users assigned to the shadow group would be granted read access to the
/etc/shadow file. If attackers can gain read access to the /etc/shadow file,
they can easily run a password cracking program against the hashed passwords
to break them. Other security information that is stored in the /etc/shadow
file (such as expiration) could also be useful to subvert additional user
accounts. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_shadow_group_empty | Identifiers: | CCE-91344-2 | References: | | |
|
Group
Set Password Expiration Parameters
Group contains 7 rules |
[ref]
The file /etc/login.defs controls several
password-related settings. Programs such as passwd ,
su , and
login consult /etc/login.defs to determine
behavior with regard to password aging, expiration warnings,
and length. See the man page login.defs(5) for more information.
Users should be forced to change their passwords, in order to
decrease the utility of compromised passwords. However, the need to
change passwords often should be balanced against the risk that
users will reuse or write down passwords if forced to change them
too often. Forcing password changes every 90-360 days, depending on
the environment, is recommended. Set the appropriate value as
PASS_MAX_DAYS and apply it to existing accounts with the
-M flag.
The PASS_MIN_DAYS ( -m ) setting prevents password
changes for 7 days after the first change, to discourage password
cycling. If you use this setting, train users to contact an administrator
for an emergency password change in case a new password becomes
compromised. The PASS_WARN_AGE ( -W ) setting gives
users 7 days of warnings at login time that their passwords are about to expire.
For example, for each existing human user USER, expiration parameters
could be adjusted to a 180 day maximum password age, 7 day minimum password
age, and 7 day warning period with the following command:
$ sudo chage -M 180 -m 7 -W 7 USER
|
Rule
Set Password Maximum Age
[ref] | To specify password maximum age for new accounts,
edit the file /etc/login.defs
and add or correct the following line:
PASS_MAX_DAYS 365
A value of 180 days is sufficient for many environments.
The DoD requirement is 60.
The profile requirement is 365 . | Rationale: | Any password, no matter how complex, can eventually be cracked. Therefore, passwords
need to be changed periodically. If the operating system does not limit the lifetime
of passwords and force users to change their passwords, there is the risk that the
operating system passwords could be compromised.
Setting the password maximum age ensures users are required to
periodically change their passwords. Requiring shorter password lifetimes
increases the risk of users writing down the password in a convenient
location subject to physical compromise. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_maximum_age_login_defs | Identifiers: | CCE-85570-0 | References: | cis-csc | 1, 12, 15, 16, 5 | cjis | 5.6.2.1 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.5.6 | disa | CCI-004066 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 0418, 1055, 1402 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-5(f), IA-5(1)(d), CM-6(a) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | pcidss | Req-8.2.4 | os-srg | SRG-OS-000076-GPOS-00044 | stigid | SLES-15-020220 | cis | 5.4.1.2 | pcidss4 | 8.3.9, 8.3 | stigref | SV-234891r986490_rule |
| |
|
Rule
Set Password Minimum Age
[ref] | To specify password minimum age for new accounts,
edit the file /etc/login.defs
and add or correct the following line:
PASS_MIN_DAYS 1
A value of 1 day is considered sufficient for many
environments. The DoD requirement is 1.
The profile requirement is 1 . | Rationale: | Enforcing a minimum password lifetime helps to prevent repeated password
changes to defeat the password reuse or history enforcement requirement. If
users are allowed to immediately and continually change their password,
then the password could be repeatedly changed in a short period of time to
defeat the organization's policy regarding password reuse.
Setting the minimum password age protects against users cycling back to a
favorite password after satisfying the password reuse requirement. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_minimum_age_login_defs | Identifiers: | CCE-85720-1 | References: | cis-csc | 1, 12, 15, 16, 5 | cjis | 5.6.2.1.1 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.5.8 | disa | CCI-004066 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 0418, 1055, 1402 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-5(1)(d), IA-5(1).1(v) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | os-srg | SRG-OS-000075-GPOS-00043 | stigid | SLES-15-020200 | cis | 5.4.1.3 | stigref | SV-234889r986486_rule |
| |
|
Rule
Set Existing Passwords Maximum Age
[ref] | Configure non-compliant accounts to enforce a 365-day maximum password lifetime
restriction by running the following command:
$ sudo chage -M 365
USER
| Rationale: | Any password, no matter how complex, can eventually be cracked. Therefore,
passwords need to be changed periodically. If the operating system does
not limit the lifetime of passwords and force users to change their
passwords, there is the risk that the operating system passwords could be
compromised. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_set_max_life_existing | Identifiers: | CCE-85571-8 | References: | | |
|
Rule
Set Existing Passwords Minimum Age
[ref] | Configure non-compliant accounts to enforce a 24 hours/1 day minimum password
lifetime by running the following command:
$ sudo chage -m 1 USER
| Rationale: | Enforcing a minimum password lifetime helps to prevent repeated password
changes to defeat the password reuse or history enforcement requirement. If
users are allowed to immediately and continually change their password, the
password could be repeatedly changed in a short period of time to defeat the
organization's policy regarding password reuse. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_set_min_life_existing | Identifiers: | CCE-85710-2 | References: | | |
|
Rule
Set Existing Passwords Warning Age
[ref] | To configure how many days prior to password expiration that a warning will be issued to
users, run the command:
$ sudo chage --warndays 7
USER
The DoD requirement is 7, and CIS recommendation is no less than 7 days.
This profile requirement is 7 . | Rationale: | Providing an advance warning that a password will be expiring gives users
time to think of a secure password. Users caught unaware may choose a simple
password or write it down where it may be discovered. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_set_warn_age_existing | Identifiers: | CCE-92479-5 | References: | | |
|
Rule
Set Password Warning Age
[ref] | To specify how many days prior to password
expiration that a warning will be issued to users,
edit the file /etc/login.defs and add or correct
the following line:
PASS_WARN_AGE 7
The DoD requirement is 7.
The profile requirement is 7 . | Rationale: | Setting the password warning age enables users to
make the change at a practical time. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_warn_age_login_defs | Identifiers: | CCE-91335-0 | References: | cis-csc | 1, 12, 13, 14, 15, 16, 18, 3, 5, 7, 8 | cobit5 | DSS01.03, DSS03.05, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.5.8 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 6.2 | ism | 0418, 1055, 1402 | iso27001-2013 | A.12.4.1, A.12.4.3, A.18.1.4, A.6.1.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5 | nist | IA-5(f), IA-5(1)(d), CM-6(a) | nist-csf | DE.CM-1, DE.CM-3, PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7 | pcidss | Req-8.2.4 | cis | 5.4.1.4 | pcidss4 | 8.3.9, 8.3 |
| |
|
Rule
Set existing passwords a period of inactivity before they been locked
[ref] | Configure user accounts that have been inactive for over a given period of time
to be automatically disabled by running the following command:
$ sudo chage --inactive 30USER
| Rationale: | Inactive accounts pose a threat to system security since the users are not logging in to
notice failed login attempts or other anomalies. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_set_post_pw_existing | Identifiers: | CCE-92480-3 | References: | cobit5 | DSS01.03, DSS03.05, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.5.6 | disa | CCI-000017, CCI-000795, CCI-003627, CCI-003628 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 6.2 | iso27001-2013 | A.12.4.1, A.12.4.3, A.18.1.4, A.6.1.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5 | nerc-cip | CIP-004-6 R2.2.2, CIP-004-6 R2.2.3, CIP-007-3 R.1.3, CIP-007-3 R5, CIP-007-3 R5.1.1, CIP-007-3 R5.1.3, CIP-007-3 R5.2.1, CIP-007-3 R5.2.3 | nist | IA-4(e), AC-2(3), CM-6(a) | nist-csf | DE.CM-1, DE.CM-3, PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7 | pcidss | Req-8.1.4 | os-srg | SRG-OS-000118-GPOS-00060 | cis | 5.4.1.5 | pcidss4 | 8.2.6, 8.2 |
| |
|
Group
Verify Proper Storage and Existence of Password
Hashes
Group contains 8 rules |
[ref]
By default, password hashes for local accounts are stored
in the second field (colon-separated) in
/etc/shadow . This file should be readable only by
processes running with root credentials, preventing users from
casually accessing others' password hashes and attempting
to crack them.
However, it remains possible to misconfigure the system
and store password hashes
in world-readable files such as /etc/passwd , or
to even store passwords themselves in plaintext on the system.
Using system-provided tools for password change/creation
should allow administrators to avoid such misconfiguration. |
Rule
Verify All Account Password Hashes are Shadowed
[ref] | If any password hashes are stored in /etc/passwd (in the second field,
instead of an x or * ), the cause of this misconfiguration should be
investigated. The account should have its password reset and the hash should be
properly stored, or the account should be deleted entirely. | Rationale: | The hashes for all user account passwords should be stored in
the file /etc/shadow and never in /etc/passwd ,
which is readable by all users. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_all_shadowed | Identifiers: | CCE-85846-4 | References: | cis-csc | 1, 12, 15, 16, 5 | cjis | 5.5.2 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.5.10 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 1410 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-5(h), CM-6(a) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | pcidss | Req-8.2.1 | cis | 6.2.1 | pcidss4 | 8.3.2, 8.3 |
| |
|
Rule
Verify All Account Password Hashes are Shadowed with SHA512
[ref] | Verify the 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. | Rationale: | 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_all_shadowed_sha512 | Identifiers: | CCE-85566-8 | References: | disa | CCI-000803, CCI-004062 | nist | IA-5(1)(c), IA-5(1).1(v), IA-7, IA-7.1 | os-srg | SRG-OS-000073-GPOS-00041, SRG-OS-000120-GPOS-00061 | stigid | SLES-15-020180 | cis | 5.4.1.1 | stigref | SV-234887r986483_rule |
| |
|
Rule
Ensure all users last password change date is in the past
[ref] | All users should have a password change date in the past. Warning:
Automatic remediation is not available, in order to avoid any system disruption. | Rationale: | If a user recorded password change date is in the future then they could
bypass any set password expiration. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_last_change_is_in_past | Identifiers: | CCE-92504-0 | References: | | |
|
Rule
All GIDs referenced in /etc/passwd must be defined in /etc/group
[ref] | Add a group to the system for each GID referenced without a corresponding group. | Rationale: | If a user is assigned the Group Identifier (GID) of a group not existing on the system, and a group
with the Group Identifier (GID) is subsequently created, the user may have unintended rights to
any files associated with the group. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_gid_passwd_group_same | Identifiers: | CCE-85847-2 | References: | cis-csc | 1, 12, 15, 16, 5 | cjis | 5.5.2 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | disa | CCI-000764 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.2.3, CIP-004-6 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.2, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3 | nist | IA-2, CM-6(a) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | pcidss | Req-8.5.a | os-srg | SRG-OS-000104-GPOS-00051 | cis | 6.2.13 | pcidss4 | 8.2.2, 8.2 |
| |
|
Rule
Verify No .forward Files Exist
[ref] | The .forward file specifies an email address to forward the user's mail to. | Rationale: | Use of the .forward file poses a security risk in that sensitive data may
be inadvertently transferred outside the organization. The .forward file
also poses a risk as it can be used to execute commands that may perform
unintended actions. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_no_forward_files | Identifiers: | CCE-92622-0 | References: | | |
|
Rule
Ensure there are no legacy + NIS entries in /etc/passwd
[ref] | The + character in /etc/passwd file marks a place where
entries from a network information service (NIS) should be directly inserted. | Rationale: | Using this method to include entries into /etc/passwd is considered legacy
and should be avoided. These entries may provide a way for an attacker
to gain access to the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_no_legacy_plus_entries_etc_passwd | Identifiers: | CCE-91399-6 | References: | | |
|
Rule
Ensure there are no legacy + NIS entries in /etc/shadow
[ref] | The + character in /etc/shadow file marks a place where
entries from a network information service (NIS) should be directly inserted. | Rationale: | Using this method to include entries into /etc/shadow is considered legacy
and should be avoided. These entries may provide a way for an attacker
to gain access to the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_no_legacy_plus_entries_etc_shadow | Identifiers: | CCE-91402-8 | References: | | |
|
Rule
Verify No netrc Files Exist
[ref] | The .netrc files contain login information
used to auto-login into FTP servers and reside in the user's home
directory. These files may contain unencrypted passwords to
remote FTP servers making them susceptible to access by unauthorized
users and should not be used. Any .netrc files should be removed. | Rationale: | Unencrypted passwords for remote FTP servers may be stored in .netrc
files. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_no_netrc_files | Identifiers: | CCE-92655-0 | References: | cis-csc | 1, 11, 12, 14, 15, 16, 18, 3, 5 | cobit5 | DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.06, DSS06.10 | disa | CCI-000196 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7 | iso27001-2013 | A.18.1.4, A.6.1.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R1.3, CIP-003-8 R3, CIP-003-8 R3.1, CIP-003-8 R3.2, CIP-003-8 R3.3, CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.2.3, CIP-004-6 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.2, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3 | nist | IA-5(h), IA-5(1)(c), CM-6(a), IA-5(7) | nist-csf | PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7, PR.PT-3 | cis | 6.2.10 |
| |
|
Group
Restrict Root Logins
Group contains 7 rules |
[ref]
Direct root logins should be allowed only for emergency use.
In normal situations, the administrator should access the system
via a unique unprivileged account, and then use su or sudo to execute
privileged commands. Discouraging administrators from accessing the
root account directly ensures an audit trail in organizations with
multiple administrators. Locking down the channels through which
root can connect directly also reduces opportunities for
password-guessing against the root account. The login program
uses the file /etc/securetty to determine which interfaces
should allow root logins.
The virtual devices /dev/console
and /dev/tty* represent the system consoles (accessible via
the Ctrl-Alt-F1 through Ctrl-Alt-F6 keyboard sequences on a default
installation). The default securetty file also contains /dev/vc/* .
These are likely to be deprecated in most environments, but may be retained
for compatibility. Root should also be prohibited from connecting
via network protocols. Other sections of this document
include guidance describing how to prevent root from logging in via SSH. |
Rule
Verify Only Root Has UID 0
[ref] | If any account other than root has a UID of 0, this misconfiguration should
be investigated and the accounts other than root should be removed or have
their UID changed.
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 greater than "1000" that has not already been
assigned. | Rationale: | An account has root authority if it has a UID of 0. Multiple accounts
with a UID of 0 afford more opportunity for potential intruders to
guess a password for a privileged account. Proper configuration of
sudo is recommended to afford multiple system administrators
access to root privileges in an accountable manner. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_no_uid_except_zero | Identifiers: | CCE-85664-1 | References: | cis-csc | 1, 12, 13, 14, 15, 16, 18, 3, 5 | cobit5 | APO01.06, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.02, DSS06.03, DSS06.10 | cui | 3.1.1, 3.1.5 | disa | CCI-000366 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.18.1.4, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.2.3, CIP-004-6 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.2, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3 | nist | CM-6(b), CM-6.1(iv) | nist-csf | PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7, PR.DS-5 | pcidss | Req-8.5 | os-srg | SRG-OS-000480-GPOS-00227 | stigid | SLES-15-020100 | cis | 6.2.3 | pcidss4 | 8.2.1, 8.2 | stigref | SV-234876r991589_rule |
| |
|
Rule
Verify Root Has A Primary GID 0
[ref] | The root user should have a primary group of 0. | Rationale: | To help ensure that root-owned files are not inadvertently exposed to other users. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_root_gid_zero | Identifiers: | CCE-91289-9 | References: | | |
|
Rule
Ensure the Group Used by pam_wheel.so Module Exists on System and is Empty
[ref] | Ensure that the group sugroup referenced by
var_pam_wheel_group_for_su variable and used as value for the pam_wheel.so
group option exists and has no members. This empty group used by
pam_wheel.so in /etc/pam.d/su ensures that no user can run commands with
altered privileges through the su command. Warning:
Note that this rule just ensures the group exists and has no members. This rule does not
configure pam_wheel.so module. The pam_wheel.so module configuration is
accomplished by use_pam_wheel_group_for_su rule. | Rationale: | The su program allows to run commands with a substitute user and group ID.
It is commonly used to run commands as the root user.
Limiting access to such command is considered a good security practice. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_pam_wheel_group_empty | Identifiers: | CCE-92528-9 | References: | | |
|
Rule
Direct root Logins Not Allowed
[ref] | To further limit access to the root account, administrators
can disable root logins at the console by editing the /etc/securetty file.
This file lists all devices the root user is allowed to login to. If the file does
not exist at all, the root user can login through any communication device on the
system, whether via the console or via a raw network interface. This is dangerous
as user can login to the system as root via Telnet, which sends the password in
plain text over the network. By default, SUSE Linux Enterprise 15's
/etc/securetty file only allows the root user to login at the console
physically attached to the system. To prevent root from logging in, remove the
contents of this file. To prevent direct root logins, remove the contents of this
file by typing the following command:
$ sudo echo > /etc/securetty
Warning:
This rule only checks the /etc/securetty file existence and its content.
If you need to restrict user access using the /etc/securetty file, make sure
the pam_securetty.so PAM module is properly enabled in relevant PAM files. | Rationale: | Disabling direct root logins ensures proper accountability and multifactor
authentication to privileged accounts. Users will first login, then escalate
to privileged (root) access via su / sudo. This is required for FISMA Low
and FISMA Moderate systems. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_no_direct_root_logins | Identifiers: | CCE-91427-5 | References: | cis-csc | 1, 12, 15, 16, 5 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.1.1, 3.1.6 | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.2.3, CIP-004-6 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.2, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3 | nist | IA-2, CM-6(a) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | cis | 5.5 | anssi | R33 | pcidss4 | 8.6.1, 8.6 |
| |
|
Rule
Ensure that System Accounts Do Not Run a Shell Upon Login
[ref] | Some accounts are not associated with a human user of the system, and exist to perform some
administrative functions. Should an attacker be able to log into these accounts, they should
not be granted access to a shell.
The login shell for each local account is stored in the last field of each line in
/etc/passwd . System accounts are those user accounts with a user ID less than
1000 . The user ID is stored in the third field. If any system account
other than root has a login shell, disable it with the command:
$ sudo usermod -s /sbin/nologin account
Warning:
Do not perform the steps in this section on the root account. Doing so might cause the
system to become inaccessible. | Rationale: | Ensuring shells are not given to system accounts upon login makes it more difficult for
attackers to make use of system accounts. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_no_shelllogin_for_systemaccounts | Identifiers: | CCE-85672-4 | References: | cis-csc | 1, 12, 13, 14, 15, 16, 18, 3, 5, 7, 8 | cobit5 | DSS01.03, DSS03.05, DSS05.04, DSS05.05, DSS05.07, DSS06.03 | disa | CCI-000366 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 6.2 | ism | 1491 | iso27001-2013 | A.12.4.1, A.12.4.3, A.6.1.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5 | nist | AC-6, CM-6(a), CM-6(b), CM-6.1(iv) | nist-csf | DE.CM-1, DE.CM-3, PR.AC-1, PR.AC-4, PR.AC-6 | os-srg | SRG-OS-000480-GPOS-00227 | stigid | SLES-15-020091 | cis | 5.4.2 | pcidss4 | 8.2.2, 8.2 | stigref | SV-234875r991589_rule |
| |
|
Rule
Restrict Virtual Console Root Logins
[ref] | To restrict root logins through the (deprecated) virtual console devices,
ensure lines of this form do not appear in /etc/securetty :
vc/1
vc/2
vc/3
vc/4
| Rationale: | Preventing direct root login to virtual console devices
helps ensure accountability for actions taken on the system
using the root account. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_securetty_root_login_console_only | Identifiers: | CCE-91430-9 | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | cui | 3.1.1, 3.1.5 | disa | CCI-000770 | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | AC-6, CM-6(a) | nist-csf | PR.AC-4, PR.DS-5 | os-srg | SRG-OS-000324-GPOS-00125 | cis | 5.5 | pcidss4 | 8.6.1, 8.6 |
| |
|
Rule
Enforce Usage of pam_wheel with Group Parameter for su Authentication
[ref] | To ensure that only users who are members of the group set in the group option of
pam_wheel.so module can run commands with altered privileges through the su
command, make sure that the following line exists in the file /etc/pam.d/su :
auth required pam_wheel.so use_uid group=sugroup
Warning:
Note that ensure_pam_wheel_group_empty rule complements this requirement by
ensuring the referenced group exists and has no members. | Rationale: | The su program allows to run commands with a substitute user and group ID.
It is commonly used to run commands as the root user.
Limiting access to such command is considered a good security practice. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_use_pam_wheel_group_for_su | Identifiers: | CCE-92522-2 | References: | | |
|
Rule
Ensure All Accounts on the System Have Unique User IDs
[ref] | Change user IDs (UIDs), or delete accounts, so each has a unique name. Warning:
Automatic remediation of this control is not available due to unique requirements of each
system. | Rationale: | To assure accountability and prevent unauthenticated access, interactive users must be identified and authenticated to prevent potential misuse and compromise of the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_account_unique_id | Identifiers: | CCE-83277-4 | References: | | |
|
Rule
Ensure All Groups on the System Have Unique Group ID
[ref] | Change the group name or delete groups, so each has a unique id. Warning:
Automatic remediation of this control is not available due to the unique requirements of each system. | Rationale: | To assure accountability and prevent unauthenticated access, groups must be identified uniquely to prevent potential misuse and compromise of the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_group_unique_id | Identifiers: | CCE-91339-2 | References: | | |
|
Rule
Ensure All Groups on the System Have Unique Group Names
[ref] | Change the group name or delete groups, so each has a unique name. Warning:
Automatic remediation of this control is not available due to the unique requirements of each system. | Rationale: | To assure accountability and prevent unauthenticated access, groups must be identified uniquely to prevent potential misuse and compromise of the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_group_unique_name | Identifiers: | CCE-91340-0 | References: | | |
|
Group
Secure Session Configuration Files for Login Accounts
Group contains 2 groups and 10 rules |
[ref]
When a user logs into a Unix account, the system
configures the user's session by reading a number of files. Many of
these files are located in the user's home directory, and may have
weak permissions as a result of user error or misconfiguration. If
an attacker can modify or even read certain types of account
configuration information, they can often gain full access to the
affected user's account. Therefore, it is important to test and
correct configuration file permissions for interactive accounts,
particularly those of privileged users such as root or system
administrators. |
Group
Ensure that No Dangerous Directories Exist in Root's Path
Group contains 2 rules |
[ref]
The active path of the root account can be obtained by
starting a new root shell and running:
# echo $PATH
This will produce a colon-separated list of
directories in the path.
Certain path elements could be considered dangerous, as they could lead
to root executing unknown or
untrusted programs, which could contain malicious
code.
Since root may sometimes work inside
untrusted directories, the . character, which represents the
current directory, should never be in the root path, nor should any
directory which can be written to by an unprivileged or
semi-privileged (system) user.
It is a good practice for administrators to always execute
privileged commands by typing the full path to the
command. |
Rule
Ensure that Root's Path Does Not Include World or Group-Writable Directories
[ref] | For each element in root's path, run:
# ls -ld DIR
and ensure that write permissions are disabled for group and
other. | Rationale: | Such entries increase the risk that root could
execute code provided by unprivileged users,
and potentially malicious code. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_root_path_dirs_no_write | Identifiers: | CCE-91401-0 | References: | cis-csc | 11, 3, 9 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05 | disa | CCI-000366 | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3 | isa-62443-2013 | SR 7.6 | iso27001-2013 | A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4 | nist | CM-6(a), CM-6(a) | nist-csf | PR.IP-1 | cis | 6.2.4 |
| |
|
Rule
Ensure that Root's Path Does Not Include Relative Paths or Null Directories
[ref] | Ensure that none of the directories in root's path is equal to a single
. character, or
that it contains any instances that lead to relative path traversal, such as
.. or beginning a path without the slash ( / ) character.
Also ensure that there are no "empty" elements in the path, such as in these examples:
PATH=:/bin
PATH=/bin:
PATH=/bin::/sbin
These empty elements have the same effect as a single . character. | Rationale: | Including these entries increases the risk that root could
execute code from an untrusted location. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_root_path_no_dot | Identifiers: | CCE-91400-2 | References: | cis-csc | 11, 3, 9 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05 | disa | CCI-000366 | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3 | isa-62443-2013 | SR 7.6 | iso27001-2013 | A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4 | nist | CM-6(a), CM-6(a) | nist-csf | PR.IP-1 | cis | 6.2.4 |
| |
|
Group
Ensure that Users Have Sensible Umask Values
Group contains 3 rules |
[ref]
The umask setting controls the default permissions
for the creation of new files.
With a default umask setting of 077, files and directories
created by users will not be readable by any other user on the
system. Users who wish to make specific files group- or
world-readable can accomplish this by using the chmod command.
Additionally, users can make all their files readable to their
group by default by setting a umask of 027 in their shell
configuration files. If default per-user groups exist (that is, if
every user has a default group whose name is the same as that
user's username and whose only member is the user), then it may
even be safe for users to select a umask of 007, making it very
easy to intentionally share files with groups of which the user is
a member.
|
Rule
Ensure the Default Bash Umask is Set Correctly
[ref] | To ensure the default umask for users of the Bash shell is set properly,
add or correct the umask setting in /etc/bash.bashrc to read
as follows:
umask 027
| Rationale: | The umask value influences the permissions assigned to files when they are created.
A misconfigured umask value could result in files with excessive permissions that can be read or
written to by unauthorized users. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_umask_etc_bashrc | Identifiers: | CCE-91215-4 | References: | cis-csc | 18 | cobit5 | APO13.01, BAI03.01, BAI03.02, BAI03.03 | disa | CCI-000366 | isa-62443-2009 | 4.3.4.3.3 | iso27001-2013 | A.14.1.1, A.14.2.1, A.14.2.5, A.6.1.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | AC-6(1), CM-6(a) | nist-csf | PR.IP-2 | os-srg | SRG-OS-000480-GPOS-00228, SRG-OS-000480-GPOS-00227 | cis | 5.4.5 | anssi | R36 |
| |
|
Rule
Ensure the Default Umask is Set Correctly in login.defs
[ref] | To ensure the default umask controlled by /etc/login.defs is set properly,
add or correct the UMASK setting in /etc/login.defs to read as follows:
UMASK 027
| Rationale: | The umask value influences the permissions assigned to files when they are created.
A misconfigured umask value could result in files with excessive permissions that can be read and
written to by unauthorized users. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_umask_etc_login_defs | Identifiers: | CCE-85659-1 | References: | cis-csc | 11, 18, 3, 9 | cobit5 | APO13.01, BAI03.01, BAI03.02, BAI03.03, BAI10.01, BAI10.02, BAI10.03, BAI10.05 | disa | CCI-000366 | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3 | isa-62443-2013 | SR 7.6 | iso27001-2013 | A.12.1.2, A.12.5.1, A.12.6.2, A.14.1.1, A.14.2.1, A.14.2.2, A.14.2.3, A.14.2.4, A.14.2.5, A.6.1.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | AC-6(1), CM-6(a) | nist-csf | PR.IP-1, PR.IP-2 | os-srg | SRG-OS-000480-GPOS-00228 | stigid | SLES-15-040420 | cis | 5.4.5 | anssi | R36 | stigref | SV-235030r991590_rule |
| |
|
Rule
Ensure the Default Umask is Set Correctly in /etc/profile
[ref] | To ensure the default umask controlled by /etc/profile is set properly,
add or correct the umask setting in /etc/profile to read as follows:
umask 027
Note that /etc/profile also reads scrips within /etc/profile.d directory.
These scripts are also valid files to set umask value. Therefore, they should also be
considered during the check and properly remediated, if necessary. | Rationale: | The umask value influences the permissions assigned to files when they are created.
A misconfigured umask value could result in files with excessive permissions that can be read or
written to by unauthorized users. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_umask_etc_profile | Identifiers: | CCE-91216-2 | References: | cis-csc | 18 | cobit5 | APO13.01, BAI03.01, BAI03.02, BAI03.03 | disa | CCI-000366 | isa-62443-2009 | 4.3.4.3.3 | iso27001-2013 | A.14.1.1, A.14.2.1, A.14.2.5, A.6.1.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | AC-6(1), CM-6(a) | nist-csf | PR.IP-2 | os-srg | SRG-OS-000480-GPOS-00228, SRG-OS-000480-GPOS-00227 | cis | 5.4.5 | anssi | R36 |
| |
|
Rule
Set Interactive Session Timeout
[ref] | Setting the TMOUT option in /etc/profile ensures that
all user sessions will terminate based on inactivity.
The value of TMOUT should be exported and read only.
The TMOUT
setting in /etc/profile.d/autologout.sh should read as follows:
TMOUT=900
readonly TMOUT
export TMOUT | Rationale: | 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_tmout | Identifiers: | CCE-83269-1 | References: | cis-csc | 1, 12, 15, 16 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | cui | 3.1.11 | disa | CCI-000057, CCI-001133 | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | nerc-cip | CIP-004-6 R2.2.3, CIP-007-3 R5.1, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3 | nist | AC-12, SC-10, AC-2(5), CM-6(a) | nist-csf | PR.AC-7 | os-srg | SRG-OS-000163-GPOS-00072, SRG-OS-000029-GPOS-00010 | stigid | SLES-15-010130 | cis | 5.4.4 | anssi | R32 | pcidss4 | 8.6.1, 8.6 | stigref | SV-234813r958402_rule |
| |
|
Rule
All Interactive Users Home Directories Must Exist
[ref] | Create home directories to all 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 :
$ sudo mkdir /home/USER
| Rationale: | 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_user_interactive_home_directory_exists | Identifiers: | CCE-85628-6 | References: | | |
|
Rule
All User Files and Directories In The Home Directory Must Have Mode 0750 Or Less Permissive
[ref] | Set the mode on files and directories in the local interactive user home
directory with the following command:
$ sudo chmod 0750 /home/USER/FILE_DIR
Files that begin with a "." are excluded from this requirement. | Rationale: | If a local interactive user files have excessive permissions, unintended users
may be able to access or modify them. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_users_home_files_permissions | Identifiers: | CCE-91403-6 | References: | | |
|
Rule
Ensure users' .netrc Files are not group or world accessible
[ref] | While the system administrator can establish secure permissions for users' .netrc files, the
users can easily override these.
This rule ensures every .netrc file or directory under the home directory related
to an interactive user is not group or world accessible | Rationale: | .netrc files may contain unencrypted passwords that may be used to attack other systems.
Note: While the complete removal of .netrc files is recommended, if any are required on the
system, secure permissions must be applied. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_users_netrc_file_permissions | Identifiers: | CCE-92697-2 | References: | | |
|
Rule
All Interactive User Home Directories Must Have mode 0750 Or Less Permissive
[ref] | Change the mode of interactive users home directories to 0750 . To
change the mode of interactive users home directory, use the
following command:
$ sudo chmod 0750 /home/USER
| Rationale: | Excessive permissions on local interactive user home directories may allow
unauthorized access to user files by other users. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_home_directories | Identifiers: | CCE-85629-4 | References: | | |
|
Group
AppArmor
Group contains 4 rules |
[ref]
Many security vulnerabilities result from bugs in trusted programs. A trusted
program runs with privileges that attackers want to possess. The program fails
to keep that trust if there is a bug in the program that allows the attacker to
acquire said privilege.
AppArmor® is an application security solution designed specifically to apply
privilege confinement to suspect programs. AppArmor allows the administrator to
specify the domain of activities the program can perform by developing a
security profile. A security profile is a listing of files that the program may
access and the operations the program may perform. AppArmor secures
applications by enforcing good application behavior without relying on attack
signatures, so it can prevent attacks even if previously unknown
vulnerabilities are being exploited.
For more information on using AppArmor, see
https://www.suse.com/documentation/sles-12/book_security/data/cha_apparmor_intro.html. |
Rule
Install the pam_apparmor Package
[ref] | The pam_apparmor package can be installed with the following command:
$ sudo zypper install pam_apparmor
| Rationale: | Protection of system integrity using AppArmor depends on this package being
installed. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_pam_apparmor_installed | Identifiers: | CCE-85765-6 | References: | disa | CCI-001764, CCI-001774, CCI-002165, CCI-002233, CCI-002235 | nist | AC-3(4), AC-6(8), AC-6(10), CM-7(5)(b), CM-7(2), SC-7(21), CM-6(a) | os-srg | SRG-OS-000312-GPOS-00122, SRG-OS-000312-GPOS-00123, SRG-OS-000312-GPOS-00124, SRG-OS-000324-GPOS-00125, SRG-OS-000326-GPOS-00126, SRG-OS-000370-GPOS-00155, SRG-OS-000480-GPOS-00230, SRG-OS-000480-GPOS-00227, SRG-OS-000480-GPOS-00231, SRG-OS-000480-GPOS-00232 | stigid | SLES-15-010390 | cis | 1.7.1.1 | anssi | R45 | stigref | SV-234848r958702_rule |
| |
|
Rule
Enforce all AppArmor Profiles
[ref] | AppArmor profiles define what resources applications are able to access.
To set all profiles to enforce mode run the following command:
$ sudo aa-enforce /etc/apparmor.d/*
To list unconfined processes run the following command:
$ sudo aa-unconfined
Any unconfined processes may need to have a profile created or activated
for them and then be restarted. | Rationale: | Security configuration requirements vary from site to site. Some sites may
mandate a policy that is stricter than the default policy, which is perfectly
acceptable. This recommendation is intended to ensure that any policies that
exist on the system are activated. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_all_apparmor_profiles_enforced | Identifiers: | CCE-92536-2 | References: | | |
|
Rule
All AppArmor Profiles are in enforce or complain mode
[ref] | AppArmor profiles define what resources applications are able to access.
To set all profiles to either enforce or complain mode
run the following command to set all profiles to enforce mode:
$ sudo aa-enforce /etc/apparmor.d/*
run the following command to set all profiles to complain mode:
$ sudo aa-complain /etc/apparmor.d/*
To list unconfined processes run the following command:
$ sudo aa-unconfined
Any unconfined processes may need to have a profile created or activated
for them and then be restarted. | Rationale: | Security configuration requirements vary from site to site. Some sites may
mandate a policy that is stricter than the default policy, which is perfectly
acceptable. This recommendation is intended to ensure that any policies that
exist on the system are activated. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_all_apparmor_profiles_in_enforce_complain_mode | Identifiers: | CCE-92548-7 | References: | | |
|
Rule
Ensure AppArmor is Active and Configured
[ref] | Verify that the Apparmor tool is configured to
control whitelisted applications and user home directory access
control.
The apparmor service can be enabled with the following command:
$ sudo systemctl enable apparmor.service
| Rationale: | 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_apparmor_configured | Identifiers: | CCE-85752-4 | References: | disa | CCI-001764, CCI-001774, CCI-002165, CCI-002233, CCI-002235 | nist | AC-3(4), AC-6(8), AC-6(10), CM-7(5)(b), CM-7(2), SC-7(21), CM-6(a) | os-srg | SRG-OS-000312-GPOS-00122, SRG-OS-000312-GPOS-00123, SRG-OS-000312-GPOS-00124, SRG-OS-000324-GPOS-00125, SRG-OS-000326-GPOS-00126, SRG-OS-000370-GPOS-00155, SRG-OS-000480-GPOS-00230, SRG-OS-000480-GPOS-00227, SRG-OS-000480-GPOS-00231, SRG-OS-000480-GPOS-00232 | stigid | SLES-15-010390 | cis | 1.7.1.2 | anssi | R45 | stigref | SV-234848r958702_rule |
| |
|
Group
GRUB2 bootloader configuration
Group contains 2 groups and 5 rules |
[ref]
During the boot process, the boot loader is
responsible for starting the execution of the kernel and passing
options to it. The boot loader allows for the selection of
different kernels - possibly on different partitions or media.
The default SUSE Linux Enterprise 15 boot loader for x86 systems is called GRUB2.
Options it can pass to the kernel include single-user mode, which
provides root access without any authentication, and the ability to
disable SELinux. To prevent local users from modifying the boot
parameters and endangering security, protect the boot loader configuration
with a password and ensure its configuration file's permissions
are set properly. |
Group
Non-UEFI GRUB2 bootloader configuration
Group contains 4 rules |
[ref]
Non-UEFI GRUB2 bootloader configuration |
Rule
Verify /boot/grub2/grub.cfg Group Ownership
[ref] | The file /boot/grub2/grub.cfg should
be group-owned by the root group to prevent
destruction or modification of the file.
To properly set the group owner of /boot/grub2/grub.cfg , run the command:
$ sudo chgrp root /boot/grub2/grub.cfg
| Rationale: | The root group is a highly-privileged group. Furthermore, the group-owner of this
file should not have any access privileges anyway. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_grub2_cfg | Identifiers: | CCE-85849-8 | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2.2 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | cui | 3.4.5 | disa | CCI-000366 | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-7.1 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 1.5.2 | anssi | R29 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify /boot/grub2/grub.cfg User Ownership
[ref] | The file /boot/grub2/grub.cfg should
be owned by the root user to prevent destruction
or modification of the file.
To properly set the owner of /boot/grub2/grub.cfg , run the command:
$ sudo chown root /boot/grub2/grub.cfg
| Rationale: | Only root should be able to modify important boot parameters. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_grub2_cfg | Identifiers: | CCE-85848-0 | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2.2 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | cui | 3.4.5 | disa | CCI-000366 | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-7.1 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 1.5.2 | anssi | R29 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify /boot/grub2/grub.cfg Permissions
[ref] | File permissions for /boot/grub2/grub.cfg should be set to 600.
To properly set the permissions of /boot/grub2/grub.cfg , run the command:
$ sudo chmod 600 /boot/grub2/grub.cfg
| Rationale: | Proper permissions ensure that only the root user can modify important boot
parameters. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_grub2_cfg | Identifiers: | CCE-91426-7 | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | cui | 3.4.5 | disa | CCI-000225 | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | cis | 1.5.2 | anssi | R29 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Set Boot Loader Password in grub2
[ref] | The grub2 boot loader should have a superuser account and password
protection enabled to protect boot-time settings.
Since plaintext passwords are a security risk, generate a hash for the password
by running the following command:
# grub2-mkpasswd-pbkdf2
When prompted, enter the password that was selected.
Using the hash from the output, modify the /etc/grub.d/40_custom
file with the following content:
set superusers="boot"
password_pbkdf2 boot grub.pbkdf2.sha512.VeryLongString
NOTE: the bootloader superuser account and password MUST differ from the
root account and password.
Once the superuser password has been added,
update the
grub.cfg file by running:
grub2-mkconfig -o /boot/grub2/grub2.cfg
Warning:
To prevent hard-coded passwords, automatic remediation of this control is not available. Remediation
must be automated as a component of machine provisioning, or followed manually as outlined above.
Also, do NOT manually add the superuser account and password to the
grub.cfg file as the grub2-mkconfig command overwrites this file. | Rationale: | Password protection on the boot loader configuration ensures
users with physical access cannot trivially alter
important bootloader settings. These include which kernel to use,
and whether to enter single-user mode. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_password | Identifiers: | CCE-83274-1 | References: | cis-csc | 1, 11, 12, 14, 15, 16, 18, 3, 5 | cobit5 | DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.06, DSS06.10 | cui | 3.4.5 | disa | CCI-000213 | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7 | iso27001-2013 | A.18.1.4, A.6.1.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5 | nist | CM-6(a) | nist-csf | PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7, PR.PT-3 | os-srg | SRG-OS-000080-GPOS-00048 | stigid | SLES-15-010190 | cis | 1.5.1 | anssi | R5 | stigref | SV-234819r958472_rule |
| |
|
Group
UEFI GRUB2 bootloader configuration
Group contains 1 rule |
[ref]
UEFI GRUB2 bootloader configuration Warning:
UEFI generally uses vfat file systems, which does not support Unix-style permissions
managed by chmod command. In this case, in order to change file permissions for files
within /boot/efi it is necessary to update the mount options in /etc/fstab file and
reboot the system. |
Rule
Set the UEFI Boot Loader Password
[ref] | The grub2 boot loader should have a superuser account and password
protection enabled to protect boot-time settings.
Since plaintext passwords are a security risk, generate a hash for the password
by running the following command:
# grub2-mkpasswd-pbkdf2
When prompted, enter the password that was selected.
Using the hash from the output, modify the /etc/grub.d/40_custom
file with the following content:
set superusers="boot"
password_pbkdf2 boot grub.pbkdf2.sha512.VeryLongString
NOTE: the bootloader superuser account and password MUST differ from the
root account and password.
Once the superuser password has been added,
update the
grub.cfg file by running:
grub2-mkconfig -o /boot/grub2/grub2.cfg
Warning:
To prevent hard-coded passwords, automatic remediation of this control is not available. Remediation
must be automated as a component of machine provisioning, or followed manually as outlined above.
Also, do NOT manually add the superuser account and password to the
grub.cfg file as the grub2-mkconfig command overwrites this file. | Rationale: | Password protection on the boot loader configuration ensures
users with physical access cannot trivially alter
important bootloader settings. These include which kernel to use,
and whether to enter single-user mode. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_uefi_password | Identifiers: | CCE-83275-8 | References: | cis-csc | 11, 12, 14, 15, 16, 18, 3, 5 | cobit5 | DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.03, DSS06.06 | cui | 3.4.5 | disa | CCI-000213 | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7 | iso27001-2013 | A.6.1.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-6(a) | nist-csf | PR.AC-4, PR.AC-6, PR.PT-3 | ospp | FIA_UAU.1 | os-srg | SRG-OS-000080-GPOS-00048 | stigid | SLES-15-010200 | cis | 1.5.1 | anssi | R5 | stigref | SV-234820r958472_rule |
| |
|
Group
Configure Syslog
Group contains 4 groups and 13 rules |
[ref]
The syslog service has been the default Unix logging mechanism for
many years. It has a number of downsides, including inconsistent log format,
lack of authentication for received messages, and lack of authentication,
encryption, or reliable transport for messages sent over a network. However,
due to its long history, syslog is a de facto standard which is supported by
almost all Unix applications.
In SUSE Linux Enterprise 15, rsyslog has replaced ksyslogd as the
syslog daemon of choice, and it includes some additional security features
such as reliable, connection-oriented (i.e. TCP) transmission of logs, the
option to log to database formats, and the encryption of log data en route to
a central logging server.
This section discusses how to configure rsyslog for
best effect, and how to use tools provided with the system to maintain and
monitor logs. |
Group
Ensure Proper Configuration of Log Files
Group contains 4 rules |
[ref]
The file /etc/rsyslog.conf controls where log message are written.
These are controlled by lines called rules, which consist of a
selector and an action.
These rules are often customized depending on the role of the system, the
requirements of the environment, and whatever may enable
the administrator to most effectively make use of log data.
The default rules in SUSE Linux Enterprise 15 are:
*.info;mail.none;authpriv.none;cron.none /var/log/messages
authpriv.* /var/log/secure
mail.* -/var/log/maillog
cron.* /var/log/cron
*.emerg *
uucp,news.crit /var/log/spooler
local7.* /var/log/boot.log
See the man page rsyslog.conf(5) for more information.
Note that the rsyslog daemon can be configured to use a timestamp format that
some log processing programs may not understand. If this occurs,
edit the file /etc/rsyslog.conf and add or edit the following line:
$ ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
|
Rule
Ensure Log Files Are Owned By Appropriate Group
[ref] | The group-owner of all log files written by
rsyslog should be root .
These log files are determined by the second part of each Rule line in
/etc/rsyslog.conf and typically all appear in /var/log .
For each log file LOGFILE referenced in /etc/rsyslog.conf ,
run the following command to inspect the file's group owner:
$ ls -l LOGFILE
If the owner is not root ,
run the following command to
correct this:
$ sudo chgrp root LOGFILE
| Rationale: | The log files generated by rsyslog contain valuable information regarding system
configuration, user authentication, and other such information. Log files should be
protected from unauthorized access. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_rsyslog_files_groupownership | Identifiers: | CCE-85838-1 | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | disa | CCI-001314 | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | ism | 0988, 1405 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-10.5.1, Req-10.5.2 | cis | 4.2.1.3 | anssi | R71 | pcidss4 | 10.3.2, 10.3 |
| |
|
Rule
Ensure Log Files Are Owned By Appropriate User
[ref] | The owner of all log files written by
rsyslog should be
root .
These log files are determined by the second part of each Rule line in
/etc/rsyslog.conf and typically all appear in /var/log .
For each log file LOGFILE referenced in /etc/rsyslog.conf ,
run the following command to inspect the file's owner:
$ ls -l LOGFILE
If the owner is not
root ,
run the following command to
correct this:
$ sudo chown root LOGFILE
| Rationale: | The log files generated by rsyslog contain valuable information regarding system
configuration, user authentication, and other such information. Log files should be
protected from unauthorized access. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_rsyslog_files_ownership | Identifiers: | CCE-85839-9 | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | disa | CCI-001314 | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | ism | 0988, 1405 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-10.5.1, Req-10.5.2 | cis | 4.2.1.3 | anssi | R71 | pcidss4 | 10.3.2, 10.3 |
| |
|
Rule
Ensure System Log Files Have Correct Permissions
[ref] | The file permissions for all log files written by rsyslog should
be set to 640, or more restrictive. These log files are determined by the
second part of each Rule line in /etc/rsyslog.conf and typically
all appear in /var/log . For each log file LOGFILE
referenced in /etc/rsyslog.conf , run the following command to
inspect the file's permissions:
$ ls -l LOGFILE
If the permissions are not 640 or more restrictive, run the following
command to correct this:
$ sudo chmod 640 LOGFILE
" | Rationale: | Log files can contain valuable information regarding system
configuration. If the system log files are not protected unauthorized
users could change the logged data, eliminating their forensic value. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_rsyslog_files_permissions | Identifiers: | CCE-85837-3 | References: | disa | CCI-001314 | ism | 0988, 1405 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | CM-6(a), AC-6(1) | pcidss | Req-10.5.1, Req-10.5.2 | cis | 4.2.1.3 | anssi | R71 | pcidss4 | 10.3.1, 10.3 |
| |
|
Rule
Ensure logging is configured
[ref] | The /etc/rsyslog.conf and /etc/rsyslog.d/*.conf files
specifies rules for logging and which files are to be used to log certain
classes of messages. Warning:
This rule does not come with remediation as there is no one way to solve the problem, and
the requirement from CIS specification does not require one particular way, but persuades
the system administrator to perform configuration suitable for the specific environment.
This also means that the OVAL check is too generic, and the user most probably should
perform additional manual verification. | Rationale: | A great deal of important security-related information is sent via
rsyslog (e.g., successful and failed su attempts, failed login attempts,
root login attempts, etc.). | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_rsyslog_logging_configured | Identifiers: | CCE-92497-7 | References: | | |
|
Group
systemd-journald
Group contains 3 rules |
[ref]
systemd-journald is a system service that collects and stores
logging data. It creates and maintains structured, indexed
journals based on logging information that is received from a
variety of sources.
For more information on systemd-journald and additional systemd-journald configuration options, see
https://systemd.io/. |
Rule
Ensure journald is configured to compress large log files
[ref] | The journald system can compress large log files to avoid fill the system disk. | Rationale: | Log files that are not properly compressed run the risk of growing so large that they fill up the log partition. Valuable logging information could be lost if the log partition becomes full. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_journald_compress | Identifiers: | CCE-91377-2 | References: | | |
|
Rule
Ensure journald is configured to send logs to rsyslog
[ref] | Data from journald may be stored in volatile memory or persisted locally.
Utilities exist to accept remote export of journald logs. | Rationale: | Storing log data on a remote host protects log integrity from local attacks. If an attacker gains root access on the local system, they could tamper with or remove log data that is stored on the local system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_journald_forward_to_syslog | Identifiers: | CCE-91376-4 | References: | | |
|
Rule
Ensure journald is configured to write log files to persistent disk
[ref] | The journald system may store log files in volatile memory or locally on disk.
If the logs are only stored in volatile memory they will we lost upon reboot. | Rationale: | Log files contain valuable data and need to be persistent to aid in possible investigations. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_journald_storage | Identifiers: | CCE-91378-0 | References: | | |
|
Group
Ensure All Logs are Rotated by logrotate
Group contains 3 rules |
[ref]
Edit the file /etc/logrotate.d/syslog . Find the first
line, which should look like this (wrapped for clarity):
/var/log/messages /var/log/secure /var/log/maillog /var/log/spooler \
/var/log/boot.log /var/log/cron {
Edit this line so that it contains a one-space-separated
listing of each log file referenced in /etc/rsyslog.conf .
All logs in use on a system must be rotated regularly, or the
log files will consume disk space over time, eventually interfering
with system operation. The file /etc/logrotate.d/syslog is the
configuration file used by the logrotate program to maintain all
log files written by syslog . By default, it rotates logs weekly and
stores four archival copies of each log. These settings can be
modified by editing /etc/logrotate.conf , but the defaults are
sufficient for purposes of this guide.
Note that logrotate is run nightly by the cron job
/etc/cron.daily/logrotate . If particularly active logs need to be
rotated more often than once a day, some other mechanism must be
used. |
Rule
Ensure logrotate is Installed
[ref] | logrotate is installed by default. The logrotate package can be installed with the following command: $ sudo zypper install logrotate
| Rationale: | The logrotate package provides the logrotate services. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_logrotate_installed | Identifiers: | CCE-92561-0 | References: | cis-csc | 1, 14, 15, 16, 3, 5, 6 | cobit5 | APO11.04, BAI03.05, DSS05.04, DSS05.07, MEA02.01 | disa | CCI-000366 | isa-62443-2009 | 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9 | iso27001-2013 | A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1 | nist | CM-6(a) | nist-csf | PR.PT-1 | pcidss | Req-10.7 | cis | 4.2.4 | anssi | R71 | pcidss4 | 10.5.1, 10.5 |
| |
|
Rule
Ensure Logrotate Runs Periodically
[ref] | The logrotate utility allows for the automatic rotation of
log files. The frequency of rotation is specified in /etc/logrotate.conf ,
which triggers a cron task or a timer. To configure logrotate to run daily, add or correct
the following line in /etc/logrotate.conf :
# rotate log files frequency
daily
| Rationale: | Log files that are not properly rotated run the risk of growing so large
that they fill up the /var/log partition. Valuable logging information could be lost
if the /var/log partition becomes full. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_logrotate_activated | Identifiers: | CCE-85850-6 | References: | cis-csc | 1, 14, 15, 16, 3, 5, 6 | cobit5 | APO11.04, BAI03.05, DSS05.04, DSS05.07, MEA02.01 | disa | CCI-000366 | isa-62443-2009 | 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9 | iso27001-2013 | A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1 | nist | CM-6(a) | nist-csf | PR.PT-1 | pcidss | Req-10.7 | cis | 4.2.4 | anssi | R71 |
| |
|