| Group
Guide to the Secure Configuration of KubeOS
Group contains 3 groups and 200 rules |
| Group
System Settings
Group contains 2 groups and 200 rules |
[ref]
Contains rules that check correct system settings. |
| Group
Installing and Maintaining Software
Group contains 1 group and 200 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
STIG rules for KubeOS
Group contains 200 rules |
[ref]
Traditional Unix security relies heavily on file and
directory permissions to prevent unauthorized users from reading or
modifying files to which they should not have access. |
Rule
KubeOS must be a vendor-supported release.
[ref] |
Verify that the version of KubeOS is vendor supported with the following command:
$ cat /etc/os-release | grep -i KubeOS
NAME="KubeOS"
...
If the installed version of KubeOS is not supported, this is a finding.
| | Rationale: | A KubeOS release is considered supported if the vendor continues to provide security patches for the product. With an unsupported release, it will not be possible to resolve security issues discovered in the system software. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261263r996826_rule | | Identifiers and References | Identifiers:
C-261263 References:
2.1 | |
|
Rule
KubeOS must disable the x86 Ctrl-Alt-Delete key sequence.
[ref] |
Verify KubeOS is not configured to reboot the system when Ctrl-Alt-Delete is pressed with the following command:
$ systemctl status ctrl-alt-del.target
ctrl-alt-del.target
Loaded: masked (Reason: Unit ctrl-alt-del.target is masked.)
Active: inactive (dead)
If ctrl-alt-del.target is not masked, this is a finding.
| | Rationale: | A locally logged-on user who presses Ctrl-Alt-Delete when at the console can reboot the system. If accidentally pressed, as could happen in the case of a mixed OS environment, this can create the risk of short-term loss of availability of systems due to unintentional reboot. In the graphical user interface environment, risk of unintentional reboot from the Ctrl-Alt-Delete sequence is reduced because the user will be prompted before any action is taken. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261266r996292_rule | | Identifiers and References | Identifiers:
C-261266 References:
17.1 | |
|
Rule
KubeOS with a basic input/output system (BIOS) must require authentication upon booting into single-user and maintenance modes.
[ref] |
Note: If the system does not use a BIOS, this requirement is not applicable.
Verify that KubeOS has set an encrypted root password with the following command:
$ awk '/^ *password/ && $1 == "password_pbkdf2"' /boot/grub2/grub.cfg
password_pbkdf2 root grub.pbkdf2.sha512.10000.03255F190F0E2F7B4F0D1C3216012309162F022A7A636771
If the root password entry does not begin with password_pbkdf2, this is a finding.
| | Rationale: | To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by approved PKIs, all systems (e.g., web servers and web portals) must be properly configured to incorporate access control methods that do not rely solely on the possession of a certificate for access. Successful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement.
Access control policies include identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed by the application to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261267r996295_rule | | Identifiers and References | Identifiers:
C-261267 References:
18.1 | |
|
Rule
KubeOS with Unified Extensible Firmware Interface (UEFI) implemented must require authentication upon booting into single-user mode and maintenance.
[ref] |
Note: If the system does not use UEFI, this requirement is not applicable.
Verify that KubeOS has set an encrypted root password with the following command:
$ awk '/^ *password/ && $1 == "password_pbkdf2"' /boot/efi/EFI/openEuler/grub.cfg
password_pbkdf2 root grub.pbkdf2.sha512.10000.03255F190F0E2F7B4F0D1C3216012309162F022A7A636771
If the root password entry does not begin with password_pbkdf2, this is a finding.
| | Rationale: | If the system allows a user to boot into single-user or maintenance mode without authentication, any user that invokes single-user or maintenance mode is granted privileged access to all system information. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261268r996298_rule | | Identifiers and References | Identifiers:
C-261268 References:
18.2 | |
|
Rule
KubeOS must restrict access to the kernel message buffer.
[ref] |
Verify KubeOS is configured to restrict access to the kernel message buffer with the following commands:
$ sysctl kernel.dmesg_restrict
kernel.dmesg_restrict = 1
If kernel.dmesg_restrict is not set to 1 or is missing, this is a finding.
Check that the configuration files are present to enable this kernel parameter:
$ grep -r kernel.dmesg_restrict /run/sysctl.d/* /etc/sysctl.d/* /usr/local/lib/sysctl.d/* /usr/lib/sysctl.d/* /lib/sysctl.d/* /etc/sysctl.conf 2> /dev/null
/etc/sysctl.conf:kernel.dmesg_restrict = 1
/etc/sysctl.d/99-sysctl.conf:kernel.dmesg_restrict = 1
If kernel.dmesg_restrict is not set to 1, is missing or commented out, this is a finding.
If conflicting results are returned, this is a finding.
| | Rationale: |
Restricting access to the kernel message buffer limits access only to root. This prevents attackers from gaining additional system information as a nonprivileged user. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261269r996301_rule | | Identifiers and References | Identifiers:
C-261269 References:
3.1 | |
|
Rule
KubeOS kernel core dumps must be disabled unless needed.
[ref] |
Verify that KubeOS kernel core dumps are disabled unless needed with the following command:
$ systemctl status kdump.service
kdump.service - Load kdump kernel and initrd
Loaded: loaded (/usr/lib/systemd/system/kdump.service; disabled; vendor preset: disabled)
Active: inactive (dead)
If kdump.service is active, ask the system administrator if the use of the service is required and documented with the information system security officer (ISSO).
If the service is active and is not documented, this is a finding.
| | Rationale: | Kernel core dumps may contain sensitive information and unnecessarily consume system resources. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261270r996860_rule | | Identifiers and References | Identifiers:
C-261270 References:
4.1 | |
|
Rule
Address space layout randomization (ASLR) must be implemented by KubeOS to protect memory from unauthorized code execution.
[ref] |
Verify KubeOS implements Address space layout randomization (ASLR) with the following command:
$ sysctl kernel.randomize_va_space
kernel.randomize_va_space = 2
If the kernel parameter randomize_va_space is not equal to 2, or nothing is returned, this is a finding.
| | Rationale: |
Some adversaries launch attacks with the intent of executing code in nonexecutable regions of memory or in memory locations that are prohibited. Security safeguards employed to protect memory include, for example, data execution prevention and address space layout randomization. Data execution prevention safeguards can either be hardware enforced or software enforced, with hardware providing the greater strength of mechanism.
Examples of attacks are buffer overflow attacks. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261271r996306_rule | | Identifiers and References | Identifiers:
C-261271 References:
3.2 | |
|
Rule
KubeOS must implement kptr-restrict to prevent the leaking of internal kernel addresses.
[ref] |
Verify KubeOS prevents leaking of internal kernel addresses with the following command:
$ sysctl kernel.kptr_restrict
kernel.kptr_restrict = 1
If the kernel parameter kptr_restrict is not equal to 1, or nothing is returned, this is a finding.
| | Rationale: |
Some adversaries launch attacks with the intent of executing code in nonexecutable regions of memory or in memory locations that are prohibited. Security safeguards employed to protect memory include, for example, data execution prevention and address space layout randomization. Data execution prevention safeguards can either be hardware enforced or software enforced, with hardware providing the greater strength of mechanism.
Examples of attacks are buffer overflow attacks. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261272r996309_rule | | Identifiers and References | Identifiers:
C-261272 References:
3.3 | |
|
Rule
KubeOS must use vlock to allow for session locking.
[ref] |
Check that KubeOS has the vlock package installed with the following command:
$ vlock -v
If a return value is displayed, the item passes the check. Otherwise, the item fails the check.
| | Rationale: |
A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not want to log out because of the temporary nature of the absence.
The session lock is implemented at the point where session activity can be determined.
Regardless of where the session lock is determined and implemented, once invoked, the session lock must remain in place until the user reauthenticates. No other activity aside from reauthentication must unlock the system. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261276r996316_rule | | Identifiers and References | Identifiers:
C-261276 References:
1.1 | |
|
Rule
KubeOS must not have the telnet-server package installed.
[ref] |
Verify the telnet-server package is not installed on KubeOS.
Check that the telnet-server package is not installed on KubeOS by running the following command:
$ whereis telnetd
If the telnet-server package is installed, this is a finding.
| | Rationale: | It is detrimental for KubeOS to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked, and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors.
KubeOS is capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions and functions).
Examples of nonessential capabilities include but are not limited to games, software packages, tools, and demonstration software not related to requirements or providing a wide array of functionality not required for every mission but which cannot be disabled. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261277r996318_rule | | Identifiers and References | Identifiers:
C-261277 References:
20.1 | |
|
Rule
A separate file system must be used for KubeOS user home directories (such as /home or an equivalent).
[ref] |
Verify that a separate file system/partition has been created for KubeOS nonprivileged local interactive users (those with a UID greater than 1000) home directories with the following command:
$ mount | grep /home
If a return value is displayed, the item passes the check. Otherwise, the item fails the check.
| | Rationale: | The use of separate file systems for different paths can protect the system from failures resulting from a file system becoming full or failing. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261278r996320_rule | | Identifiers and References | Identifiers:
C-261278 References:
5.1 | |
|
Rule
KubeOS must use a separate file system for /var.
[ref] |
Verify that KubeOS has a separate file system/partition for /var with the following command:
$ mount | grep "/var "
If a return value is displayed, the item passes the check. Otherwise, the item fails the check.
| | Rationale: | The use of separate file systems for different paths can protect the system from failures resulting from a file system becoming full or failing. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261279r996322_rule | | Identifiers and References | Identifiers:
C-261279 References:
5.2 | |
|
Rule
KubeOS must use a separate file system for the system audit data path.
[ref] |
Verify that KubeOS has a separate file system/partition for the system audit data path with the following command:
$ mount | grep " /var/log/audit"
If a return value is displayed, the item passes the check. Otherwise, the item fails the check.
| | Rationale: | The use of separate file systems for different paths can protect the system from failures resulting from a file system becoming full or failing. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261280r996324_rule | | Identifiers and References | Identifiers:
C-261280 References:
5.3 | |
|
Rule
KubeOS file systems that are being imported via Network File System (NFS) must be mounted to prevent files with the setuid and setgid bit set from being executed.
[ref] |
Verify KubeOS file systems that are being NFS exported are mounted with the nosuid option with the following command:
$ mount | grep "/persist/nfs" | grep nosuid
If a return value is displayed, the item passes the check. Otherwise, the item fails the check.
| | Rationale: |
The "nosuid" mount option causes the system to not execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261281r996326_rule | | Identifiers and References | Identifiers:
C-261281 References:
5.4 | |
|
Rule
KubeOS file systems that are being imported via Network File System (NFS) must be mounted to prevent binary files from being executed.
[ref] |
Verify KubeOS file systems that are being NFS exported are mounted with the noexec option with the following command:
$ mount | grep "/persist/nfs" | grep noexec
If a return value is displayed, the item passes the check. Otherwise, the item fails the check.
| | Rationale: |
The "noexec" mount option causes the system to not execute binary files. This option must be used for mounting any file system not containing approved binary files, as they may be incompatible. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261282r996328_rule | | Identifiers and References | Identifiers:
C-261282 References:
5.5 | |
|
Rule
KubeOS file systems that contain user home directories must be mounted to prevent files with the setuid and setgid bit set from being executed.
[ref] |
Verify that KubeOS file systems that contain user home directories are mounted with the nosuid option.
Print the currently active file system mount options of the file system(s) that contain the user home directories with the following command:
$ mount | grep "/home " | grep nosuid
If a return value is displayed, the item passes the check. Otherwise, the item fails the check.
| | Rationale: | The "nosuid" mount option causes the system to not execute setuid and setgid files with owner privileges. This option must be used for mounting any file system not containing approved setuid and setguid files. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261285r996838_rule | | Identifiers and References | Identifiers:
C-261285 References:
5.7 | |
|
Rule
KubeOS must disable the file system automounter unless required.
[ref] |
Verify KubeOS disables the ability to automount devices.
Verify the automounter service is active with the following command:
$ systemctl status autofs
autofs.service - Automounts filesystems on demand
Loaded: loaded (/usr/lib/systemd/system/autofs.service; disabled)
Active: inactive (dead)
If the autofs status is set to active and is not documented with the information system security officer (ISSO) as an operational requirement, this is a finding.
| | Rationale: | Automatically mounting file systems permits easy introduction of unknown devices, thereby facilitating malicious activity. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261286r996338_rule | | Identifiers and References | Identifiers:
C-261286 References:
5.8 | |
|
Rule
KubeOS must have directories that contain system commands set to a mode of 755 or less permissive.
[ref] |
Verify that the system command directories have mode 755 or less permissive with the following command:
$ find -L /usr/local/bin /usr/local/sbin -perm /022 -type d -exec stat -c "%n %a" '{}' \;
If any directories are found to be group-writable or world-writable, this is a finding.
| | Rationale: | If KubeOS were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.
This requirement applies to KubeOS with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261287r996341_rule | | Identifiers and References | Identifiers:
C-261287 References:
6.1 | |
|
Rule
KubeOS must have system commands set to a mode of 755 or less permissive.
[ref] |
Verify that the system command directories have mode 755 or less permissive with the following command:
$ find -L /usr/local/bin /usr/local/sbin -perm /022 -type d -exec stat -c "%n %a" '{}' \;
If any directories are found to be group-writable or world-writable, this is a finding.
| | Rationale: | If KubeOS were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.
This requirement applies to KubeOS with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261288r996344_rule | | Identifiers and References | Identifiers:
C-261288 References:
6.2 | |
|
Rule
KubeOS library directories must have mode 755 or less permissive.
[ref] |
Verify the system-wide shared library directories /lib, /lib64, /usr/lib and /usr/lib64 have mode 755 or less permissive with the following command:
$ find /lib /lib64 /usr/lib /usr/lib64 -perm /022 -type d -exec stat -c "%n %a" '{}' \;
If any of the aforementioned directories are found to be group-writable or world-writable, this is a finding.
| | Rationale: | If KubeOS were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.
This requirement applies to KubeOS with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261289r996347_rule | | Identifiers and References | Identifiers:
C-261289 References:
6.3 | |
|
Rule
KubeOS library files must have mode 755 or less permissive.
[ref] |
Verify the systemwide shared library files contained in the directories /lib, /lib64, /usr/lib, and /usr/lib64 have mode 0755 or less permissive.
Check that the systemwide shared library files have mode 0755 or less permissive with the following command:
$ find /lib /lib64 /usr/lib /usr/lib64 -type f -name '*.so*' -perm /022 -exec stat -c "%n %a" {} +
If any output is returned, this is a finding.
| | Rationale: | If KubeOS were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.
This requirement applies to KubeOS with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261290r1102096_rule | | Identifiers and References | Identifiers:
C-261290 References:
6.4 | |
|
Rule
All KubeOS local interactive user home directories must have mode 750 or less permissive.
[ref] |
Note: This may miss interactive users that have been assigned a privileged User Identifier (UID). Evidence of interactive use may be obtained from a number of log files containing system logon information.
Verify the assigned home directory of all KubeOS local interactive users has a mode of 750 or less permissive with the following command:
$ ls -ld $(awk -F: '($3>=1000)&&($7 !~ /nologin/){print $6}' /etc/passwd)
-rwxr-x--- 1 smithj users 18 Mar 5 17:6 /home/smithj
If home directories referenced in /etc/passwd do not have a mode of 750 or less permissive, this is a finding.
| | 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_EC-261291r996352_rule | | Identifiers and References | Identifiers:
C-261291 References:
6.5 | |
|
Rule
All KubeOS local initialization files must have mode 740 or less permissive.
[ref] |
Verify that all KubeOS local initialization files have a mode of 740 or less permissive with the following command:
Note: The example will be for the user smithj, who has a home directory of /home/smithj.
$ ls -al /home/smithj/.* | more
-rw-r-x---- 1 smithj users 896 Mar 10 2011 .profile
-rw-r-x---- 1 smithj users 497 Jan 6 27 .login
-rw-r-x---- 1 smithj users 886 Jan 6 27 .something
If any local initialization files have a mode more permissive than 740, this is a finding.
| | Rationale: | Local initialization files are used to configure the user's shell environment upon logon. Malicious modification of these files could compromise accounts upon logon. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261292r996354_rule | | Identifiers and References | Identifiers:
C-261292 References:
6.6 | |
|
Rule
KubeOS SSH daemon public host key files must have mode 644 or less permissive.
[ref] |
Verify KubeOS SSH daemon public host key files have mode 644 or less permissive with the following command:
Note: SSH public key files may be found in other directories on the system depending on the installation.
$ find /etc/ssh -name 'ssh_host*key.pub' -exec stat -c "%a %n" {} \;
644 /etc/ssh/ssh_host_rsa_key.pub
644 /etc/ssh/ssh_host_dsa_key.pub
644 /etc/ssh/ssh_host_ecdsa_key.pub
644 /etc/ssh/ssh_host_ed25519_key.pub
If any file has a mode more permissive than 644, this is a finding.
| | Rationale: | If a public host key file is modified by an unauthorized user, the SSH service may be compromised. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261293r996357_rule | | Identifiers and References | Identifiers:
C-261293 References:
6.7 | |
|
Rule
KubeOS SSH daemon private host key files must have mode 640 or less permissive.
[ref] |
Verify KubeOS SSH daemon private host key files have mode 640 or less permissive.
The following command will find all SSH private key files on the system with the following command:
$ find / -name '*ssh_host*key' -exec ls -lL {} \;
Check the mode of the private host key files under /etc/ssh file with the following command:
$ find /etc/ssh -name 'ssh_host*key' -exec stat -c "%a %n" {} \;
640 /etc/ssh/ssh_host_rsa_key
640 /etc/ssh/ssh_host_dsa_key
640 /etc/ssh/ssh_host_ecdsa_key
640 /etc/ssh/ssh_host_ed25519_key
If any file has a mode more permissive than 640, this is a finding.
| | Rationale: | If an unauthorized user obtains the private SSH host key file, the host could be impersonated. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261294r996359_rule | | Identifiers and References | Identifiers:
C-261294 References:
6.8 | |
|
Rule
KubeOS library files must be owned by root.
[ref] |
Verify the systemwide shared library files contained in the directories /lib, /lib64, /usr/lib, and /usr/lib64 are owned by root with the following command:
$ find /lib /lib64 /usr/lib /usr/lib64 -type f -name '*.so*' ! -user root -exec stat -c "%n %U" {} +
If any output is returned, this is a finding.
| | Rationale: | If KubeOS were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.
This requirement applies to KubeOS with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261295r1102099_rule | | Identifiers and References | Identifiers:
C-261295 References:
6.9 | |
|
Rule
KubeOS library files must be group-owned by root.
[ref] |
Verify the systemwide shared library files contained in the directories /lib, /lib64, /usr/lib, and /usr/lib64 are group owned by root with the following command:
$ find /lib /lib64 /usr/lib /usr/lib64 -type f -name '*.so*' ! -group root -exec stat -c "%n %G" {} +
If any output is returned, this is a finding.
| | Rationale: | If KubeOS were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.
This requirement applies to KubeOS with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261296r1102102_rule | | Identifiers and References | Identifiers:
C-261296 References:
6.10 | |
|
Rule
KubeOS library directories must be owned by root.
[ref] |
Verify the system-wide shared library directories contained in the directories /lib, /lib64, /usr/lib and /usr/lib64 are owned by root with the following command:
$ find /lib /lib64 /usr/lib /usr/lib64 ! -user root -type d -exec stat -c "%n %U" '{}' \;
If any system wide library directory is returned, this is a finding.
| | Rationale: | If KubeOS were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.
This requirement applies to KubeOS with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261297r996368_rule | | Identifiers and References | Identifiers:
C-261297 References:
6.11 | |
|
Rule
KubeOS library directories must be group-owned by root.
[ref] |
Verify the system-wide shared library directories contained in the directories /lib, /lib64, /usr/lib and /usr/lib64 are group-owned by root with the following command:
$ find /lib /lib64 /usr/lib /usr/lib64 ! -group root -type d -exec stat -c "%n %G" '{}' \;
If any system wide library directory is returned, this is a finding.
| | Rationale: | If KubeOS were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.
This requirement applies to KubeOS with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261298r996371_rule | | Identifiers and References | Identifiers:
C-261298 References:
6.12 | |
|
Rule
KubeOS must have system commands owned by root.
[ref] |
Verify that the system commands are owned by root with the following command:
$ find -L /usr/local/bin /usr/local/sbin ! -user root -type f -exec stat -c "%n %U" '{}' \;
If any system commands are returned, this is a finding.
| | Rationale: | If KubeOS were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.
This requirement applies to KubeOS with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261299r996373_rule | | Identifiers and References | Identifiers:
C-261299 References:
6.13 | |
|
Rule
KubeOS must have system commands group-owned by root or a system account.
[ref] |
Verify that the system commands are group-owned by root with the following command:
$ find -L /usr/local/bin /usr/local/sbin! -group root -type f -exec stat -c "%n %G" '{}' \;
If any system commands are returned, this is a finding.
| | Rationale: | If KubeOS were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.
This requirement applies to KubeOS with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261300r996375_rule | | Identifiers and References | Identifiers:
C-261300 References:
6.14 | |
|
Rule
KubeOS must have directories that contain system commands owned by root.
[ref] |
Verify that the system command directories are owned by root with the following command:
$ find -L /usr/local/bin /usr/local/sbin ! -user root -type d -exec stat -c "%n %U" '{}' \;
If any system command directories are returned, this is a finding.
| | Rationale: | If KubeOS were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.
This requirement applies to KubeOS with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261301r996377_rule | | Identifiers and References | Identifiers:
C-261301 References:
6.15 | |
|
Rule
KubeOS must have directories that contain system commands group-owned by root.
[ref] |
Verify that the system command directories are group-owned by root with the following command:
$ find -L /usr/local/bin /usr/local/sbin ! -group root -type d -exec stat -c "%n %G" '{}' \;
If any system command directories are returned, this is a finding.
| | Rationale: | If KubeOS were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.
This requirement applies to KubeOS with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261302r996380_rule | | Identifiers and References | Identifiers:
C-261302 References:
6.16 | |
|
Rule
All KubeOS files and directories must have a valid owner.
[ref] |
Verify that all KubeOS files and directories on the system have a valid owner with the following command:
Note: The value after -fstype must be replaced with the filesystem type. XFS is used as an example.
$ find / -fstype xfs -nouser
If any files on the system do not have a valid owner, this is a finding.
| | Rationale: | Unowned files and directories may be unintentionally inherited if a user is assigned the same User Identifier (UID) as the UID of the unowned files. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261303r996382_rule | | Identifiers and References | Identifiers:
C-261303 References:
6.17 | |
|
Rule
All KubeOS files and directories must have a valid group owner.
[ref] |
Verify all KubeOS files and directories on the system have a valid group with the following command:
Note: The value after -fstype must be replaced with the filesystem type. XFS is used as an example.
$ find / -fstype xfs -nogroup
If any files on the system do not have a valid group, this is a finding.
| | Rationale: | Files without a valid group owner may be unintentionally inherited if a group is assigned the same Group Identifier (GID) as the GID of the files without a valid group owner. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261304r996384_rule | | Identifiers and References | Identifiers:
C-261304 References:
6.18 | |
|
Rule
All KubeOS local interactive user home directories must be group-owned by the home directory owner
[ref] |
Verify the assigned home directory of all KubeOS local interactive users is group-owned by that user's primary GID with the following command:
Note: This may miss local interactive users that have been assigned a privileged User Identifier (UID). Evidence of interactive use may be obtained from a number of log files containing system logon information. The returned directory /home/smithj is used as an example.
$ awk -F: '($3>=1000)&&($7 !~ /nologin/){print $4, $6}' /etc/passwd)
250:/home/smithj
Check the user's primary group with the following command:
$ grep users /etc/group
users:x:250:smithj,jonesj,jacksons
If the user home directory referenced in /etc/passwd is not group-owned by that user's primary GID, this is a finding.
| | Rationale: | If the Group Identifier (GID) of a local interactive user's home directory is not the same as the primary GID of the user, this would allow unauthorized access to the user's files, and users that share the same group may not be able to access files that they legitimately should. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261305r996387_rule | | Identifiers and References | Identifiers:
C-261305 References:
6.19 | |
|
Rule
All KubeOS world-writable directories must be group-owned by root, sys, bin, or an application group.
[ref] |
Verify all KubeOS world-writable directories are group-owned by root, sys, bin, or an application group with the following command:
$ find / -perm -002 -type d -exec ls -lLd {} \;
drwxrwxrwt. 2 root root 40 Aug 26 13:7 /dev/mqueue
drwxrwxrwt. 2 root root 220 Aug 26 13:23 /dev/shm
drwxrwxrwt. 14 root root 4096 Aug 26 13:29 /tmp
If any world-writable directories are not owned by root, sys, bin, or an application group associated with the directory, this is a finding.
| | Rationale: | If a world-writable directory has the sticky bit set and is not group-owned by a privileged Group Identifier (GID), unauthorized users may be able to modify files created by others.
The only authorized public directories are those temporary directories supplied with the system or those designed to be temporary file repositories. The setting is normally reserved for directories used by the system and by users for temporary file storage, (e.g., /tmp), and for directories requiring global read/write access. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261306r996389_rule | | Identifiers and References | Identifiers:
C-261306 References:
6.20 | |
|
Rule
The sticky bit must be set on all KubeOS world-writable directories.
[ref] |
Verify KubeOS prevents unauthorized and unintended information transfer via the shared system resources with the following command:
$ find / \( -path /.snapshots -o -path /sys -o -path /proc \) -prune -o -perm -002 -type d -exec ls -lLd {} \;
256 0 drwxrwxrwt 1 root root 4096 Jun 14 06:45 /tmp
If any of the returned directories do not have the sticky bit set, or are not documented as having the write permission for the other class, this is a finding.
| | Rationale: | Preventing unauthorized information transfers mitigates the risk of information, including encrypted representations of information, produced by the actions of prior users/roles (or the actions of processes acting on behalf of prior users/roles) from being available to any current users/roles (or current processes) that obtain access to shared system resources (e.g., registers, main memory, and hard disks) after those resources have been released back to information systems. The control of information in shared resources is also commonly referred to as object reuse and residual information protection.
This requirement generally applies to the design of an information technology product, but it can also apply to the configuration of particular information system components that are, or use, such products. This can be verified by acceptance/validation processes in other government agencies.
There may be shared resources with configurable protections (e.g., files in storage) that may be assessed on specific information system components. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261307r996392_rule | | Identifiers and References | Identifiers:
C-261307 References:
6.21 | |
|
Rule
KubeOS must prevent unauthorized users from accessing system error messages.
[ref] |
Verify KubeOS prevents unauthorized users from accessing system error messages.
Check the /var/log/messages file permissions with the following command:
$ stat -c "%n %U:%G %a" /var/log/messages
/var/log/messages root:root 640
Check that permissions.local file contains the correct permissions rules with the following command:
$ grep -i messages /etc/permissions.local
/var/log/messages root:root 640
If the effective permissions do not match the permissions.local file, the command does not return any output, or is commented out, this is a finding.
| | Rationale: | Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify KubeOS or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives.
The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261308r996395_rule | | Identifiers and References | Identifiers:
C-261308 References:
6.22 | |
|
Rule
KubeOS must generate error messages that provide information necessary for corrective actions without revealing information that could be exploited by adversaries.
[ref] |
Verify KubeOS has all system log files under the /var/log directory with a permission set to 640, by using the following command:
Note: The btmp, wtmp, and lastlog files are excluded. Refer to the Vulnerability Discussion for details.
$ find /var/log -perm /137 ! -name '*[bw]tmp' ! -name '*lastlog' -type f -exec stat -c "%n %a" {} \;
If command displays any output, this is a finding.
| | Rationale: | Any operating system providing too much information in error messages risks compromising the data and security of the structure, and content of error messages needs to be carefully considered by the organization.
Organizations carefully consider the structure/content of error messages. The extent to which information systems are able to identify and handle error conditions is guided by organizational policy and operational requirements. Information that could be exploited by adversaries includes, for example, erroneous logon attempts with passwords entered by mistake as the username, mission/business information that can be derived from (if not stated explicitly by) information recorded, and personal information, such as account numbers, social security numbers, and credit card numbers.
The /var/log/btmp, /var/log/wtmp, and /var/log/lastlog files have group write and global read permissions to allow for the lastlog function to perform. Limiting the permissions beyond this configuration will result in the failure of functions that rely on the lastlog database. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261309r996398_rule | | Identifiers and References | Identifiers:
C-261309 References:
6.23 | |
|
Rule
KubeOS must be configured to prohibit or restrict the use of functions, ports, protocols, and/or services as defined in the Ports, Protocols, and Services Management (PPSM) Category Assignments List (CAL) and vulnerability assessments.
[ref] |
Verify KubeOS firewalld.service is enabled and running with the following command:
$ systemctl status firewalld.service
firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: disabled)
Active: active (running) since Wed 2023-11-29 08:12:35 MST
If the service is not enabled and active, this is a finding.
Check the firewall configuration for any unnecessary or prohibited functions, ports, protocols, and/or services by running the following command:
$ firewall-cmd --list-all
Ask the system administrator for the site or program PPSM Component Local Services Assessment (Component Local Services Assessment (CLSA). Verify the services allowed by the firewall match the PPSM CLSA.
If there are any additional ports, protocols, or services that are not included in the PPSM CLSA, this is a finding.
If there are any ports, protocols, or services that are prohibited by the PPSM CAL, this is a finding.
| | Rationale: | To prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types), organizations must disable or restrict unused or unnecessary physical and logical ports/protocols on information systems.
Additionally, operating system remote access functionality must have the capability to immediately disconnect current users remotely accessing the information system and/or disable further remote access. The speed of disconnect or disablement varies based on the criticality of mission functions and the need to eliminate immediate or future remote access to organizational information systems. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261310r996401_rule | | Identifiers and References | Identifiers:
C-261310 References:
7.1 | |
|
Rule
KubeOS clock must, for networked systems, be synchronized to an authoritative time source at least every 24 hours.
[ref] |
Verify that KubeOS clock must be configured to synchronize to an authoritative time source when the time difference is greater than one second with the following command:
$ grep maxpoll /etc/chrony.conf
server 0.us.pool.ntp.mil maxpoll 16
If the server parameter is not set to an authoritative time source, maxpoll is greater than 16, the line is commented out, or the line is missing, this is a finding.
| | Rationale: | Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Sources outside the configured acceptable allowance (drift) may be inaccurate.
Synchronizing internal information system clocks provides uniformity of time stamps for information systems with multiple system clocks and systems connected over a network.
Organizations should consider endpoints that may not have regular access to the authoritative time server (e.g., mobile, teleworking, and tactical endpoints). | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261311r1038944_rule | | Identifiers and References | Identifiers:
C-261311 References:
8.1 | |
|
Rule
KubeOS must not have network interfaces in promiscuous mode unless approved and documented.
[ref] |
Verify KubeOS network interfaces are not in promiscuous mode with the following command:
$ ip link | grep -i promisc
If network interfaces are found on the system in promiscuous mode and their use has not been approved by the ISSO and documented, this is a finding.
| | Rationale: | Network interfaces in promiscuous mode allow for the capture of all network traffic visible to the system. If unauthorized individuals can access these applications, it may allow then to collect information such as logon IDs, passwords, and key exchanges between systems.
If the system is being used to perform a network troubleshooting function, the use of these tools must be documented with the information system security officer (ISSO) and restricted to only authorized personnel. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261312r996406_rule | | Identifiers and References | Identifiers:
C-261312 References:
9.1 | |
|
Rule
KubeOS must not forward Internet Protocol version 4 (IPv4) source-routed packets.
[ref] |
Verify KubeOS does not accept IPv4 source-routed packets with the following command:
$ sysctl net.ipv4.conf.all.accept_source_route
net.ipv4.conf.all.accept_source_route = 0
If the network parameter ipv4.conf.all.accept_source_route is not equal to 0, or nothing is returned, this is a finding.
| | Rationale: |
Source-routed packets allow the source of the packet to suggest that routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routed traffic, such as when IPv4/IPv6 forwarding is enabled and the system is functioning as a router. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261313r996409_rule | | Identifiers and References | Identifiers:
C-261313 References:
3.4 | |
|
Rule
KubeOS must not forward Internet Protocol version 4 (IPv4) source-routed packets by default.
[ref] |
Verify KubeOS does not accept IPv4 source-routed packets by default with the following command:
$ sysctl net.ipv4.conf.default.accept_source_route
net.ipv4.conf.default.accept_source_route = 0
If the network parameter ipv4.conf.default.accept_source_route is not equal to 0, or nothing is returned, this is a finding.
| | Rationale: |
Source-routed packets allow the source of the packet to suggest that routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routed traffic, such as when IPv4 forwarding is enabled and the system is functioning as a router. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261314r996412_rule | | Identifiers and References | Identifiers:
C-261314 References:
3.5 | |
|
Rule
KubeOS must prevent Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirect messages from being accepted.
[ref] |
Verify KubeOS does not accept IPv4 ICMP redirect messages with the following command:
$ sysctl net.ipv4.conf.all.accept_redirects
net.ipv4.conf.all.accept_redirects = 0
If the network parameter ipv4.conf.all.accept_redirects is not equal to 0, or nothing is returned, this is a finding.
| | Rationale: |
ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261315r996415_rule | | Identifiers and References | Identifiers:
C-261315 References:
3.6 | |
|
Rule
KubeOS must not allow interfaces to accept Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirect messages by default.
[ref] |
Verify KubeOS does not accept IPv4 ICMP redirect messages by default with the following command:
$ sysctl net.ipv4.conf.default.accept_redirects
net.ipv4.conf.default.accept_redirects = 0
If the network parameter ipv4.conf.default.accept_redirects is not equal to 0, or nothing is returned, this is a finding.
| | Rationale: |
ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261316r996418_rule | | Identifiers and References | Identifiers:
C-261316 References:
3.7 | |
|
Rule
KubeOS must not send Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirects.
[ref] |
Verify KubeOS does not allow interfaces to perform IPv4 ICMP redirects with the following command:
$ sysctl net.ipv4.conf.all.send_redirects
net.ipv4.conf.all.send_redirects = 0
If the network parameter ipv4.conf.all.send_redirects is not equal to 0, or nothing is returned, this is a finding.
| | Rationale: |
ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages contain information from the system's route table, possibly revealing portions of the network topology. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261317r996421_rule | | Identifiers and References | Identifiers:
C-261317 References:
3.8 | |
|
Rule
KubeOS must not allow interfaces to send Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirect messages by default.
[ref] |
Verify KubeOS does not allow interfaces to perform IPv4 ICMP redirects by default with the following command:
$ sysctl net.ipv4.conf.default.send_redirects
net.ipv4.conf.default.send_redirects = 0
If the network parameter ipv4.conf.default.send_redirects is not equal to 0, or nothing is returned, this is a finding.
| | Rationale: |
ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages contain information from the system's route table, possibly revealing portions of the network topology. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261318r996424_rule | | Identifiers and References | Identifiers:
C-261318 References:
3.9 | |
|
Rule
KubeOS must not be performing Internet Protocol version 4 (IPv4) packet forwarding unless the system is a router.
[ref] |
Verify KubeOS is not performing IPv4 packet forwarding, unless the system is a router with the following command:
$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0
If the network parameter ipv4.ip_forward is not equal to 0, or nothing is returned, this is a finding.
| | Rationale: |
Routing protocol daemons are typically used on routers to exchange network topology information with other routers. If this software is used when not required, system network information may be unnecessarily transmitted across the network. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261319r996427_rule | | Identifiers and References | Identifiers:
C-261319 References:
3.10 | |
|
Rule
KubeOS must be configured to use TCP syncookies.
[ref] |
Verify KubeOS is configured to use IPv4 TCP syncookies with the following command:
$ sysctl net.ipv4.tcp_syncookies
net.ipv4.tcp_syncookies = 1
If the network parameter ipv4.tcp_syncookies is not equal to 1, or nothing is returned, this is a finding.
| | Rationale: |
Denial of service (DoS) is a condition in which a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity.
Managing excess capacity ensures that sufficient capacity is available to counter flooding attacks. Employing increased capacity and service redundancy may reduce the susceptibility to some DoS attacks. Managing excess capacity may include, for example, establishing selected usage priorities, quotas, or partitioning. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261320r996861_rule | | Identifiers and References | Identifiers:
C-261320 References:
3.11 | |
|
Rule
KubeOS must not forward Internet Protocol version 6 (IPv6) source-routed packets.
[ref] |
Verify KubeOS does not accept IPv6 source-routed packets with the following command:
$ sysctl net.ipv6.conf.all.accept_source_route
net.ipv6.conf.all.accept_source_route = 0
If the network parameter ipv6.conf.all.accept_source_route is not equal to 0 or nothing is returned, this is a finding.
| | Rationale: |
Source-routed packets allow the source of the packet to suggest that routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routed traffic, such as when IPv4 forwarding is enabled and the system is functioning as a router. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261321r996433_rule | | Identifiers and References | Identifiers:
C-261321 References:
3.12 | |
|
Rule
KubeOS must not accept IPv6 source-routed packets by default.
[ref] |
Verify KubeOS does not accept IPv6 source-routed packets by default with the following command:
$ sysctl net.ipv6.conf.default.accept_source_route
net.ipv6.conf.default.accept_source_route = 0
If the network parameter ipv6.conf.default.accept_source_route is not equal to 0, or nothing is returned, this is a finding.
| | Rationale: |
Source-routed packets allow the source of the packet to suggest that routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routed traffic, such as when IPv4 forwarding is enabled and the system is functioning as a router. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261322r996436_rule | | Identifiers and References | Identifiers:
C-261322 References:
3.13 | |
|
Rule
KubeOS must prevent Internet Protocol version 6 (IPv6) Internet Control Message Protocol (ICMP) redirect messages from being accepted.
[ref] |
Verify KubeOS does not accept IPv6 ICMP redirect messages with the following command:
$ sysctl net.ipv6.conf.all.accept_redirects
net.ipv6.conf.all.accept_redirects = 0
If the network parameter ipv6.conf.all.accept_redirects is not equal to 0, or nothing is returned, this is a finding.
| | Rationale: |
ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261323r996439_rule | | Identifiers and References | Identifiers:
C-261323 References:
3.14 | |
|
Rule
KubeOS must not allow interfaces to accept Internet Protocol version 6 (IPv6) Internet Control Message Protocol (ICMP) redirect messages by default.
[ref] |
Verify KubeOS does not allow IPv6 ICMP redirect messages by default with the following command:
$ sysctl net.ipv6.conf.default.accept_redirects
net.ipv6.conf.default.accept_redirects = 0
If the network parameter ipv6.conf.default.accept_redirects is not equal to 0, or nothing is returned, this is a finding.
| | Rationale: |
ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261324r996442_rule | | Identifiers and References | Identifiers:
C-261324 References:
3.15 | |
|
Rule
KubeOS must not be performing Internet Protocol version 6 (IPv6) packet forwarding unless the system is a router.
[ref] |
Verify KubeOS is not performing IPv6 packet forwarding, unless the system is a router with the following command:
$ sysctl net.ipv6.conf.all.forwarding
net.ipv6.conf.all.forwarding = 0
If the network parameter ipv6.conf.all.forwarding is not equal to 0, or nothing is returned, this is a finding.
| | Rationale: |
Routing protocol daemons are typically used on routers to exchange network topology information with other routers. If this software is used when not required, system network information may be unnecessarily transmitted across the network. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261325r996445_rule | | Identifiers and References | Identifiers:
C-261325 References:
3.16 | |
|
Rule
KubeOS must not be performing Internet Protocol version 6 (IPv6) packet forwarding by default unless the system is a router.
[ref] |
Verify KubeOS is not performing IPv6 packet forwarding by default, unless the system is a router with the following command:
$ sysctl net.ipv6.conf.default.forwarding
net.ipv6.conf.default.forwarding = 0
If the network parameter ipv6.conf.default.forwarding is not equal to 0, or nothing is returned, this is a finding.
| | Rationale: |
Routing protocol daemons are typically used on routers to exchange network topology information with other routers. If this software is used when not required, system network information may be unnecessarily transmitted across the network. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261326r996448_rule | | Identifiers and References | Identifiers:
C-261326 References:
3.17 | |
|
Rule
KubeOS must have SSH installed to protect the confidentiality and integrity of transmitted information.
[ref] |
Verify the SSH package is installed by using the following command:
$ find / -name ssh-keygen
/usr/bin/ssh-keygen
If the openssh package is not installed, this is a finding.
| | Rationale: |
Without protection of the transmitted information, confidentiality and integrity may be compromised because unprotected communications can be intercepted and either read or altered.
This requirement applies to both internal and external networks and all types of information system components from which information can be transmitted (e.g., servers, mobile devices, notebook computers, printers, copiers, scanners, and facsimile machines). Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification.
Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, logical means (cryptography) do not have to be employed, and vice versa. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261327r996450_rule | | Identifiers and References | Identifiers:
C-261327 References:
10.10 | |
|
Rule
KubeOS must use SSH to protect the confidentiality and integrity of transmitted information.
[ref] |
Verify sshd.service is enabled and active by using the following command:
$ systemctl status sshd.service | grep -i active
Active: active (running) since Wed 2023-11-29 09:49:45 MST; 2 months 23 days ago
If openssh.service is not active, this is a finding.
| | Rationale: |
Without protection of the transmitted information, confidentiality and integrity may be compromised because unprotected communications can be intercepted and either read or altered.
This requirement applies to both internal and external networks and all types of information system components from which information can be transmitted (e.g., servers, mobile devices, notebook computers, printers, copiers, scanners, and facsimile machines). Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification.
Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, logical means (cryptography) do not have to be employed, and vice versa. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261328r996453_rule | | Identifiers and References | Identifiers:
C-261328 References:
10.11 | |
|
Rule
KubeOS must not allow unattended or automatic logon via SSH.
[ref] |
Verify KubeOS disables unattended or automatic logon via SSH with the following command:
$ grep -w "^PermitEmptyPasswords no" /etc/ssh/sshd_config
PermitEmptyPasswords no
$ grep -w "^PermitUserEnvironment no" /etc/ssh/sshd_config
PermitUserEnvironment no
If PermitEmptyPasswords or PermitUserEnvironment keywords are not set to no, are commented out, or are missing completely, this is a finding.
| | Rationale: | Failure to restrict system access via SSH to authenticated users negatively impacts KubeOS security. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261330r996457_rule | | Identifiers and References | Identifiers:
C-261330 References:
10.12 | |
|
Rule
KubeOS must be configured so that all network connections associated with SSH traffic terminate after becoming unresponsive.
[ref] |
Verify the SSH server automatically terminates a user session after the SSH client has become unresponsive by using the following command:
$ /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '\r' | tr '\n' ' ' | xargs grep -iH '^\s*clientalivecountmax'
/etc/ssh/sshd_config:ClientAliveCountMax 1
If ClientAliveCountMax is not set to 1, is commented out, missing, or conflicting results are returned, this is a finding.
| | Rationale: | Terminating an unresponsive SSH session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. In addition, quickly terminating an idle SSH session will also free up resources committed by the managed network element.
Terminating network connections associated with communications sessions includes, for example, deallocating associated TCP/IP address/port pairs at the operating system level and deallocating networking assignments at the application level if multiple application sessions are using a single operating system-level network connection. This does not mean the operating system terminates all sessions or network access; it only ends the unresponsive session and releases the resources associated with that session. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261331r996459_rule | | Identifiers and References | Identifiers:
C-261331 References:
10.1 | |
|
Rule
KubeOS must be configured so that all network connections associated with SSH traffic are terminated after 10 minutes of becoming unresponsive.
[ref] |
Verify the SSH server automatically terminates a user session after the SSH client has been unresponsive for 10 minutes by using the following command:
$ /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '\r' | tr '\n' ' ' | xargs grep -iH '^\s*clientaliveinterval'
/etc/ssh/sshd_config:ClientAliveInterval 600
If ClientAliveInterval is not set to 600 or less, is commented out, missing, or conflicting results are returned, this is a finding.
| | Rationale: | Terminating an unresponsive SSH session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. In addition, quickly terminating an idle SSH session will also free up resources committed by the managed network element.
Terminating network connections associated with communications sessions includes, for example, deallocating associated TCP/IP address/port pairs at the operating system level and deallocating networking assignments at the application level if multiple application sessions are using a single operating system-level network connection. This does not mean that the operating system terminates all sessions or network access; it only ends the unresponsive session and releases the resources associated with that session. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261332r996462_rule | | Identifiers and References | Identifiers:
C-261332 References:
10.2 | |
|
Rule
KubeOS SSH daemon must disable forwarded remote X connections for interactive users, unless to fulfill documented and validated mission requirements.
[ref] |
Verify KubeOS SSH daemon remote X forwarded connections for interactive users are disabled with the following command:
$ /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '\r' | tr '\n' ' ' | xargs grep -iH '^\s*x11forwarding'
/etc/ssh/sshd_config:X11Forwarding no
If the X11Forwarding keyword is set to yes and is not documented with the information system security officer (ISSO) as an operational requirement, is commented out, or the line is missing, this is a finding.
| | Rationale: | The security risk of using X11 forwarding is that the client's X11 display server may be exposed to attack when the SSH client requests forwarding. A system administrator may have a stance in which they want to protect clients that may expose themselves to attack by unwittingly requesting X11 forwarding, which can warrant a ''no'' setting.
X11 forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the user's X11 authorization database) can access the local X11 display through the forwarded connection. An attacker may then be able to perform activities such as keystroke monitoring if the ForwardX11Trusted option is also enabled.
If X11 services are not required for the system's intended function, they should be disabled or restricted as appropriate to the system's needs. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261333r996464_rule | | Identifiers and References | Identifiers:
C-261333 References:
10.3 | |
|
Rule
KubeOS must implement approved encryption to protect the confidentiality of SSH remote connections.
[ref] |
Verify that KubeOS implements encryption to protect the confidentiality of SSH remote connections with the following command:
$ grep -w "^Ciphers aes256-ctr,aes192-ctr,aes128-ctr" /etc/ssh/sshd_config
Ciphers aes256-ctr,aes192-ctr,aes128-ctr
If any ciphers other than aes256-ctr, aes192-ctr, or aes128-ctr are listed, the order differs from the example above, the line is commented out, or the Ciphers keyword is missing, or conflicting results are returned, this is a finding.
| | Rationale: | Without confidentiality protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session.
Remote access is access to nonpublic information systems by an authorized user (or an information system) communicating through an external, nonorganization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless.
Encryption provides a means to secure the remote connection to prevent unauthorized access to the data traversing the remote access connection (e.g., RDP), thereby providing a degree of confidentiality. The encryption strength of a mechanism is selected based on the security categorization of the information.
The system will attempt to use the first cipher presented by the client that matches the server list. Listing the values "strongest to weakest" is a method to ensure the use of the strongest cipher available to secure the SSH connection. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261334r996467_rule | | Identifiers and References | Identifiers:
C-261334 References:
10.13 | |
|
Rule
KubeOS SSH daemon must be configured to only use Message Authentication Codes (MACs) employing FIPS 140-2/140-3 approved cryptographic hash algorithms.
[ref] |
Verify KubeOS SSH daemon is configured to only use MACs that employ FIPS 140-2/140-3 approved hashes with the following command:
$ grep -w "^MACs hmac-sha2-512,hmac-sha2-256" /etc/ssh/sshd_config
MACs hmac-sha2-512,hmac-sha2-256
If any ciphers other than hmac-sha2-512 or hmac-sha2-256 are listed, the order differs from the example above, is commented out, missing, or conflicting results are returned, this is a finding.
| | Rationale: | Without cryptographic integrity protections, information can be altered by unauthorized users without detection.
Remote access (e.g., RDP) is access to nonpublic information systems by an authorized user (or an information system) communicating through an external, nonorganization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless.
Cryptographic mechanisms used for protecting the integrity of information include, for example, signed hash functions using asymmetric cryptography enabling distribution of the public key to verify the hash information while maintaining the confidentiality of the secret key used to generate the hash.
The system will attempt to use the first hash presented by the client that matches the server list. Listing the values "strongest to weakest" is a method to ensure the use of the strongest hash available to secure the SSH connection. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261335r996469_rule | | Identifiers and References | Identifiers:
C-261335 References:
10.14 | |
|
Rule
KubeOS SSH server must be configured to use only FIPS 140-2/140-3 validated key exchange algorithms.
[ref] |
Verify that the SSH server is configured to use only FIPS 140-2/140-3 validated key exchange algorithms with the following command:
$ grep -w "^KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256" /etc/ssh/sshd_config
KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256
If KexAlgorithms does not contain the list of algorithms in the exact order, is commented out, missing, or conflicting results are returned, this is a finding.
| | Rationale: | Without cryptographic integrity protections provided by FIPS 140-2/140-3 validated cryptographic algorithms, information can be viewed and altered by unauthorized users without detection.
The system will attempt to use the first algorithm presented by the client that matches the server list. Listing the values "strongest to weakest" is a method to ensure the use of the strongest algorithm available to secure the SSH connection. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261336r996472_rule | | Identifiers and References | Identifiers:
C-261336 References:
10.15 | |
|
Rule
KubeOS must deny direct logons to the root account using remote access via SSH.
[ref] |
Verify KubeOS denies direct logons to the root account using remote access via SSH with the following command:
$ /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '\r' | tr '\n' ' ' | xargs grep -iH '^\s*permitrootlogin'
/etc/ssh/sshd_config:PermitRootLogin no
If the PermitRootLogin keyword is set to yes, is commented out, missing, or conflicting results are returned, this is a finding.
| | Rationale: | To ensure individual accountability and prevent unauthorized access, organizational users must be individually identified and authenticated.
A group authenticator is a generic account used by multiple individuals. Use of a group authenticator alone does not uniquely identify individual users. Examples of the group authenticator is the Unix OS "root" user account, the Windows "Administrator" account, the "sa" account, or a "helpdesk" account.
For example, the Unix and Windows KubeOS offer a "switch user" capability, allowing users to authenticate with their individual credentials and, when needed, "switch" to the administrator role. This method provides for unique individual authentication prior to using a group authenticator.
Users (and any processes acting on behalf of users) need to be uniquely identified and authenticated for all accesses other than those accesses explicitly identified and documented by the organization, which outlines specific user actions that can be performed on KubeOS without identification or authentication.
Requiring individuals to be authenticated with an individual authenticator prior to using a group authenticator allows for traceability of actions, as well as adding an additional level of protection of the actions that can be taken with group account knowledge. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261337r996844_rule | | Identifiers and References | Identifiers:
C-261337 References:
10.4 | |
|
Rule
KubeOS must log SSH connection attempts and failures to the server.
[ref] |
Verify SSH is configured to verbosely log connection attempts and failed logon attempts to KubeOS with the following command:
$ /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '\r' | tr '\n' ' ' | xargs grep -iH '^\s*loglevel'
/etc/ssh/sshd_config:LogLevel VERBOSE
If LogLevel is not set to VERBOSE, is commented out, missing, or conflicting results are returned, this is a finding.
| | Rationale: | Remote access services, such as those providing remote access to network devices and information systems, which lack automated monitoring capabilities, increase risk and make remote user access management difficult at best.
Remote access is access to nonpublic information systems by an authorized user (or an information system) communicating through an external, nonorganization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless.
Automated monitoring of remote access sessions allows organizations to detect cyberattacks and also ensure ongoing compliance with remote access policies by auditing connection activities of remote access capabilities, such as Remote Desktop Protocol (RDP), on a variety of information system components (e.g., servers, workstations, notebook computers, smartphones, and tablets). | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261338r996845_rule | | Identifiers and References | Identifiers:
C-261338 References:
10.5 | |
|
Rule
KubeOS must display the date and time of the last successful account logon upon an SSH logon.
[ref] |
Verify all remote connections via SSH to KubeOS display feedback on when account accesses last occurred with the following command:
$ /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '\r' | tr '\n' ' ' | xargs grep -iH '^\s*printlastlog'
/etc/ssh/sshd_config:PrintLastLog yes
If the PrintLastLog is not set to yes, is commented out, missing, or conflicting results are returned, this is a finding.
| | Rationale: | Providing users with feedback on when account accesses via SSH last occurred facilitates user recognition and reporting of unauthorized account use. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261339r996480_rule | | Identifiers and References | Identifiers:
C-261339 References:
10.6 | |
|
Rule
KubeOS SSH daemon must be configured to not allow authentication using known hosts authentication.
[ref] |
Verify KubeOS SSH daemon is configured to not allow authentication using known hosts authentication with the following command:
$ /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '\r' | tr '\n' ' ' | xargs grep -iH '^\s*ignoreuserknownhosts'
/etc/ssh/sshd_config:IgnoreUserKnownHosts yes
If IgnoreUserKnownHosts is not set to no, is commented out, missing, or conflicting results are returned, this is a finding.
| | Rationale: | Configuring this setting for the SSH daemon provides additional assurance that remote logon via SSH will require a password, even in the event of misconfiguration elsewhere. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261340r996483_rule | | Identifiers and References | Identifiers:
C-261340 References:
10.7 | |
|
Rule
KubeOS SSH daemon must perform strict mode checking of home directory configuration files.
[ref] |
Verify KubeOS SSH daemon performs strict mode checking of home directory configuration files with the following command:
$ /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '\r' | tr '\n' ' ' | xargs grep -iH '^\s*strictmodes'
/etc/ssh/sshd_config:StrictModes yes
If StrictModes is not set to yes, is commented out, missing, or conflicting results are returned, this is a finding.
| | Rationale: | If other users have access to modify user-specific SSH configuration files, they may be able to log on to the system as another user. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261341r996486_rule | | Identifiers and References | Identifiers:
C-261341 References:
10.8 | |
|
Rule
KubeOS, for PKI-based authentication, must enforce authorized access to the corresponding private key.
[ref] |
Verify the SSH private key files have a passcode.
For each private key stored on the system, use the following command (with the example of /etc/ssh/ssh_host_dsa_key):
$ ssh-keygen -y -f /etc/ssh/ssh_host_dsa_key
Load key "/etc/ssh/ssh_host_dsa_key": Permission denied
If the contents of any key are displayed, this is a finding.
It can not be scanned automatically, please check it manually.
Check whether all SSH private key files have proper passcode protection to prevent unauthorized access.
| | Rationale: | If the private key is discovered, an attacker can use the key to authenticate as an authorized user and gain access to the network infrastructure.
The cornerstone of the PKI is the private key used to encrypt or digitally sign information.
If the private key is stolen, this will lead to the compromise of the authentication and nonrepudiation gained through PKI because the attacker can use the private key to digitally sign documents and pretend to be the authorized user.
Both the holders of a digital certificate and the issuing authority must protect the computers, storage devices, or whatever they use to keep the private keys. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261342r996488_rule | | Identifiers and References | Identifiers:
C-261342 References:
10.9 | |
|
Rule
There must be no .shosts files on KubeOS.
[ref] |
Verify there are no .shosts files on KubeOS with the following command:
$ find / \( -path /.snapshots -o -path /sys -o -path /proc \) -prune -o -name '.shosts' -print
If any .shosts files are found on the system, this is a finding.
| | Rationale: | The .shosts files are used to configure host-based authentication for individual users or the system via SSH. Host-based authentication is not sufficient for preventing unauthorized access to the system as it does not require interactive identification and authentication of a connection request or for the use of two-factor authentication. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261343r996489_rule | | Identifiers and References | Identifiers:
C-261343 References:
10.16 | |
|
Rule
There must be no shosts.equiv files on KubeOS.
[ref] |
Verify there are no shosts.equiv files on KubeOS with the following command:
$ find /etc -name shosts.equiv
If any shosts.equiv files are found on the system, this is a finding.
| | Rationale: | The shosts.equiv files are used to configure host-based authentication for the system via SSH. Host-based authentication is not sufficient for preventing unauthorized access to the system, as it does not require interactive identification and authentication of a connection request, or for the use of two-factor authentication. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261344r996490_rule | | Identifiers and References | Identifiers:
C-261344 References:
10.17 | |
|
Rule
KubeOS wireless network adapters must be disabled unless approved and documented.
[ref] |
Verify that KubeOS has no wireless network adapters enabled with the following command:
$ wicked show all
...
wlan0 up
link: #3, state up, mtu 1500
type: wireless, hwaddr 06:00:00:00:00:02
config: wicked:xml:/etc/wicked/ifconfig/wlan0.xml
leases: ipv4 dhcp granted
addr: ipv4 10.0.0.101/16 [dhcp]
route: ipv4 default via 10.0.0.1 proto dhcp
If a wireless interface is configured and has not been documented and approved by the AO, this is a finding.
It can not be scanned automatically, please check it manually.
Manually inspect the system to verify all wireless network adapters are disabled unless approved and documented by the AO.
| | Rationale: | Without protection of communications with wireless peripherals, confidentiality and integrity may be compromised because unprotected communications can be intercepted and either read, altered, or used to compromise KubeOS.
This requirement applies to wireless peripheral technologies (e.g., wireless mice, keyboards, displays, etc.) used with a KubeOS. Wireless peripherals (e.g., Wi-Fi/Bluetooth/IR keyboards, mice, pointing devices, and Near Field Communications [NFC]) present a unique challenge by creating an open, unsecured port on a computer. Wireless peripherals must meet requirements for wireless data transmission and be approved for use by the AO. Even though some wireless peripherals, such as mice and pointing devices, do not ordinarily carry information that need to be protected, modification of communications with these wireless peripherals may be used to compromise KubeOS. Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification.
Protecting the confidentiality and integrity of communications with wireless peripherals can be accomplished by physical means (e.g., employing physical barriers to wireless radio frequencies) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa. If the wireless peripheral is only passing telemetry data, encryption of the data may not be required. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261346r996496_rule | | Identifiers and References | Identifiers:
C-261346 References:
11.1 | |
|
Rule
KubeOS must disable the USB mass storage kernel module.
[ref] |
Verify KubeOS does not automount USB mass storage devices when connected to the host with the following command:
$ grep usb-storage /etc/modprobe.d/50-blacklist.conf
blacklist usb-storage
If the line is commented out or the line is missing, this is a finding.
It can not be scanned automatically, please check it manually.
Manually check the blacklist configuration to ensure the USB mass storage kernel module is properly disabled.
| | Rationale: | Without identifying devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity.
Peripherals include but are not limited to such devices as flash drives, external storage, and printers. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261347r996498_rule | | Identifiers and References | Identifiers:
C-261347 References:
12.1 | |
|
Rule
All KubeOS local interactive user accounts, upon creation, must be assigned a home directory.
[ref] |
Verify all KubeOS local interactive users on the system are assigned a home directory upon creation with the following command:
$ grep -i "^CREATE_HOME yes" /etc/login.defs
CREATE_HOME yes
If the CREATE_HOME parameter is not set to yes, the line is commented out, or the line is missing, this is a finding.
| | Rationale: | If local interactive users are not assigned a valid home directory, there is no place for the storage and control of files they should own. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261348r996500_rule | | Identifiers and References | Identifiers:
C-261348 References:
13.1 | |
|
Rule
KubeOS default permissions must be defined in such a way that all authenticated users can only read and modify their own files.
[ref] |
Verify KubeOS defines default permissions for all authenticated users in such a way that the users can only read and modify their own files with the following command:
$ grep -i "^UMASK 077" /etc/login.defs
UMASK 077
If the UMASK variable is set to 000, the severity is raised to a CAT I and this is a finding.
If the value of UMASK is not set to 077, the line is commented out, or the line is missing, this is a finding.
| | Rationale: | Setting the most restrictive default permissions ensures that when new accounts are created, they do not have unnecessary access. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261349r996502_rule | | Identifiers and References | Identifiers:
C-261349 References:
13.2 | |
|
Rule
KubeOS shadow password suite must be configured to enforce a delay of at least five seconds between logon prompts following a failed logon attempt.
[ref] |
Verify KubeOS enforces a delay of at least five seconds between logon prompts following a failed logon attempt with the following command:
$ grep -wi "^fail_delay 5" /etc/login.defs
FAIL_DELAY 5
If the value of FAIL_DELAY is not set to 5 or greater, the line is commented out, or the line is missing, this is a finding.
| | Rationale: | Limiting the number of logon attempts over a certain time interval reduces the chances that an unauthorized user may gain access to an account. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261350r996504_rule | | Identifiers and References | Identifiers:
C-261350 References:
13.3 | |
|
Rule
All KubeOS local interactive users must have a home directory assigned in the /etc/passwd file.
[ref] |
Verify KubeOS local interactive users on the system have a home directory assigned with the following command:
getent passwd | while IFS=: read user _ _ _ _ homedir shell; do
if grep -qxF $shell /etc/shells 2>/dev/null; then
if [ ! -d $homedir ]; then
echo $user: fail
fi
fi
done
If any interactive users do not have a home directory assigned, this is a finding.
| | Rationale: | If local interactive users are not assigned a valid home directory, there is no place for the storage and control of files they should own. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261351r996506_rule | | Identifiers and References | Identifiers:
C-261351 References:
13.4 | |
|
Rule
All KubeOS local interactive user home directories defined in the /etc/passwd file must exist.
[ref] |
Verify the assigned home directory of all KubeOS local interactive users on the system exists.
Check the home directory assignment for all local interactive nonprivileged users on the system with the following command:
$ awk -F: '($3>=1000)&&($7 !~ /nologin/){print $1, $6}' /etc/passwd
smithj /home/smithj
Note: This may miss interactive users that have been assigned a privileged User Identifier (UID). Evidence of interactive use may be obtained from a number of log files containing system logon information.
Check that all referenced home directories exist with the following command:
$ pwck -r
user 'smithj': directory '/home/smithj' does not exist
If any home directories referenced in /etc/passwd are returned as not defined, this is a finding.
| | 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 (DoS) 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_EC-261352r996862_rule | | Identifiers and References | Identifiers:
C-261352 References:
6.24 | |
|
Rule
All KubeOS local interactive user initialization files executable search paths must contain only paths that resolve to the users
[ref] |
Verify that all KubeOS local interactive user initialization files executable search path statements do not contain statements that will reference a working directory other than the user's home directory with the following command:
Note: The example will be for the user smithj, who has a home directory of /home/smithj.
$ grep -i path= /home/<username>/.*
/home/<username>/.bash_profile:PATH=$PATH:$HOME/.local/bin:$HOME/bin
If any local interactive user initialization files have executable search path statements that include directories outside of their home directory, and the additional path statements are not documented with the ISSO as an operational requirement, this is a finding.
| | Rationale: | The executable search path (typically the PATH environment variable) contains a list of directories for the shell to search to find executables. If this path includes the current working directory (other than the user's home directory), executables in these directories may be executed instead of system commands. This variable is formatted as a colon-separated list of directories. If there is an empty entry, such as a leading or trailing colon or two consecutive colons, this is interpreted as the current working directory. If deviations from the default system search path for the local interactive user are required, they must be documented with the information system security officer (ISSO). | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261353r996512_rule | | Identifiers and References | Identifiers:
C-261353 References:
13.5 | |
|
Rule
All KubeOS local initialization files must not execute world-writable programs.
[ref] |
Verify that KubeOS local initialization files do not execute world-writable programs with the following command:
$ find / -xdev -perm -002 -type f -exec ls -ld {} \;
If any local initialization files are found to reference world-writable files, this is a finding.
| | Rationale: | If user start-up files execute world-writable programs, especially in unprotected directories, they could be maliciously modified to destroy user files or otherwise compromise the system at the user level. If the system is compromised at the user level, it is easier to elevate privileges to eventually compromise the system at the root and network level. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261354r996514_rule | | Identifiers and References | Identifiers:
C-261354 References:
6.25 | |
|
Rule
KubeOS must automatically expire temporary accounts within 72 hours.
[ref] |
Verify temporary accounts have been provisioned with an expiration date of 72 hours with the following command:
$ chage -l <temporary_account_name> | grep -E '(Password|Account) expires'
If any temporary accounts have no expiration date set or do not expire within 72 hours, this is a finding.
It can not be scanned automatically, please check it manually.
Manually verify all temporary accounts are configured to expire within 72 hours as required.
| | Rationale: | Temporary accounts are privileged or nonprivileged accounts established during pressing circumstances, such as new software or hardware configuration or an incident response, where the need for prompt account activation requires bypassing normal account authorization procedures. If any inactive temporary accounts are left enabled on the system and are not either manually removed or automatically expired within 72 hours, the security posture of the system will be degraded and exposed to exploitation by unauthorized users or insider threat actors.
Temporary accounts are different from emergency accounts. Emergency accounts, also known as "last resort" or "break glass" accounts, are local logon accounts enabled on the system for emergency use by authorized system administrators to manage a system when standard logon methods are failing or not available. Emergency accounts are not subject to manual removal or scheduled expiration requirements.
The automatic expiration of temporary accounts may be extended as needed by the circumstances, but it must not be extended indefinitely. A documented permanent account should be established for privileged users who need long-term maintenance accounts. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261355r996516_rule | | Identifiers and References | Identifiers:
C-261355 References:
13.6 | |
|
Rule
KubeOS must never automatically remove or disable emergency administrator accounts.
[ref] |
Verify KubeOS is configured such that emergency administrator accounts are never automatically removed or disabled with the following command:
Note: Root is typically the account of last resort on a system and is also used as the example emergency administrator account. If another account is being used as the emergency administrator account, the command should be used against that account.
$ chage -l <emergency_administrator_account_name> | grep -E '(Password|Account) expires'
Password expires: never
Account expires: never
If Password expires or Account expires is set to anything other than never, this is a finding.
It can not be scanned automatically, please check it manually.
Manually verify emergency administrator accounts are configured to never expire.
| | Rationale: | Emergency administrator accounts, also known as "last resort" or "break glass" accounts, are local logon accounts enabled on the system for emergency use by authorized system administrators to manage a system when standard logon methods are failing or not available. Emergency accounts are not subject to manual removal or scheduled expiration requirements. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261356r996518_rule | | Identifiers and References | Identifiers:
C-261356 References:
13.7 | |
|
Rule
KubeOS must not have unnecessary accounts.
[ref] |
Verify all KubeOS accounts are assigned to an active system, application, or user account with the following command:
$ more /etc/passwd
root:x:0:0:root:/root:/bin/bash
...
games:x:12:100:Games account:/var/games:/bin/bash
Obtain the list of authorized system accounts from the information system security officer.
If the accounts on the system do not match the provided documentation, this is a finding.
| | Rationale: | Accounts providing no operational purpose provide additional opportunities for system compromise. Unnecessary accounts include user accounts for individuals not requiring access to the system and application accounts for applications not installed on the system. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261357r996521_rule | | Identifiers and References | Identifiers:
C-261357 References:
13.8 | |
|
Rule
KubeOS must not have unnecessary account capabilities.
[ref] |
Verify all noninteractive KubeOS accounts do not have an interactive shell assigned to them with the following command:
Check the system accounts on the system.
$ awk -F: 'NR==FNR { shells[$1]=1; next } $3 > 1000 && ($7 in shells) ' /etc/shells /etc/passwd
If noninteractive accounts such as games or nobody are listed with an interactive shell, this is a finding.
| | Rationale: | Accounts providing no operational purpose provide additional opportunities for system compromise. Therefore all necessary noninteractive accounts should not have an interactive shell assigned to them. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261358r996829_rule | | Identifiers and References | Identifiers:
C-261358 References:
13.9 | |
|
Rule
KubeOS root account must be the only account with unrestricted access to the system.
[ref] |
Verify that KubeOS root account is the only account with unrestricted access to the system with the following command:
$ awk -F: '$3 == 0 {print $1}' /etc/passwd
root
If any accounts other than root are listed, this is a finding.
| | Rationale: | If an account other than root also has a User Identifier (UID) of "0", it has root authority, giving that account unrestricted access to the entire KubeOS. Multiple accounts with a UID of "0" afford an opportunity for potential intruders to guess a password for a privileged account. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261359r996526_rule | | Identifiers and References | Identifiers:
C-261359 References:
13.42 | |
|
Rule
KubeOS must disable account identifiers (individuals, groups, roles, and devices) after 35 days of inactivity after password expiration.
[ref] |
Verify KubeOS disables account identifiers after 35 days of inactivity after the password expiration with the following command:
$ grep -i '^INACTIVE=35' /etc/default/useradd
INACTIVE=35
If the value for INACTIVE is not set to a value greater than 0 and less than or equal to 35, if the line is commented out, or the line is missing, this is a finding.
| | 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. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained.
KubeOS must track periods of inactivity and disable application identifiers after 35 days of inactivity. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261360r996529_rule | | Identifiers and References | Identifiers:
C-261360 References:
13.10 | |
|
Rule
KubeOS must not have duplicate User IDs (UIDs) for interactive users.
[ref] |
Verify KubeOS contains no duplicate UIDs for interactive users with the following command:
$ awk -F ":" 'list[$3]++{print $1, $3}' /etc/passwd
If output is produced, this is a finding.
| | Rationale: | To ensure accountability and prevent unauthenticated access, interactive users must be identified and authenticated to prevent potential misuse and compromise of the system.
Interactive users include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors). Interactive users (and processes acting on behalf of users) must be uniquely identified and authenticated to all accesses, except for the following:
1) Accesses explicitly identified and documented by the organization. Organizations document specific user actions that can be performed on the information system without identification or authentication; and
2) Accesses that occur through authorized use of group authenticators without individual authentication. Organizations may require unique identification of individuals in group accounts (e.g., shared privilege accounts) or for detailed accountability of individual activity. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261361r996530_rule | | Identifiers and References | Identifiers:
C-261361 References:
13.11 | |
|
Rule
KubeOS must display the date and time of the last successful account logon upon logon.
[ref] |
Verify KubeOS users are provided with feedback on when account accesses last occurred with the following command:
$ grep "session required pam_lastlog.so showfailed" /etc/pam.d/login
If pam_lastlog is missing from /etc/pam.d/login file, the silent option is present, the second column value different from requisite, or the returned line is commented out, this is a finding.
| | Rationale: | Providing users with feedback on when account accesses last occurred facilitates user recognition and reporting of unauthorized account use. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261362r996533_rule | | Identifiers and References | Identifiers:
C-261362 References:
13.12 | |
|
Rule
KubeOS must initiate a session lock after a 15-minute period of inactivity.
[ref] |
Verify KubeOS must initiate a session logout after a 15-minute period of inactivity for all connection type with the following command:
$ grep -w "^TMOUT=900" /etc/profile.d/autologout.sh
$ grep -w "^readonly TMOUT" /etc/profile.d/autologout.sh
$ grep -w "^export TMOUT" /etc/profile.d/autologout.sh
If the file /etc/profile.d/autologout.sh does not exist or has no return value, this is a finding.
| | Rationale: | A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not log out because of the temporary nature of the absence.
Rather than relying on the users to manually lock their KubeOS session prior to vacating the vicinity, KubeOS needs to be able to identify when a user's session has idled and take action to initiate the session lock.
The session lock is implemented at the point where session activity can be determined and/or controlled. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261363r996536_rule | | Identifiers and References | Identifiers:
C-261363 References:
13.13 | |
|
Rule
KubeOS must lock an account after three consecutive invalid access attempts.
[ref] |
Verify KubeOS locks a user account after three consecutive failed access attempts until the locked account is released by an administrator with the following command:
$ grep -w "^auth required pam_faillock.so onerr=fail silent audit deny=3" /etc/pam.d/common-auth
$ grep -w "^account required pam_faillock.so" /etc/pam.d/common-account
If deny set to a value other than 1, 2, or 3, if onerr=fail is missing, if the line is commented out, or the line is missing, this is a finding.
| | Rationale: | By limiting the number of failed access attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute-forcing, is reduced. Limits are imposed by locking the account.
The pam_tally2.so module maintains a count of attempted accesses. This includes username entry into a logon field as well as password entry. With counting access attempts, it is possible to lock an account without presenting a password into the password field. This should be taken into consideration as it poses as an avenue for denial of service (DoS). | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261364r996863_rule | | Identifiers and References | Identifiers:
C-261364 References:
13.14 | |
|
Rule
KubeOS must enforce a delay of at least five seconds between logon prompts following a failed logon attempt via pluggable authentication modules (PAM).
[ref] |
Verify KubeOS enforces a delay of at least five seconds between logon prompts following a failed logon attempt with the following command:
$ grep auth required pam_faildelay.so delay=5000000 /etc/pam.d/common-auth
If the value of delay is not set to 5000000 or greater, delay is missing, the line is commented out, or the pam_faildelay line is missing completely, this is a finding.
| | Rationale: | Limiting the number of logon attempts over a certain time interval reduces the chances that an unauthorized user may gain access to an account. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261365r996541_rule | | Identifiers and References | Identifiers:
C-261365 References:
13.15 | |
|
Rule
KubeOS must limit the number of concurrent sessions to 10 for all accounts and/or account types.
[ref] |
Verify KubeOS limits the number of concurrent sessions to 10 for all accounts and/or account types with the following command:
$ grep -w "* hard maxlogins 10" /etc/security/limits.conf
* hard maxlogins 10
If the maxlogins does not have a value of 10 or less, is commented out, or is missing, this is a finding.
| | Rationale: | KubeOS management includes the ability to control the number of users and user sessions that use a KubeOS. Limiting the number of allowed users and sessions per user is helpful in reducing the risks related to denial-of-service (DoS) attacks.
This requirement addresses concurrent sessions for information system accounts and does not address concurrent sessions by single users via multiple system accounts. The maximum number of concurrent sessions should be defined based on mission needs and the operational environment for each system. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261367r996839_rule | | Identifiers and References | Identifiers:
C-261367 References:
16.63 | |
|
Rule
KubeOS must have policycoreutils package installed.
[ref] |
Verify KubeOS has the policycoreutils package installed with the following command:
$ sestatus -v
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
...
If the policycoreutils package is not installed, this is a finding.
| | Rationale: | Without verification of the security functions, security functions may not operate correctly and the failure may go unnoticed. Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters.
Policycoreutils contains the policy core utilities that are required for basic operation of an SELinux-enabled system. These utilities include load_policy to load SELinux policies, setfile to label filesystems, newrole to switch roles, and run_init to run /etc/init.d scripts in the proper context. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261368r996548_rule | | Identifiers and References | Identifiers:
C-261368 References:
16.64 | |
|
Rule
KubeOS must use a Linux Security Module configured to enforce limits on system services.
[ref] |
Verify SELinux is active and in Enforcing mode with the following command:
$ getenforce
Enforcing
If SELinux is not in Enforcing mode, this is a finding.
| | Rationale: | Without verification of the security functions, security functions may not operate correctly and the failure may go unnoticed. Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters.
This requirement applies to operating systems performing security function verification/testing and/or systems and environments that require this functionality. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261369r996549_rule | | Identifiers and References | Identifiers:
C-261369 References:
14.3 | |
|
Rule
KubeOS must enable the SELinux targeted policy.
[ref] |
Verify SELinux is active and enforcing the targeted policy with the following command:
$ grep -i "SELINUXTYPE=targeted" /etc/selinux/config
If the Loaded policy name is not set to targeted, this is a finding.
| | Rationale: | Without verification of the security functions, security functions may not operate correctly and the failure may go unnoticed. Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters.
This requirement applies to operating systems performing security function verification/testing and/or systems and environments that require this functionality. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261370r996551_rule | | Identifiers and References | Identifiers:
C-261370 References:
14.1 | |
|
Rule
KubeOS must prevent nonprivileged users from executing privileged functions, including disabling, circumventing, or altering implemented security safeguards/countermeasures.
[ref] |
Verify KubeOS prevents nonprivileged users from executing privileged functions, including disabling, circumventing, or altering implemented security safeguards/countermeasures.
Obtain a list of authorized users (other than system administrator and guest accounts) for the system.
Check the list against the system with the following command:
$ semanage login -l | more
Login Name SELinux User MLS/MCS Range Service
__default__ user_u s0-s0:c0.c1023 *
root unconfined_u s0-s0:c0.c1023 *
system_u system_u s0-s0:c0.c1023 *
joe staff_u s0-s0:c0.c1023 *
All administrators must be mapped to the sysadm_u, staff_u, or an appropriately tailored confined role as defined by the organization.
All authorized nonadministrative users must be mapped to the user_u role.
If any interactive users are not mapped in this way, this is a finding.
It can not be scanned automatically, please check it manually.
Manually verify that all nonprivileged users are properly mapped to appropriate SELinux roles and cannot execute privileged functions.
| | Rationale: | Preventing nonprivileged users from executing privileged functions mitigates the risk that unauthorized individuals or processes may gain unnecessary access to information or privileges.
Privileged functions include, for example, establishing accounts, performing system integrity checks, or administering cryptographic key management activities. Nonprivileged users are individuals who do not possess appropriate authorizations. Circumventing intrusion detection and prevention mechanisms or malicious code protection mechanisms are examples of privileged functions that require protection from nonprivileged users. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261371r996554_rule | | Identifiers and References | Identifiers:
C-261371 References:
14.2 | |
|
Rule
KubeOS must use the invoking user
[ref] |
Verify that the sudoers security policy is configured to use the invoking user's password for privilege escalation with the following command:
$ grep -rE '^Defaults !(targetpw|rootpw|runaspw)$' /etc/sudoers /etc/sudoers.d/
Defaults !targetpw
Defaults !rootpw
Defaults !runaspw
If Defaults types are not defined for !targetpw, !rootpw, and !runaspw, there are conflicting results between files, this is a finding.
| | Rationale: | The sudoers security policy requires that users authenticate themselves before they can use sudo. When sudoers requires authentication, it validates the invoking user's credentials. If the rootpw, targetpw, or runaspw flags are defined and not disabled, by default the operating system will prompt the invoking user for the "root" user password.
For more information on each of the listed configurations, reference the sudoers(5) manual page. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261372r996556_rule | | Identifiers and References | Identifiers:
C-261372 References:
13.16 | |
|
Rule
KubeOS must reauthenticate users when changing authenticators, roles, or escalating privileges.
[ref] |
Verify that KubeOS requires reauthentication when changing authenticators, roles, or escalating privileges with the following command:
$ grep -i "^nopasswd" /etc/sudoers
$ grep -i "^!authenticate" /etc/sudoers
If any uncommented lines containing !authenticate, or NOPASSWD are returned and active accounts on the system have valid passwords, this is a finding.
| | Rationale: | Without reauthentication, users may access resources or perform tasks for which they do not have authorization.
When KubeOS provides the capability to change user authenticators, change security roles, or escalate a functional capability, it is critical the user reauthenticate. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261373r1050789_rule | | Identifiers and References | Identifiers:
C-261373 References:
13.17 | |
|
Rule
KubeOS must require reauthentication when using the "sudo" command.
[ref] |
Verify KubeOS requires reauthentication when using the sudo command to elevate privileges with the following command:
$ grep -ir 'timestamp_timeout' /etc/sudoers /etc/sudoers.d
/etc/sudoers:Defaults timestamp_timeout=0
If timestamp_timeout is set to a negative number, is commented out, conflicting results are returned, or no results are returned, this is a finding.
| | Rationale: | Without reauthentication, users may access resources or perform tasks for which they do not have authorization.
When operating systems provide the capability to escalate a functional capability, it is critical the organization requires the user to reauthenticate when using the "sudo" command.
If the value is set to an integer less than 0, the user's time stamp will not expire and the user will not have to reauthenticate for privileged actions until the user's session is terminated. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261374r1050789_rule | | Identifiers and References | Identifiers:
C-261374 References:
13.18 | |
|
Rule
KubeOS must restrict privilege elevation to authorized personnel.
[ref] |
Verify the sudoers file restricts sudo access to authorized personnel with the following command:
$ grep -iw 'ALL' /etc/sudoers /etc/sudoers.d/*
root ALL=(ALL) ALL
If ALL ALL=(ALL) ALL or ALL ALL=(ALL:ALL) ALL entries are returned, this is a finding.
| | Rationale: | The sudo command allows a user to execute programs with elevated (administrator) privileges. It prompts the user for their password and confirms the request to execute a command by checking a file, called sudoers. If the "sudoers" file is not configured correctly, any user defined on the system can initiate privileged actions on the target system. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261375r996562_rule | | Identifiers and References | Identifiers:
C-261375 References:
13.19 | |
|
Rule
KubeOS must specify the default "include" directory for the /etc/sudoers file.
[ref] |
Verify KubeOS specifies only the default include directory for the /etc/sudoers file, and does not have nested include files or directories within the /etc/sudoers.d directory with the following command:
Note: If the include and includedir directives are not present in the /etc/sudoers file, this requirement is not applicable.
$ grep -w "^#includedir /etc/sudoers.d" /etc/sudoers
#includedir /etc/sudoers.d
If the results are not /etc/sudoers.d or additional files or directories are specified, this is a finding.
| | Rationale: | The "sudo" command allows authorized users to run programs (including shells) as other users, system users, and root. The "/etc/sudoers" file is used to configure authorized "sudo" users as well as the programs they are allowed to run. Some configuration options in the "/etc/sudoers" file allow configured users to run programs without reauthenticating. Use of these configuration options makes it easier for one compromised account to be used to compromise other accounts.
It is possible to include other sudoers files from within the sudoers file currently being parsed using the @include and @includedir directives. For compatibility with sudo versions prior to 1.9.1, #include and #includedir are also accepted. When sudo reaches this line it will suspend processing of the current file (/etc/sudoers) and switch to the specified file/directory. Once the end of the included file(s) is reached, the rest of /etc/sudoers will be processed. Files that are included may themselves include other files. A hard limit of 128 nested include files is enforced to prevent include file loops. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261376r996564_rule | | Identifiers and References | Identifiers:
C-261376 References:
13.20 | |
|
Rule
KubeOS must enforce passwords that contain at least one uppercase character.
[ref] |
Verify KubeOS enforces password complexity by requiring at least one uppercase character with the following command:
$ grep -w "^password requisite pam_pwquality.so ucredit=-1" /etc/pam.d/common-password
If the value for ucredit is not -1, if ucredit is missing from the line, the second column value different from requisite, the line is commented out, or the line is missing, this is a finding.
| | Rationale: | Use of a complex password helps increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.
Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261377r996566_rule | | Identifiers and References | Identifiers:
C-261377 References:
13.21 | |
|
Rule
KubeOS must enforce passwords that contain at least one lowercase character.
[ref] |
Verify KubeOS enforces password complexity by requiring at least one lower character with the following command:
$ grep -w "^password requisite pam_pwquality.so lcredit=-1" /etc/pam.d/common-password
If the value for lcredit is not -1, if lcredit is missing from the line, the second column value different from requisite, the line is commented out, or the line is missing, this is a finding.
| | Rationale: | Use of a complex password helps increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.
Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261378r996568_rule | | Identifiers and References | Identifiers:
C-261378 References:
13.22 | |
|
Rule
KubeOS must enforce passwords that contain at least one numeric character.
[ref] |
Verify KubeOS enforces password complexity by requiring at least one numeric character with the following command:
$ grep -w "^password requisite pam_pwquality.so dcredit=-1" /etc/pam.d/common-password
If the value for dcredit is not -1, if dcredit is missing from the line, the second column value different from requisite, the line is commented out, or the line is missing, this is a finding.
| | Rationale: | Use of a complex password helps increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.
Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261379r996570_rule | | Identifiers and References | Identifiers:
C-261379 References:
13.23 | |
|
Rule
KubeOS must enforce passwords that contain at least one special character.
[ref] |
Verify KubeOS enforces password complexity by requiring at least one special character with the following command:
$ grep -w "^password requisite pam_pwquality.so ocredit=-1" /etc/pam.d/common-password
If the value for ocredit is not -1, if ucredit is missing from the line, the second column value different from requisite, the line is commented out, or the line is missing, this is a finding.
| | Rationale: | Use of a complex password helps increase the time and resources required to compromise the password. Password complexity or strength is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.
Password complexity is one factor in determining how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.
Special characters are not alphanumeric. Examples include: ~ ! @ # $ % ^ *. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261380r996572_rule | | Identifiers and References | Identifiers:
C-261380 References:
13.24 | |
|
Rule
KubeOS must prevent the use of dictionary words for passwords.
[ref] |
Verify KubeOS prevents the use of dictionary words for passwords with the following command:
$ grep -w "^password requisite pam_pwquality.so" /etc/pam.d/common-password
If the second column value is different from requisite, the line is commented out, or the line is missing, this is a finding.
| | Rationale: | If KubeOS allows the user to select passwords based on dictionary words, this increases the chances of password compromise by increasing the opportunity for successful guesses and brute-force attacks. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261381r996574_rule | | Identifiers and References | Identifiers:
C-261381 References:
13.25 | |
|
Rule
KubeOS must employ passwords with a minimum of 15 characters.
[ref] |
Verify KubeOS enforces a minimum 15-character password length with the following command:
$ grep -w "^password requisite pam_pwquality.so minlen=15" /etc/pam.d/common-password
If the value for minlen is not 15 or greater, the minlen option is missing from the line, the second column has a value different from requisite, the line is commented out, or the line is missing, this is a finding.
| | Rationale: | The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised.
Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps determine strength and how long it takes to crack a password. Use of more characters in a password helps exponentially increase the time and/or resources required to compromise the password. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261382r996577_rule | | Identifiers and References | Identifiers:
C-261382 References:
13.26 | |
|
Rule
KubeOS must require the change of at least eight of the total number of characters when passwords are changed.
[ref] |
Verify KubeOS requires at least eight characters be changed between the old and new passwords during a password change with the following command:
$ grep -w "^password requisite pam_pwquality.so difok=8" /etc/pam.d/common-password
If the value for difok is not 8 or greater, if difok is missing from the line, the second column value different from requisite, the line is commented out, or the line is missing, this is a finding.
| | Rationale: | If KubeOS allows the user to consecutively reuse extensive portions of passwords, this increases the chances of password compromise by increasing the window of opportunity for attempts at guessing and brute-force attacks. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261383r996580_rule | | Identifiers and References | Identifiers:
C-261383 References:
13.27 | |
|
Rule
KubeOS must not allow passwords to be reused for a minimum of five generations.
[ref] |
Verify KubeOS prohibits the reuse of a password for a minimum of five generations with the following command:
$ grep -w "^password requisite pam_pwhistory.so remember=5 use_authtok" /etc/pam.d/common-password
If the value for remember is not 5 or greater, if the remember option is missing from the line, if the use_authtok option is missing, if the second column has a value different from requisite, if the line is commented out, or the line is missing, this is a finding.
| | Rationale: | Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. If the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the end result is a password that is not changed as per policy requirements. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261384r996583_rule | | Identifiers and References | Identifiers:
C-261384 References:
13.28 | |
|
Rule
KubeOS must configure the Linux Pluggable Authentication Modules (PAM) to only store encrypted representations of passwords.
[ref] |
Verify KubeOS configures the Linux PAM to only store encrypted representations of passwords with the following command:
$ grep -w "^password required pam_unix.so sha512" /etc/pam.d/common-password
If the value sha512 is not present in the line, the second column value is different from requisite, the line is commented out, or the line is missing, 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_EC-261385r996586_rule | | Identifiers and References | Identifiers:
C-261385 References:
13.29 | |
|
Rule
KubeOS must not be configured to allow blank or null passwords.
[ref] |
Verify KubeOS is not configured to allow blank or null passwords with the following command:
$ grep pam_unix.so /etc/pam.d/* | grep nullok
If this produces any output, 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_EC-261386r996587_rule | | Identifiers and References | Identifiers:
C-261386 References:
13.43 | |
|
Rule
KubeOS must not have accounts configured with blank or null passwords.
[ref] |
Check the /etc/shadow file for blank passwords with the following command:
$ awk -F: '!$2 {print $1}' /etc/shadow
If the command returns any results, this is a finding.
| | Rationale: | If an account has an empty password, anyone could log on and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261387r996588_rule | | Identifiers and References | Identifiers:
C-261387 References:
13.44 | |
|
Rule
KubeOS must employ user passwords with a minimum lifetime of 24 hours (one day).
[ref] |
Verify KubeOS enforces a minimum time period between password changes for each user account of one day or greater with the following command:
$ awk -F: '$4 < 1 {print $1 ":" $4}' /etc/shadow
If any results are returned that are not associated with a system account, this is a finding.
| | Rationale: | Enforcing a minimum password lifetime helps prevent repeated password changes to defeat the password reuse or history enforcement requirement. If users are allowed to immediately and continually change their password, the password could be repeatedly changed in a short period of time to defeat the organization's policy regarding password reuse. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261388r996591_rule | | Identifiers and References | Identifiers:
C-261388 References:
13.30 | |
|
Rule
KubeOS must employ user passwords with a maximum lifetime of 60 days.
[ref] |
Verify that KubeOS enforces a maximum user password age of 60 days or less with the following command:
$ awk -F: '$5 > 60 || $5 == "" {print $1 ":" $5}' /etc/shadow
If any results are returned that are not associated with a system account, this is a finding.
| | Rationale: | Any password, no matter how complex, can eventually be cracked. Therefore, passwords need to be changed periodically. If KubeOS does not limit the lifetime of passwords and force users to change their passwords, there is the risk that KubeOS passwords could be compromised. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261389r1038967_rule | | Identifiers and References | Identifiers:
C-261389 References:
13.31 | |
|
Rule
KubeOS must employ a password history file.
[ref] |
Verify the password history file exists on KubeOS with the following command:
$ find /etc/security -name opasswd
If the opasswd file does not exist, this is a finding.
| | Rationale: | Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. If the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the end result is a password that is not changed as per policy requirements. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261390r996595_rule | | Identifiers and References | Identifiers:
C-261390 References:
13.32 | |
|
Rule
KubeOS must employ FIPS 140-2/140-3-approved cryptographic hashing algorithms for system authentication.
[ref] |
Use the following command to verify that the KubeOS user password should use the SHA512 algorithm.
$ grep -w "^ENCRYPT_METHOD SHA512" /etc/login.defs
ENCRYPT_METHOD SHA512
If ENCRYPT_METHOD is not set to SHA512, or is commented out, this is a finding.
| | Rationale: | The system must use a strong hashing algorithm to store the password. The system must use a sufficient number of hashing rounds to ensure the required level of entropy.
Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261391r996598_rule | | Identifiers and References | Identifiers:
C-261391 References:
13.45 | |
|
Rule
KubeOS shadow password suite must be configured to use a sufficient number of hashing rounds.
[ref] |
Verify KubeOS shadow password suite is configured to encrypt passwords using sufficient number of hashing rounds.
$ grep -i "^SHA_CRYPT_" /etc/login.defs
SHA_CRYPT_MIN_ROUNDS 5000
SHA_CRYPT_MAX_ROUNDS 5000
If only one of SHA_CRYPT_MIN_ROUNDS or SHA_CRYPT_MAX_ROUNDS is set, and this value is below 5000, this is a finding.
If both SHA_CRYPT_MIN_ROUNDS and SHA_CRYPT_MAX_ROUNDS are set, and the highest value for either is below 5000, this is a finding.
| | Rationale: | The system must use a strong hashing algorithm to store the password. The system must use a sufficient number of hashing rounds to ensure the required level of entropy.
Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261392r996600_rule | | Identifiers and References | Identifiers:
C-261392 References:
13.46 | |
|
Rule
KubeOS must employ FIPS 140-2/140-3 approved cryptographic hashing algorithm for system authentication (login.defs).
[ref] |
Verify that the shadow password suite configuration is set to encrypt password with a FIPS 140-2/140-3 approved cryptographic hashing algorithm with the following command:
$ grep "^ENCRYPT_METHOD " /etc/login.defs
ENCRYPT_METHOD SHA512
If ENCRYPT_METHOD is not set to SHA512, if any values other that SHA512 are configured, or if no output is produced, this is a finding.
| | Rationale: | Unapproved mechanisms that are used for authentication to the cryptographic module are not verified and therefore cannot be relied on to provide confidentiality or integrity, and data may be compromised.
KubeOS using encryption are required to use FIPS 140-2/140-3 compliant mechanisms for authenticating to cryptographic modules.
FIPS 140-2/140-3 is the current standard for validating that mechanisms used to access cryptographic modules use authentication that meets requirements. This allows for Security Levels 1, 2, 3, or 4 for use on a general-purpose computing system. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261393r996602_rule | | Identifiers and References | Identifiers:
C-261393 References:
13.33 | |
|
Rule
KubeOS must be configured to create or update passwords with a minimum lifetime of 24 hours (one day).
[ref] |
Verify KubeOS creates or updates passwords with minimum password age of one day or greater with the following command:
$ grep -w "^PASS_MIN_DAYS " /etc/login.defs
If PASS_MIN_DAYS does not have a value of 1 or greater, the line is commented out, or no line is returned, this is a finding.
| | Rationale: | Enforcing a minimum password lifetime helps prevent repeated password changes to defeat the password reuse or history enforcement requirement. If users are allowed to immediately and continually change their password, the password could be repeatedly changed in a short period of time to defeat the organization's policy regarding password reuse. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261394r996604_rule | | Identifiers and References | Identifiers:
C-261394 References:
13.34 | |
|
Rule
KubeOS must be configured to create or update passwords with a maximum lifetime of 60 days.
[ref] |
Verify that KubeOS is configured to create or update passwords with a maximum password age of 60 days or less with the following command:
$ grep -w "^PASS_MAX_DAYS 7 " /etc/login.defs
If PASS_MAX_DAYS is not set to a value of 7 , this is a finding.
| | Rationale: | Any password, no matter how complex, can eventually be cracked. Therefore, passwords need to be changed periodically. If KubeOS does not limit the lifetime of passwords and force users to change their passwords, there is the risk that KubeOS passwords could be compromised. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261395r1038967_rule | | Identifiers and References | Identifiers:
C-261395 References:
13.35 | |
|
Rule
KubeOS must have the packages required for multifactor authentication to be installed.
[ref] |
Configure KubeOS to implement multi-factor authentication by installing the required software packages.
Use the following commands to verify the software packages necessary for supporting multi-factor authentication are installed:
find /usr/lib64 -name libnss3.so*
find /usr/lib64 -name libnssutil3.so*
find /usr/lib64 -name libccid.so*
find /usr/lib64 -name libpcsclite.so*
find /usr/lib64 -name pam_pkcs11
find /usr/bin -name pcsc_scan
find /usr/lib64 -name libopensc.so*
| | Rationale: | Using an authentication device, such as a smart card or authentication token separate from the information system, ensures that even if the information system is compromised, that compromise will not affect credentials stored on the authentication device.
Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the Personal Identity Verification (PIV) card and the Common Access Card (CAC).
A privileged account is defined as an information system account with authorizations of a privileged user.
Remote access is access to nonpublic information systems by an authorized user (or an information system) communicating through an external, nonorganization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless.
This requirement only applies to components where this is specific to the function of the device or has the concept of an organizational user (e.g., VPN, proxy capability). This does not apply to authentication for the purpose of configuring the device itself (management). | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261396r996610_rule | | Identifiers and References | Identifiers:
C-261396 References:
1.2 | |
|
Rule
KubeOS must implement multifactor authentication for access to privileged accounts via pluggable authentication modules (PAM).
[ref] |
Verify KubeOS implements multifactor authentication for remote access to privileged accounts via PAM with the following command:
$ grep pam_pkcs11.so /etc/pam.d/common-auth
auth sufficient pam_pkcs11.so
If pam_pkcs11.so is not set in /etc/pam.d/common-auth, or the line is commented out, this is a finding.
| | Rationale: | Using an authentication device, such as a smart card or authentication token that is separate from the information system, ensures that even if the information system is compromised, that compromise will not affect credentials stored on the authentication device.
Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the Personal Identity Verification (PIV) card and the Common Access Card (CAC).
A privileged account is defined as an information system account with authorizations of a privileged user.
Remote access is access to nonpublic information systems by an authorized user (or an information system) communicating through an external, nonorganization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless.
This requirement only applies to components where this is specific to the function of the device or has the concept of an organizational user (e.g., VPN, proxy capability). This does not apply to authentication for the purpose of configuring the device itself (management). | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261397r996612_rule | | Identifiers and References | Identifiers:
C-261397 References:
13.36 | |
|
Rule
KubeOS must implement certificate status checking for multifactor authentication.
[ref] |
Verify KubeOS implements certificate status checking for multifactor authentication with the following command:
$ grep -w cert_policy /etc/pam_pkcs11/pam_pkcs11.conf | grep ocsp_on
If cert_policy is not set to include ocsp, this is a finding.
| | Rationale: | Using an authentication device, such as a smart card or authentication token separate from the information system, ensures credentials stored on the authentication device will not be affected if the information system is compromised.
Multifactor solutions that require devices separate from information systems to gain access include hardware tokens providing time-based or challenge-response authenticators, and smart cards such as the Personal Identity Verification (PIV) card and the Common Access Card (CAC).
A privileged account is defined as an information system account with authorizations of a privileged user.
Remote access is access to nonpublic information systems by an authorized user (or an information system) communicating through an external, nonorganization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless.
This requirement only applies to components with device-specific functions, or for organizational users (e.g., VPN, proxy capability). This does not apply to authentication for the purpose of configuring the device itself (management). | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261398r996615_rule | | Identifiers and References | Identifiers:
C-261398 References:
13.37 | |
|
Rule
If Network Security Services (NSS) is being used by KubeOS it must prohibit the use of cached authentications after one day.
[ref] |
If NSS is used by KubeOS, verify it prohibits the use of cached authentications after one day with the following command:
Note: If NSS is not used on the operating system, this is not applicable.
$ grep -i "^memcache_timeout" /etc/sssd/sssd.conf
memcache_timeout = 86400
If memcache_timeout has a value greater than 86400, the line is commented out, or the line is missing, this is a finding.
| | Rationale: | If cached authentication information is out of date, the validity of the authentication information may be questionable. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261399r996617_rule | | Identifiers and References | Identifiers:
C-261399 References:
13.38 | |
|
Rule
KubeOS must configure the Linux Pluggable Authentication Modules (PAM) to prohibit the use of cached offline authentications after one day.
[ref] |
Verify that KubeOS PAM prohibits the use of cached off line authentications after one day with the following command:
Note: If SSSD is not being used on the operating system, this is not applicable.
$ grep "offline_credentials_expiration" /etc/sssd/sssd.conf
offline_credentials_expiration = 1
If offline_credentials_expiration is not set to a value of 1, the line is commented out, or the line is missing, this is a finding.
| | Rationale: | If cached authentication information is out of date, the validity of the authentication information may be questionable. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261400r996619_rule | | Identifiers and References | Identifiers:
C-261400 References:
13.39 | |
|
Rule
KubeOS, for PKI-based authentication, must validate certificates by constructing a certification path (which includes status information) to an accepted trust anchor.
[ref] |
Verify KubeOS for PKI-based authentication had valid certificates by constructing a certification path (which includes status information) to an accepted trust anchor with the following command:
$ grep cert_policy /etc/pam_pkcs11/pam_pkcs11.conf
cert_policy = ca,oscp_on,signature,crl_auto;
If cert_policy is not set to include ca on all returned lines, this is a finding.
| | Rationale: | Without path validation, an informed trust decision by the relying party cannot be made when presented with any certificate not already explicitly trusted.
A trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates, and DNSSEC.
When there is a chain of trust, usually the top entity to be trusted becomes the trust anchor; it can be, for example, a Certification Authority (CA). A certification path starts with the subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted CA.
This requirement verifies that a certification path to an accepted trust anchor is used for certificate validation and that the path includes status information. Path validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted. Status information for certification paths includes certificate revocation lists or online certificate status protocol responses. Validation of the certificate status information is out of scope for this requirement. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261401r996622_rule | | Identifiers and References | Identifiers:
C-261401 References:
13.40 | |
|
Rule
KubeOS must be configured to not overwrite Pluggable Authentication Modules (PAM) configuration on package changes.
[ref] |
Verify KubeOS is configured to not overwrite PAM configuration on package changes with the following command:
$ find /etc/pam.d/ -type l -iname "common-*"
If any results are returned, this is a finding.
| | Rationale: | The "pam-config" command line utility automatically generates a system PAM configuration as packages are installed, updated, or removed from the system. "pam-config" removes configurations for PAM modules and parameters that it does not know about. It may render ineffective PAM configuration by the system administrator and thus impact system security. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261402r996624_rule | | Identifiers and References | Identifiers:
C-261402 References:
13.41 | |
|
Rule
KubeOS must use a file integrity tool to verify correct operation of all security functions.
[ref] |
Verify that Advanced Intrusion Detection Environment (AIDE) is installed and verifies the correct operation of all security functions with the following command:
$ /usr/sbin/aide -h| grep "Usage: aide \[options\] command"
If the output shows File not found, then this is a finding.
| | Rationale: | Without verification of the security functions, security functions may not operate correctly, and the failure may go unnoticed. Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters.
This requirement applies to KubeOS performing security function verification/testing and/or systems and environments that require this functionality. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261403r996627_rule | | Identifiers and References | Identifiers:
C-261403 References:
15.1 | |
|
Rule
KubeOS file integrity tool must be configured to verify Access Control Lists (ACLs).
[ref] |
Verify that KubeOS file integrity tool is configured to verify extended attributes.
$ grep "^FIPSR = p+i+n+u+g+s+m+c+acl+selinux+xattrs+sha256" /etc/aide.conf
$ grep "^DIR = p+i+n+u+g+acl+selinux+xattrs" /etc/aide.conf
$ grep "^PERMS = p+i+u+g+acl+selinux" /etc/aide.conf
$ grep "^DATAONLY = p+n+u+g+s+acl+selinux+xattrs+sha256" /etc/aide.conf
If the acl rule is not being used on all selection lines in the /etc/aide.conf file, or extended attributes are not being checked by another file integrity tool, this is a finding.
| | Rationale: | ACLs can provide permissions beyond those permitted through the file mode and must be verified by file integrity tools. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261404r996629_rule | | Identifiers and References | Identifiers:
C-261404 References:
15.2 | |
|
Rule
KubeOS file integrity tool must be configured to verify extended attributes.
[ref] |
Verify that KubeOS file integrity tool is configured to verify extended attributes.
$ grep "^FIPSR = p+i+n+u+g+s+m+c+acl+selinux+xattrs+sha256" /etc/aide.conf
$ grep "^DIR = p+i+n+u+g+acl+selinux+xattrs" /etc/aide.conf
$ grep "^DATAONLY = p+n+u+g+s+acl+selinux+xattrs+sha256" /etc/aide.conf
If the xattrs rule is not being used on all selection lines in the /etc/aide.conf file, or extended attributes are not being checked by another file integrity tool, this is a finding.
| | Rationale: | Extended attributes in file systems are used to contain arbitrary data and file metadata with security implications. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261405r996631_rule | | Identifiers and References | Identifiers:
C-261405 References:
15.3 | |
|
Rule
KubeOS file integrity tool must be configured to protect the integrity of the audit tools.
[ref] |
Verify that KubeOS file integrity tool is configured to protect the integrity of the audit tools.
Check that AIDE is properly configured to protect the integrity of the audit tools by running the following command:
$ grep /usr/sbin/au /etc/aide.conf
/usr/sbin/auditctl p+i+n+u+g+s+b+acl+selinux+xattrs+sha512
/usr/sbin/auditd p+i+n+u+g+s+b+acl+selinux+xattrs+sha512
/usr/sbin/ausearch p+i+n+u+g+s+b+acl+selinux+xattrs+sha512
/usr/sbin/aureport p+i+n+u+g+s+b+acl+selinux+xattrs+sha512
/usr/sbin/autrace p+i+n+u+g+s+b+acl+selinux+xattrs+sha512
/usr/sbin/audispd p+i+n+u+g+s+b+acl+selinux+xattrs+sha512
/usr/sbin/augenrules p+i+n+u+g+s+b+acl+selinux+xattrs+sha512
If any of the seven lines do not appear as shown, are commented out, or are missing, this is a finding.
| | Rationale: | Protecting the integrity of the tools used for auditing purposes is a critical step toward ensuring the integrity of audit information. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.
Audit tools include but are not limited to vendor-provided and open-source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.
It is not uncommon for attackers to replace the audit tools or inject code into the existing tools to provide the capability to hide or erase system activity from the audit logs.
To address this risk, audit tools must be cryptographically signed to provide the capability to identify when the audit tools have been modified, manipulated, or replaced. An example is a checksum hash of the file or files. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261406r996634_rule | | Identifiers and References | Identifiers:
C-261406 References:
15.4 | |
|
Rule
Advanced Intrusion Detection Environment (AIDE) must verify the baseline KubeOS configuration at least weekly.
[ref] |
Verify KubeOS checks the baseline configuration using AIDE for unauthorized changes at least once weekly with the following command:
Note: A file integrity tool other than AIDE may be used, but the tool must be executed at least once per week.
$ grep -R aide /etc/crontab /etc/cron.*
/etc/crontab: 30 04 * * * root /usr/sbin/aide
If the file integrity application does not exist, or a crontab file does not exist in /etc/crontab, the /etc/cron.daily subdirectory, or /etc/cron.weekly subdirectory, this is a finding.
| | Rationale: | Unauthorized changes to the baseline configuration could make the system vulnerable to various attacks or allow unauthorized access to KubeOS. Changes to KubeOS configurations can have unintended side effects, some of which may be relevant to security.
Detecting such changes and providing an automated response can help avoid unintended, negative consequences that could ultimately affect the security state of KubeOS. KubeOS's information system security manager (ISSM)/information system security officer (ISSO) and system administrator (SA) must be notified via email and/or monitoring system trap when there is an unauthorized modification of a configuration item. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261407r996637_rule | | Identifiers and References | Identifiers:
C-261407 References:
15.5 | |
|
Rule
KubeOS must notify the system administrator (SA) when Advanced Intrusion Detection Environment (AIDE) discovers anomalies in the operation of any security functions.
[ref] |
Verify KubeOS notifies the SA when AIDE discovers anomalies in the operation of any security functions.
Note: A file integrity tool other than AIDE may be used, but the tool must be configured to notify the system administrator and/or ISSO if there is an anomaly.
Verify the aide cron job sends an email when executed with the following command:
$ grep -i "aide" /etc/cron.*/aide
0 0 * * * /usr/sbin/aide --check | /bin/mail -s $HOSTNAME - Daily AIDE integrity check run root@example_server_name.mil
If the aide file does not exist under the /etc/cron directory structure or the cron job is not configured to execute a binary to send an email (such as /bin/mail), this is a finding.
| | Rationale: | If anomalies are not acted on, security functions may fail to secure the system.
Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters.
Notifications provided by information systems include messages to local computer consoles and/or hardware indications, such as lights.
This capability must take into account operational requirements for availability for selecting an appropriate response. The organization may choose to shut down or restart the information system upon security function anomaly detection. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261408r996640_rule | | Identifiers and References | Identifiers:
C-261408 References:
15.6 | |
|
Rule
KubeOS must offload rsyslog messages for networked systems in real time and offload standalone systems at least weekly.
[ref] |
Verify that KubeOS must offload syslog-ng messages for networked systems in real time and offload standalone systems at least weekly.
For standalone hosts, verify with the system administrator that the log files are offloaded at least weekly.
For networked systems, check that syslog-ng is sending log messages to a remote server with the following command:
$ grep -i "^*.* @<IP>:514" /etc/rsyslog.conf
$ grep -i "^*.* @@<IP>:514" /etc/rsyslog.conf
If any active message labels in the file do not have a line to send log messages to a remote server, this is a finding.
It can not be scanned automatically, please check it manually.
Manually verify that rsyslog messages are properly offloaded according to the specified frequency requirements.
| | Rationale: | Information stored in one location is vulnerable to accidental or incidental deletion or alteration.
Offloading is a common process in information systems with limited audit storage capacity. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261409r996643_rule | | Identifiers and References | Identifiers:
C-261409 References:
16.1 | |
|
Rule
KubeOS must have the auditing package installed.
[ref] |
Verify KubeOS auditing package is installed with the following command:
$ auditctl -v
auditctl version 3.1.2
If the package audit is not installed on the system, this is a finding.
| | Rationale: | Without establishing what type of events occurred, the source of events, where events occurred, and the outcome of events, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack.
Audit record content that may be necessary to satisfy this requirement includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked.
Associating event types with detected events in KubeOS audit logs provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured KubeOS. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261410r996645_rule | | Identifiers and References | Identifiers:
C-261410 References:
16.2 | |
|
Rule
KubeOS audit records must contain information to establish what type of events occurred, the source of events, where events occurred, and the outcome of events.
[ref] |
Verify KubeOS produces audit records with the following commands:
$ systemctl is-active auditd.service
active
$ systemctl is-enabled auditd.service
enabled
If the service is not active or not enabled, this is a finding.
| | Rationale: | Without establishing what type of events occurred, the source of events, where events occurred, and the outcome of events, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack.
Audit record content that may be necessary to satisfy this requirement includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked.
Associating event types with detected events in KubeOS audit logs provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured KubeOS. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261411r996646_rule | | Identifiers and References | Identifiers:
C-261411 References:
16.3 | |
|
Rule
The audit-audispd-plugins package must be installed on KubeOS.
[ref] |
Verify that the audit-audispd-plugins package is installed on KubeOS with the following command:
$ grep -iw "^active = yes " /etc/audit/plugins.d/au-remote.conf
active = yes
If active is not set to yes, is commented out, or is missing, this is a finding.
| | Rationale: | Information stored in one location is vulnerable to accidental or incidental deletion or alteration.
Offloading is a common process in information systems with limited audit storage capacity.
The auditd service does not include the ability to send audit records to a centralized server for management directly. However, it can use a plug-in for audit event multiplexor to pass audit records to a remote server. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261412r996649_rule | | Identifiers and References | Identifiers:
C-261412 References:
16.4 | |
|
Rule
KubeOS must allocate audit record storage capacity to store at least one week of audit records when audit records are not immediately sent to a central audit record storage facility.
[ref] |
Verify KubeOS allocates audit record storage capacity to store at least one week of audit records when audit records are not immediately sent to a central audit record storage facility.
Check the size of the partition that audit records are written to (with the example being /var/log/audit/) with the following command:
$ df -h /var/log/audit/
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 24G 10.4G 13.6G 43% /var
If the audit record partition is not allocated sufficient storage capacity, this is a finding.
| | Rationale: | To ensure KubeOS has a sufficient storage capacity in which to write the audit logs, KubeOS must be able to allocate audit record storage capacity.
The task of allocating audit record storage capacity is usually performed during initial installation of KubeOS. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261413r996652_rule | | Identifiers and References | Identifiers:
C-261413 References:
16.5 | |
|
Rule
KubeOS auditd service must notify the system administrator (SA) and information system security officer (ISSO) immediately when audit storage capacity is 75 percent full.
[ref] |
Determine if KubeOS auditd is configured to notify the SA and ISSO when the audit record storage volume reaches 75 percent of the storage capacity with the following command:
$ grep -iw space_left /etc/audit/auditd.conf
space_left = 25%
If space_left is not set to 25% or greater, this is a finding.
| | Rationale: | If security personnel are not notified immediately when storage volume reaches 75 percent utilization, they are unable to plan for audit record storage capacity expansion. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261414r996654_rule | | Identifiers and References | Identifiers:
C-261414 References:
16.6 | |
|
Rule
KubeOS audit system must take appropriate action when the audit storage volume is full.
[ref] |
Verify KubeOS takes the appropriate action when the audit storage volume is full using the following command:
$ grep disk_full_action /etc/audit/auditd.conf
disk_full_action = HALT
If disk_full_action is not set to HALT, SYSLOG, or SINGLE, is commented out, or is missing, this is a finding.
| | Rationale: | It is critical that when KubeOS is at risk of failing to process audit logs as required, it takes action to mitigate the failure. Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. Responses to audit failure depend on the nature of the failure mode.
When availability is an overriding concern, other approved actions in response to an audit failure are as follows:
1) If the failure was caused by the lack of audit record storage capacity, KubeOS must continue generating audit records if possible (automatically restarting the audit service if necessary), overwriting the oldest audit records in a first-in-first-out manner.
2) If audit records are sent to a centralized collection server and communication with this server is lost or the server fails, KubeOS must queue audit records locally until communication is restored or until the audit records are retrieved manually. Upon restoration of the connection to the centralized collection server, action should be taken to synchronize the local audit data with the collection server. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261415r1038966_rule | | Identifiers and References | Identifiers:
C-261415 References:
16.7 | |
|
Rule
KubeOS must offload audit records onto a different system or media from the system being audited.
[ref] |
Verify what action the audit system takes if it cannot offload audit records to a different system or storage media from KubeOS being audited.
Check the action that the audit system takes in the event of a network failure with the following command:
$ grep -i "network_failure_action" /etc/audisp/audisp-remote.conf
network_failure_action = syslog
If the network_failure_action option is not set to syslog, single, or halt or the line is commented out, this is a finding.
| | Rationale: | Information stored in one location is vulnerable to accidental or incidental deletion or alteration.
Offloading is a common process in information systems with limited audit storage capacity. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261416r996660_rule | | Identifiers and References | Identifiers:
C-261416 References:
16.8 | |
|
Rule
Audispd must take appropriate action when KubeOS audit storage is full.
[ref] |
Verify the audit system offloads audit records if KubeOS storage volume becomes full.
Check that the records are properly offloaded to a remote server with the following command:
$ grep -i "^disk_full_action = syslog" /etc/audisp/audisp-remote.conf
disk_full_action = syslog
If disk_full_action is not set to syslog, single, or halt or the line is commented out, this is a finding.
| | Rationale: | Information stored in one location is vulnerable to accidental or incidental deletion or alteration.
Offloading is a common process in information systems with limited audit storage capacity. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261417r996662_rule | | Identifiers and References | Identifiers:
C-261417 References:
16.9 | |
|
Rule
KubeOS must protect audit rules from unauthorized modification.
[ref] |
Verify that KubeOS protects audit rules from unauthorized modification with the following command:
$ stat -c "%n %U:%G %a" /var/log/audit
/var/log/audit root:root 600
$ stat -c "%n %U:%G %a" /var/log/audit/audit.log
/var/log/audit/audit.log root:root 600
$ stat -c "%n %U:%G %a" /etc/audit/audit.rules
/etc/audit/audit.rules root:root 640
$ stat -c "%n %U:%G %a" /etc/audit/rules.d/audit.rules
/etc/audit/rules.d/audit.rules root:root 640
If the command does not return any output or permission is insufficient, this is a finding.
| | Rationale: | Without the capability to restrict which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261418r996665_rule | | Identifiers and References | Identifiers:
C-261418 References:
16.10 | |
|
Rule
KubeOS audit tools must have the proper permissions configured to protect against unauthorized access.
[ref] |
To protect from unauthorized access verify that KubeOS audit tools have the proper permissions configured in the permissions profile by using the following command:
$ stat -c "%n %U:%G %a" /usr/sbin/auditctl
/usr/sbin/auditctl root:root 750
$ stat -c "%n %U:%G %a" /usr/sbin/auditd
/usr/sbin/auditd root:root 750
$ stat -c "%n %U:%G %a" /usr/sbin/ausearch
/usr/sbin/ausearch root:root 755
$ stat -c "%n %U:%G %a" /usr/sbin/autrace
/usr/sbin/autrace root:root 750
$ stat -c "%n %U:%G %a" /usr/sbin/aureport
/usr/sbin/aureport root:root 755
$ stat -c "%n %U:%G %a" /usr/sbin/augenrules
/usr/sbin/augenrules root:root 750
If the command does not return any output or permission is insufficient, this is a finding.
| | Rationale: | Protecting audit information includes identifying and protecting the tools used to view and manipulate log data. Protecting audit tools is necessary to prevent unauthorized operation on audit information.
KubeOS providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys to make access decisions regarding the access to audit tools.
Audit tools include, but are not limited to, vendor-provided and open-source audit tools needed to view and manipulate audit information system activity and records. Audit tools include custom queries and report generators. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261419r996668_rule | | Identifiers and References | Identifiers:
C-261419 References:
16.11 | |
|
Rule
KubeOS audit event multiplexor must be configured to use Kerberos.
[ref] |
Determine if KubeOS audit event multiplexor is configured to use Kerberos by running the following command:
$ grep enable_krb5 /etc/audisp/audisp-remote.conf
enable_krb5 = yes
If enable_krb5 is not set to yes, or is commented out, this is a finding.
| | Rationale: | Information stored in one location is vulnerable to accidental or incidental deletion or alteration.
Allowing devices and users to connect to or from the system without first authenticating them allows untrusted access and can lead to a compromise or attack. Audit events that may include sensitive data must be encrypted prior to transmission. Kerberos provides a mechanism to provide both authentication and encryption for audit event records. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261421r996672_rule | | Identifiers and References | Identifiers:
C-261421 References:
16.65 | |
|
Rule
Audispd must offload audit records onto a different system or media from KubeOS being audited.
[ref] |
Verify audispd offloads audit records onto a different system or media from KubeOS being audited with the following command:
$ grep remote_server /etc/audisp/audisp-remote.conf
remote_server = 240.9.19.81
If remote_server is not set to an external server or media, or is commented out, this is a finding.
| | Rationale: | Information stored in one location is vulnerable to accidental or incidental deletion or alteration.
Offloading is a common process in information systems with limited audit storage capacity. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261422r996674_rule | | Identifiers and References | Identifiers:
C-261422 References:
16.12 | |
|
Rule
The information system security officer (ISSO) and system administrator (SA), at a minimum, must have mail aliases to be notified of a KubeOS audit processing failure.
[ref] |
Verify the administrators are notified in the event of a KubeOS audit processing failure with the following commands:
$ grep -i "^postmaster:" /etc/aliases
postmaster: root
If the above command does not return a value of root, or the output is commented out, this is a finding.
Verify the alias for root forwards to a monitored e-mail account:
$ grep -i "^root:" /etc/aliases
root: person@server.mil
If the alias for root does not forward to a monitored e-mail account, or the output is commented out, this is a finding.
| | Rationale: | It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without this notification, the security personnel may be unaware of an impending failure of the audit capability, and system operation may be adversely affected.
Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded.
This requirement applies to each audit data storage repository (i.e., distinct information system component where audit records are stored), the centralized audit storage capacity of organizations (i.e., all audit data storage repositories combined), or both. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261423r996677_rule | | Identifiers and References | Identifiers:
C-261423 References:
16.13 | |
|
Rule
The information system security officer (ISSO) and system administrator (SA), at a minimum, must be alerted of a KubeOS audit processing failure event.
[ref] |
Verify the system is configured to send email to an account when it needs to notify an administrator with the following command:
$ grep action_mail /etc/audit/auditd.conf
action_mail_acct = root
If the value of the action_mail_acct keyword is not set to root and/or other accounts for security personnel, the returned line is commented out, or the action_mail_acct keyword is missing, this is a finding.
| | Rationale: | It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without this notification, the security personnel may be unaware of an impending failure of the audit capability, and system operation may be adversely affected.
Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded.
This requirement applies to each audit data storage repository (i.e., distinct information system component where audit records are stored), the centralized audit storage capacity of organizations (i.e., all audit data storage repositories combined), or both. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261424r996679_rule | | Identifiers and References | Identifiers:
C-261424 References:
16.14 | |
|
Rule
KubeOS must generate audit records for all uses of the "chacl" command.
[ref] |
Verify KubeOS generates an audit record for all uses of the chacl command with the following command:
$ grep -w /usr/bin/chacl /etc/audit/rules.d/audit.rules
If the command does not return a line that matches the example or the line is commented out, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter). | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261425r996682_rule | | Identifiers and References | Identifiers:
C-261425 References:
16.15 | |
|
Rule
KubeOS must generate audit records for all uses of the "chage" command.
[ref] |
Verify KubeOS generates an audit record for any use of the chage command with the following command:
$ grep -w /usr/bin/chage /etc/audit/rules.d/audit.rules
If the command does not return any output, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter). | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261426r996685_rule | | Identifiers and References | Identifiers:
C-261426 References:
16.16 | |
|
Rule
KubeOS must generate audit records for all uses of the "chcon" command.
[ref] |
Verify KubeOS generates an audit record for all uses of the chcon command with the following command:
$ grep -w /usr/bin/chcon /etc/audit/rules.d/audit.rules
-a always,exit -S all -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=-1 -F key=prim_mod
If the command does not return any output, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter). | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261427r996688_rule | | Identifiers and References | Identifiers:
C-261427 References:
16.17 | |
|
Rule
KubeOS must generate audit records for all uses of the "chfn" command.
[ref] |
Verify KubeOS generates an audit record for all uses of the chfn command with the following command:
$ grep -w /usr/bin/chfn /etc/audit/rules.d/audit.rules
-a always,exit -S all -F path=/usr/bin/chfn -F perm=x -F auid>=1000 -F auid!=-1 -F key=privileged-chfn
If the command does not return any output or the returned line is commented out, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.
At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261428r996691_rule | | Identifiers and References | Identifiers:
C-261428 References:
16.18 | |
|
Rule
KubeOS must generate audit records for all uses of the "chmod" command.
[ref] |
Verify KubeOS generates an audit record for all uses of the chmod command with the following command:
$ grep -w /usr/bin/chmod /etc/audit/rules.d/audit.rules
-a always,exit -S all -F path=/usr/bin/chmod -F perm=x -F auid>=1000 -F auid!=-1 -F key=prim_mod
If the command does not return any output, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter). | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261429r996694_rule | | Identifiers and References | Identifiers:
C-261429 References:
16.19 | |
|
Rule
KubeOS must generate audit records for a uses of the "chsh" command.
[ref] |
Verify KubeOS generates an audit record for all uses of the chsh command with the following command:
$ grep -w /usr/bin/chsh /etc/audit/rules.d/audit.rules
-a always,exit -S all -F path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=-1 -F key=privileged-chsh
If the command does not return any output, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.
At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261430r996697_rule | | Identifiers and References | Identifiers:
C-261430 References:
16.20 | |
|
Rule
KubeOS must generate audit records for all uses of the "crontab" command.
[ref] |
Verify KubeOS generates an audit record for any use of the crontab command with the following command:
$ grep -w /usr/bin/crontab /etc/audit/rules.d/audit.rules
-a always,exit -S all -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=-1 -F key=privileged-crontab
If the command does not return any output, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter). | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261431r996700_rule | | Identifiers and References | Identifiers:
C-261431 References:
16.21 | |
|
Rule
KubeOS must generate audit records for all uses of the "gpasswd" command.
[ref] |
Verify KubeOS generates an audit record for all uses of the gpasswd command with the following command:
$ grep -w /usr/bin/gpasswd /etc/audit/rules.d/audit.rules
-a always,exit -S all -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=-1 -F key=privileged-gpasswd
If the command does not return any output, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.
At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261432r996703_rule | | Identifiers and References | Identifiers:
C-261432 References:
16.22 | |
|
Rule
KubeOS must generate audit records for all uses of the "insmod" command.
[ref] |
Verify KubeOS is generates an audit record for all uses of the insmod command with the following command:
$ grep -w /sbin/insmod /etc/audit/rules.d/audit.rules
-w /sbin/insmod -p x -k modules
If the system is configured to audit the execution of the module management program insmod, the command will return a line.
If the command does not return a line that matches the example or the line is commented out, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records.
The organization has defined the following list of events for which KubeOS will provide an audit record generation capability:
1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);
2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system;
3) All account creations, modifications, disabling, and terminations; and
4) All kernel module load, unload, and restart actions. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261433r996706_rule | | Identifiers and References | Identifiers:
C-261433 References:
16.23 | |
|
Rule
KubeOS must generate audit records for all uses of the "kmod" command.
[ref] |
Verify KubeOS generates an audit record for all uses of the kmod command with the following command:
$ grep -w /usr/bin/kmod /etc/audit/rules.d/audit.rules
-w /usr/bin/kmod -p x -k modules
If the system is configured to audit the execution of the module management program kmod, the command will return a line.
If the command does not return a line that matches the example or the line is commented out, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records.
The organization has defined the following list of events for which KubeOS will provide an audit record generation capability:
1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);
2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system;
3) All account creations, modifications, disabling, and terminations; and
4) All kernel module load, unload, and restart actions. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261434r996709_rule | | Identifiers and References | Identifiers:
C-261434 References:
16.24 | |
|
Rule
KubeOS must generate audit records for all uses of the "modprobe" command.
[ref] |
Verify KubeOS generates an audit record for all uses of the modprobe command with the following command:
$ grep -w /sbin/modprobe /etc/audit/rules.d/audit.rules
-w /sbin/modprobe -p x -k modules
If the command does not return a line that matches the example or the line is commented out, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records.
The organization has defined the following list of events for which KubeOS will provide an audit record generation capability:
1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);
2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system;
3) All account creations, modifications, disabling, and terminations; and
4) All kernel module load, unload, and restart actions. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261435r996712_rule | | Identifiers and References | Identifiers:
C-261435 References:
16.25 | |
|
Rule
KubeOS must generate audit records for all uses of the "newgrp" command.
[ref] |
Verify KubeOS generates an audit record for all uses of the newgrp command with the following command:
$ grep -w /usr/bin/newgrp /etc/audit/rules.d/audit.rules
-a always,exit -S all -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=-1 -F key=privileged-newgrp
If the command does not return any output, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.
At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261436r996715_rule | | Identifiers and References | Identifiers:
C-261436 References:
16.26 | |
|
Rule
KubeOS must generate audit records for all uses of the "pam_timestamp_check" command.
[ref] |
Verify KubeOS generates an audit record for any use of the pam_timestamp_check command with the following command:
$ grep -w /sbin/pam_timestamp_check /etc/audit/rules.d/audit.rules
-a always,exit -S all -F path=/sbin/pam_timestamp_check -F perm=x -F auid>=1000 -F auid!=-1 -F key=privileged-pam_timestamp_check
If the command does not return any output, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter). | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261437r996718_rule | | Identifiers and References | Identifiers:
C-261437 References:
16.27 | |
|
Rule
KubeOS must generate audit records for all uses of the "passwd" command.
[ref] |
Verify KubeOS generates an audit record for all uses of the passwd command with the following command:
$ grep -w /usr/bin/passwd /etc/audit/rules.d/audit.rules
-a always,exit -S all -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=-1 -F key=privileged-passwd
If the command does not return any output, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.
At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261438r996721_rule | | Identifiers and References | Identifiers:
C-261438 References:
16.28 | |
|
Rule
KubeOS must generate audit records for all uses of the "rm" command.
[ref] |
Verify KubeOS generates an audit record for all uses of the rm command with the following command:
$ grep -w /usr/bin/rm /etc/audit/rules.d/audit.rules
-a always,exit -S all -F path=/usr/bin/rm -F perm=x -F auid>=1000 -F auid!=-1 -F key=prim_mod
If the command does not return any output, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter). | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261439r996724_rule | | Identifiers and References | Identifiers:
C-261439 References:
16.29 | |
|
Rule
KubeOS must generate audit records for all uses of the "rmmod" command.
[ref] |
Verify KubeOS generates an audit record for all uses of the rmmod command with the following command:
$ grep -w /sbin/rmmod /etc/audit/rules.d/audit.rules
-w /sbin/rmmod -p x -k modules
If the system is configured to audit the execution of the module management program rmmod, the command will return a line.
If the command does not return a line that matches the example or the line is commented out, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter).
The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records.
The organization has defined the following list of events for which KubeOS will provide an audit record generation capability:
1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);
2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system;
3) All account creations, modifications, disabling, and terminations; and
4) All kernel module load, unload, and restart actions. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261440r996727_rule | | Identifiers and References | Identifiers:
C-261440 References:
16.30 | |
|
Rule
KubeOS must generate audit records for all uses of the "setfacl" command.
[ref] |
Verify KubeOS generates an audit record for all uses of the setfacl command with the following command:
$ grep -w /usr/bin/setfacl /etc/audit/rules.d/audit.rules
-a always,exit -S all -F path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=-1 -F key=prim_mod
If the command does not return any output, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter). | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261441r996730_rule | | Identifiers and References | Identifiers:
C-261441 References:
16.31 | |
|
Rule
KubeOS must generate audit records for all uses of the "ssh-agent" command.
[ref] |
Verify KubeOS generates an audit record for all uses of the ssh-agent command with the following command:
$ grep -w /usr/bin/ssh-agent /etc/audit/rules.d/audit.rules
-a always,exit -S all -F path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=-1 -F key=privileged-ssh-agent
If the command does not return any output or the returned line is commented out, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.
At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261442r996733_rule | | Identifiers and References | Identifiers:
C-261442 References:
16.32 | |
|
Rule
KubeOS must generate audit records for all uses of the "ssh-keysign" command.
[ref] |
Verify KubeOS generates an audit record for all uses of the ssh-keysign command with the following command:
$ grep -w /usr/lib/ssh/ssh-keysign /etc/audit/rules.d/audit.rules
-a always,exit -S all -F path=/usr/lib/ssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=-1 -F key=privileged-ssh-keysign
If the command does not return any output, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.
At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261443r996736_rule | | Identifiers and References | Identifiers:
C-261443 References:
16.33 | |
|
Rule
KubeOS must generate audit records for all uses of the "su" command.
[ref] |
Verify KubeOS generates an audit record for any use of the su command with the following command:
$ grep -w /usr/bin/su /etc/audit/rules.d/audit.rules
-a always,exit -S all -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=-1 -F key=privileged-priv_change
If the command does not return any output or the returned line is commented out, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter). | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261444r996739_rule | | Identifiers and References | Identifiers:
C-261444 References:
16.34 | |
|
Rule
KubeOS must generate audit records for all uses of the "sudo" command.
[ref] |
Verify KubeOS generates an audit record for any use of the sudo command with the following command:
$ grep -w /usr/bin/sudo /etc/audit/rules.d/audit.rules
-a always,exit -S all -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=-1 -F key=privileged-sudo
If the command does not return any output, or the returned line is commented out, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.
At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261445r996742_rule | | Identifiers and References | Identifiers:
C-261445 References:
16.35 | |
|
Rule
KubeOS must generate audit records for all uses of the "sudoedit" command.
[ref] |
Verify an audit record is generated for all uses of the sudoedit command with the following command:
$ grep -w /usr/bin/sudoedit /etc/audit/rules.d/audit.rules
-a always,exit -S all -F path=/usr/bin/sudoedit -F perm=x -F auid>=1000 -F auid!=-1 -F key=privileged-sudoedit
If the command does not return any output or the returned line is commented out, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter). | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261446r996745_rule | | Identifiers and References | Identifiers:
C-261446 References:
16.36 | |
|
Rule
KubeOS must generate audit records for all uses of the "unix_chkpwd" or "unix2_chkpwd" commands.
[ref] |
Verify KubeOS generates an audit record for any use of the unix_chkpwd or unix2_chkpwd commands with the following command:
$ grep -w /sbin/unix_chkpwd /etc/audit/rules.d/audit.rules
-a always,exit -S all -F path=/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=-1 -F key=privileged-unix-chkpwd
$ grep -w /sbin/unix2_chkpwd /etc/audit/rules.d/audit.rules
-a always,exit -S all -F path=/sbin/unix2_chkpwd -F perm=x -F auid>=1000 -F auid!=-1 -F key=privileged-unix2-chkpwd
If the command does not return any output, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter). | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261447r996748_rule | | Identifiers and References | Identifiers:
C-261447 References:
16.37 | |
|
Rule
KubeOS must generate audit records for all uses of the "usermod" command.
[ref] |
Verify KubeOS generates an audit record for any use of the usermod command with the following command:
$ grep -w /usr/sbin/usermod /etc/audit/rules.d/audit.rules
-a always,exit -S all -F path=/usr/sbin/usermod -F perm=x -F auid>=1000 -F auid!=-1 -F key=privileged-usermod
If the command does not return any output, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter). | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261448r996751_rule | | Identifiers and References | Identifiers:
C-261448 References:
16.38 | |
|
Rule
KubeOS must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/group.
[ref] |
Verify KubeOS generates an audit record when modifications occur to the /etc/group file with the following command:
$ grep -w /etc/group /etc/audit/rules.d/audit.rules
-w /etc/group -p wa -k account_mod
If the command does not return a line that matches the example or the line is commented out, this is a finding.
Note: The -k value is arbitrary and can be different from the example output above.
| | Rationale: | Once an attacker establishes initial access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to simply create a new account. Auditing account creation mitigates this risk.
To address access requirements, KubeOS may be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261449r996754_rule | | Identifiers and References | Identifiers:
C-261449 References:
16.39 | |
|
Rule
KubeOS must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/security/opasswd.
[ref] |
Verify KubeOS generates an audit record when modifications occur to the /etc/security/opasswd file with the following command:
$ grep -w /etc/security/opasswd /etc/audit/rules.d/audit.rules
-w /etc/security/opasswd -p wa -k account_mod
If the command does not return a line that matches the example or the line is commented out, this is a finding.
Notes: The -k allows for specifying an arbitrary identifier. The string following -k does not need to match the example output above.
| | Rationale: | Once an attacker establishes initial access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to simply create a new account. Auditing account creation mitigates this risk.
To address access requirements, KubeOS may be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261450r996757_rule | | Identifiers and References | Identifiers:
C-261450 References:
16.40 | |
|
Rule
KubeOS must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/passwd.
[ref] |
Verify KubeOS generates an audit record when all modifications occur to the /etc/passwd file with the following command:
$ grep -w /etc/passwd /etc/audit/rules.d/audit.rules
-w /etc/passwd -p wa -k account_mod
If the command does not return a line that matches the example or the line is commented out, this is a finding.
Notes: The -k allows for specifying an arbitrary identifier. The string following -k does not need to match the example output above.
| | Rationale: | Once an attacker establishes initial access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to simply create a new account. Auditing account creation mitigates this risk.
To address access requirements, KubeOS may be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261451r996760_rule | | Identifiers and References | Identifiers:
C-261451 References:
16.41 | |
|
Rule
KubeOS must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/shadow.
[ref] |
Verify KubeOS generates an audit record when modifications occur to the /etc/shadow file with the following command:
$ grep -w /etc/shadow /etc/audit/rules.d/audit.rules
-w /etc/shadow -p wa -k account_mod
If the command does not return a line that matches the example or the line is commented out, this is a finding.
Notes: The -k allows for specifying an arbitrary identifier. The string following -k does not need to match the example output above.
| | Rationale: | Once an attacker establishes initial access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to simply create a new account. Auditing account creation mitigates this risk.
To address access requirements, KubeOS may be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261452r996763_rule | | Identifiers and References | Identifiers:
C-261452 References:
16.42 | |
|
Rule
KubeOS must generate audit records for all uses of the "chmod", "fchmod" and "fchmodat" system calls.
[ref] |
Verify KubeOS generates an audit record for all uses of the chmod, fchmod and fchmodat system calls with the following command:
$ grep -w chmod,fchmod,fchmodat /etc/audit/rules.d/audit.rules
-a always,exit -F arch=b32 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=-1 -F key=perm_mod
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=-1 -F key=perm_mod
If both the b32 and b64 audit rules are not defined for the chmod, fchmod, and fchmodat syscalls, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter). The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. However, the performance can be helped by combining syscalls into one rule whenever possible. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261453r996848_rule | | Identifiers and References | Identifiers:
C-261453 References:
16.43 | |
|
Rule
KubeOS must generate audit records for all uses of the "chown", "fchown", "fchownat", and "lchown" system calls.
[ref] |
Verify KubeOS generates an audit record for all uses of the chown, fchown, fchownat, and lchown system calls with the following command:
$ grep -w chown,fchown,fchownat,lchown /etc/audit/rules.d/audit.rules
-a always,exit -F arch=b32 -S chown,fchown,fchownat,lchown -F auid>=1000 -F auid!=-1 -F key=perm_mod
-a always,exit -F arch=b64 -S chown,fchown,fchownat,lchown -F auid>=1000 -F auid!=-1 -F key=perm_mod
If both the b32 and b64 audit rules are not defined for the chown, fchown, fchownat, and lchown syscalls, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter). The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary, since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261454r996769_rule | | Identifiers and References | Identifiers:
C-261454 References:
16.44 | |
|
Rule
KubeOS must generate audit records for all uses of the "creat", "open", "openat", "open_by_handle_at", "truncate", and "ftruncate" system calls.
[ref] |
Verify KubeOS generates an audit record for all uses of the creat, open, openat, open_by_handle_at, truncate, and ftruncate system calls with the following command:
$ grep -w creat,open,openat,open_by_handle_at,truncate,ftruncate /etc/audit/rules.d/audit.rules
-a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=-1 -F key=perm_access
-a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=-1 -F key=perm_access
-a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=-1 -F key=perm_access
-a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=-1 -F key=perm_access
If both the b32 and b64 audit rules are not defined for the creat, open, openat, open_by_handle_at, truncate, and ftruncate syscalls, this is a finding.
If the output does not produce rules containing -F exit=-EPERM, this is a finding.
If the output does not produce rules containing -F exit=-EACCES, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter). The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary, since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261455r996772_rule | | Identifiers and References | Identifiers:
C-261455 References:
16.45 | |
|
Rule
KubeOS must generate audit records for all uses of the "delete_module" system call.
[ref] |
Verify KubeOS generates an audit record for all uses of the delete_module system call with the following command:
$ grep -w delete_module /etc/audit/rules.d/audit.rules
-a always,exit -F arch=b32 -S delete_module -F auid>=1000 -F auid!=-1 -F key=unload_module
-a always,exit -F arch=b64 -S delete_module -F auid>=1000 -F auid!=-1 -F key=unload_module
If both the b32 and b64 audit rules are not defined for the unload_module syscall, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter). | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261456r996775_rule | | Identifiers and References | Identifiers:
C-261456 References:
16.46 | |
|
Rule
KubeOS must generate audit records for all uses of the "init_module" and "finit_module" system calls.
[ref] |
Verify KubeOS generates an audit record for all uses of the init_module and finit_module system calls with the following command:
$ grep -w init_module,finit_module /etc/audit/rules.d/audit.rules
-a always,exit -F arch=b32 -S init_module,finit_module -F auid>=1000 -F auid!=-1 -F key=moduleload
-a always,exit -F arch=b64 -S init_module,finit_module -F auid>=1000 -F auid!=-1 -F key=moduleload
If both the b32 and b64 audit rules are not defined for the init_module and finit_module syscalls, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter). The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary, since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261457r996778_rule | | Identifiers and References | Identifiers:
C-261457 References:
16.47 | |
|
Rule
KubeOS must generate audit records for all uses of the "mount" system call.
[ref] |
Verify KubeOS generates an audit record for all uses of the mount system call with the following command:
$ grep -w mount /etc/audit/rules.d/audit.rules
-a always,exit -F arch=b32 -S mount -F auid>=1000 -F auid!=-1 -F key=privileged-mount
-a always,exit -F arch=b64 -S mount -F auid>=1000 -F auid!=-1 -F key=privileged-mount
If both the b32 and b64 audit rules are not defined for the mount syscall, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.
At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261458r996781_rule | | Identifiers and References | Identifiers:
C-261458 References:
16.48 | |
|
Rule
KubeOS must generate audit records for all uses of the "setxattr", "fsetxattr", "lsetxattr", "removexattr", "fremovexattr", and "lremovexattr" system calls.
[ref] |
Verify KubeOS generates an audit record for all uses of the setxattr, fsetxattr, lsetxattr, removexattr, fremovexattr, and lremovexattr system calls with the following command:
$ grep -w setxattr,fsetxattr,lsetxattr,removexattr,fremovexattr,lremovexattr /etc/audit/rules.d/audit.rules
-a always,exit -F arch=b32 -S setxattr,fsetxattr,lsetxattr,removexattr,fremovexattr,lremovexattr -F auid>=1000 -F auid!=-1 -F key=perm_mod
-a always,exit -F arch=b64 -S setxattr,fsetxattr,lsetxattr,removexattr,fremovexattr,lremovexattr -F auid>=1000 -F auid!=-1 -F key=perm_mod
If both the b32 and b64 audit rules are not defined for the setxattr, fsetxattr, lsetxattr, removexattr, fremovexattr, and lremovexattr syscalls, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter). The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary, since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261459r996784_rule | | Identifiers and References | Identifiers:
C-261459 References:
16.49 | |
|
Rule
KubeOS must generate audit records for all uses of the "umount" system call.
[ref] |
Verify KubeOS generates an audit record for all uses of the umount and umount2 system calls with the following command:
> grep -w umount /etc/audit/rules.d/audit.rules
-a always,exit -F arch=b32 -S umount -F auid>=1000 -F auid!=-1 -F key=privileged-umount
-a always,exit -F arch=b32 -S umount2 -F auid>=1000 -F auid!=-1 -F key=privileged-umount
-a always,exit -F arch=b64 -S umount2 -F auid>=1000 -F auid!=-1 -F key=privileged-umount
If both the b32 and b64 audit rules are not defined for the umount syscall, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.
At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261460r996787_rule | | Identifiers and References | Identifiers:
C-261460 References:
16.50 | |
|
Rule
KubeOS must generate audit records for all uses of the "unlink", "unlinkat", "rename", "renameat", and "rmdir" system calls.
[ref] |
Verify KubeOS generates an audit record for all uses of the unlink, unlinkat, rename, renameat, and rmdir system calls with the following command:
$ grep -w unlink,unlinkat,rename,renameat,rmdir /etc/audit/rules.d/audit.rules
-a always,exit -F arch=b32 -S unlink,unlinkat,rename,renameat,rmdir -F auid>=1000 -F auid!=-1 -F key=perm_mod
-a always,exit -F arch=b64 -S unlink,unlinkat,rename,renameat,rmdir -F auid>=1000 -F auid!=-1 -F key=perm_mod
If both the b32 and b64 audit rules are not defined for the unlink, unlinkat, rename, renameat, and rmdir syscalls, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter). The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary, since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261461r996790_rule | | Identifiers and References | Identifiers:
C-261461 References:
16.51 | |
|
Rule
KubeOS must generate audit records for all uses of privileged functions.
[ref] |
Verify KubeOS generates an audit record for any privileged use of the execve system call with the following command:
$ grep -w execve /etc/audit/rules.d/audit.rules
-a always,exit -F arch=b32 -S execve -C uid!=euid -F euid=0 -F key=setuid
-a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -F key=setuid
-a always,exit -F arch=b32 -S execve -C gid!=egid -F egid=0 -F key=setgid
-a always,exit -F arch=b64 -S execve -C gid!=egid -F egid=0 -F key=setgid
If both the b32 and b64 audit rules for SUID files are not defined, this is a finding.
If both the b32 and b64 audit rules for SGID files are not defined, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised information system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider threats and the advanced persistent threat. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261462r996793_rule | | Identifiers and References | Identifiers:
C-261462 References:
16.52 | |
|
Rule
KubeOS must generate audit records for all modifications to the "lastlog" file.
[ref] |
Verify KubeOS generates an audit record when all modifications to the lastlog file occur with the following command:
$ grep -w /var/log/lastlog /etc/audit/rules.d/audit.rules
-w /var/log/lastlog -p wa -k logins
If the command does not return a line that matches the example or the line is commented out, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter). | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261463r996796_rule | | Identifiers and References | Identifiers:
C-261463 References:
16.53 | |
|
Rule
KubeOS must generate audit records for all modifications to the "tallylog" file.
[ref] |
Verify KubeOS generates an audit record when all modifications to the tallylog file occur with the following command:
$ grep -w /var/log/tallylog /etc/audit/rules.d/audit.rules
-w /var/log/tallylog -p wa -k logins
If the command does not return a line that matches the example or the line is commented out, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter). | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261464r996799_rule | | Identifiers and References | Identifiers:
C-261464 References:
16.54 | |
|
Rule
KubeOS must audit all uses of the sudoers file and all files in the "/etc/sudoers.d/" directory.
[ref] |
Verify KubeOS generates audit records when successful/unsuccessful attempts to access the /etc/sudoers file and files in the /etc/sudoers.d/ directory with the following command:
$ grep -w /etc/sudoers /etc/audit/rules.d/audit.rules
-w /etc/sudoers -p wa -k privileged-actions
$ grep -w /etc/sudoers.d /etc/audit/rules.d/audit.rules
-w /etc/sudoers.d -p wa -k privileged-actions
If the commands do not return output that match the examples, this is a finding.
Notes: The -k allows for specifying an arbitrary identifier. The string following -k does not need to match the example output above.
| | Rationale: | Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.
At a minimum, the organization must audit the full-text recording of privileged access commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261465r996802_rule | | Identifiers and References | Identifiers:
C-261465 References:
16.55 | |
|
Rule
Successful/unsuccessful uses of "setfiles" in KubeOS must generate an audit record.
[ref] |
Verify KubeOS generates an audit record for all uses of the setfiles command with the following command:
$ grep -w /usr/sbin/setfiles /etc/audit/rules.d/audit.rules
-a always,exit -F path=/usr/sbin/setfiles -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix-update
If the command does not return a line, or the line is commented out, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.
At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise. The "setfiles" command is primarily used to initialize the security context fields (extended attributes) on one or more filesystems (or parts of them). Usually it is initially run as part of the SELinux installation process (a step commonly known as labeling).
When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1". The AUID representation is an unsigned 32-bit integer, which equals "4294967295". The audit system interprets "-1", "4294967295", and "unset" in the same way. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261466r996805_rule | | Identifiers and References | Identifiers:
C-261466 References:
16.56 | |
|
Rule
Successful/unsuccessful uses of "semanage" in KubeOS must generate an audit record.
[ref] |
Verify KubeOS generates an audit record for all uses of the semanage command with the following command:
$ grep -w /usr/sbin/semanage /etc/audit/rules.d/audit.rules
-a always,exit -F path=/usr/sbin/semanage -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix-update
If the command does not return a line, or the line is commented out, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.
At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise. The "semanage" command is used to configure certain elements of SELinux policy without requiring modification to or recompilation from policy sources.
When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1". The AUID representation is an unsigned 32-bit integer, which equals "4294967295". The audit system interprets "-1", "4294967295", and "unset" in the same way. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261467r996808_rule | | Identifiers and References | Identifiers:
C-261467 References:
16.57 | |
|
Rule
Successful/unsuccessful uses of "setsebool" in KubeOS must generate an audit record.
[ref] |
Verify KubeOS generates an audit record for all uses of the setsebool command with the following command:
$ grep -w /usr/sbin/setsebool /etc/audit/rules.d/audit.rules
-a always,exit -F path=/usr/sbin/setsebool -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix-update
If the command does not return a line, or the line is commented out, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.
At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise. The "setsebool" command sets the current state of a particular SELinux Boolean or a list of Booleans to a given value.
When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1". The AUID representation is an unsigned 32-bit integer, which equals "4294967295". The audit system interprets "-1", "4294967295", and "unset" in the same way. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261468r997405_rule | | Identifiers and References | Identifiers:
C-261468 References:
16.58 | |
|
Rule
KubeOS must generate audit records for the "/run/utmp file".
[ref] |
Verify KubeOS generates an audit record for the /run/utmp file with the following command:
$ grep -w /run/utmp /etc/audit/rules.d/audit.rules
-w /run/utmp -p wa -k login_mod
If the command does not return a line that matches the example, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter). | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261469r996814_rule | | Identifiers and References | Identifiers:
C-261469 References:
16.59 | |
|
Rule
KubeOS must generate audit records for the "/var/log/btmp" file.
[ref] |
Verify KubeOS generates an audit record for the /var/log/btmp file with the following command:
$ grep -w /var/log/btmp /etc/audit/rules.d/audit.rules
-w /var/log/btmp -p wa -k login_mod
If the command does not return a line that matches the example, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter). | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261470r996817_rule | | Identifiers and References | Identifiers:
C-261470 References:
16.60 | |
|
Rule
KubeOS must generate audit records for the "/var/log/wtmp" file.
[ref] |
Verify KubeOS generates an audit record for the /var/log/wtmp file with the following command:
> grep -w /var/log/wtmp /etc/audit/rules.d/audit.rules
-w /var/log/wtmp -p wa -k login_mod
If the command does not return a line that matches the example, this is a finding.
Note: The key= value is arbitrary and can be different from the example output above.
| | Rationale: | Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the information system (e.g., module or policy filter). | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261471r996820_rule | | Identifiers and References | Identifiers:
C-261471 References:
16.61 | |
|
Rule
KubeOS must not disable syscall auditing.
[ref] |
Verify syscall auditing has not been disabled with the following command:
$ grep -i "\-a task,never" /etc/audit/rules.d/audit.rules
If any results are returned, this is a finding.
Verify the default rule -a task,never is not statically defined:
$ grep -rv "^#" /etc/audit/rules.d/ | grep -i "a task,never"
If any results are returned, this is a finding.
| | Rationale: | By default, KubeOS includes the "-a task,never" audit rule as a default. This rule suppresses syscall auditing for all tasks started with this rule in effect. Because the audit daemon processes the "audit.rules" file from the top down, this rule supersedes all other defined syscall rules; therefore no syscall auditing can take place on the operating system. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261472r996865_rule | | Identifiers and References | Identifiers:
C-261472 References:
16.62 | |
|
Rule
FIPS 140-2/140-3 mode must be enabled on KubeOS.
[ref] |
Verify KubeOS is running in FIPS mode by running the following command.
$ cat /proc/sys/crypto/fips_enabled
1
If the value returned is 0, nothing is returned, or the file does not exist, this is a finding.
| | Rationale: | Use of weak or untested encryption algorithms undermines the purposes of using encryption to protect data. KubeOS must implement cryptographic modules adhering to the higher standards approved by the organization since this provides assurance they have been tested and validated. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_EC-261473r996824_rule | | Identifiers and References | Identifiers:
C-261473 References:
21.1 | |
|