Implementing Extra Security Features and Best Practices

The Linux kernel features some extra security mechanisms that enhance the security of a system. These mechanisms randomize the layout of the address space for a process or prevent code from being run in non-executable memory.

The kernel uses a ring buffer to surface messages for troubleshooting purposes, and these messages can be viewed by running the dmesg command.

Threat actors can use those messages to find exploits in the system, so it's considered good security practice to ensure that only users with root permissions can run the dmesg command.

On Oracle Linux 9 systems running the Unbreakable Enterprise Kernel (UEK) 8, access is restricted by default.

To check whether access is restricted, run the following command:

sudo sysctl kernel.dmesg_restrict

If the value returned is 1, then access is already restricted.

If the value returned isn't 1, or the value is missing entirely, then you can restrict access by setting the value in a configuration file that's stored in the /etc/sysctl.d/ directory. For example, the following command creates the /etc/sysctl.d/dmesg-restrict configuration file:

echo kernel.dmesg_restrict = 1 | sudo tee /etc/sysctl.d/dmesg-restrict

To apply the change without restarting the system, run the following command:

sudo sysctl -p /etc/sysctl.d/dmesg-restrict

Since Oracle Linux 8, Oracle Linux provides a facility to set a system-wide cryptographic policy. Many applications implement cryptographic protocols to secure communications or to encrypt data. Historically, applications have maintained their own configuration of cryptographic policies in various ways, which meant that changing cryptographic policy across an entire system needed to be performed for each application and often the configuration method differed from application to application.

The ability to define a system-wide cryptographic policy that applications can hook into often reduces administrative overhead and simplifies the process. An administrator can configure the system-wide cryptographic policy and have confidence that most applications can use the same policy, by default.

Policies enable an administrator to configure:

• TLS/SSL (and DTLS) versions that are accepted
• Ciphersuites that are accepted and the preferred order
• Parameters that are accepted for certificates and key exchange, including:
  • the minimum acceptable size of parameters (DH,ECDH,RSA,DSA,ECDSA),
  • the acceptable elliptic curves (ECDH,ECDSA),
  • the acceptable signature hash functions.
• Other TLS options including safe-renegotiation

Most of the major cryptographic software on Oracle Linux is already configured to use the system-wide cryptographic policy by default. Applications that are configured to behave in this manner include important applications such as OpenSSH and bind, in addition to any applications that use the OpenSSL, GnuTLS, NSS, and libkrb5 libraries.

Configuring system-wide policy doesn't enforce behavior across the system. That policy provides a common configuration across a wide variety of applications. Any application that's not designed to use the system-wide policy continues to function according to the different policy configuration that it uses. Many applications also provide options to override the system-wide cryptographic policy if required. For example, OpenSSH provides options to set different cryptographic policies on the server and client applications, and commands such as wget and curl provide options to define a custom cipher selection and order by using the --ciphers option, effectively overriding the system-wide policy.

The system-wide policy defines the default cryptographic behavior within applications so that you can harden a system and remove insecure protocols to match your security requirements.

Oracle Linux includes the update-crypto-policies command that can be used to configure which cryptographic algorithms, ciphers, and protocols are enabled on a system for use by applications and services. That command can be used to either relax policy or to harden it further.

For more information on this tool and the applications that are affected by it, see the crypto-policies(7) and update-crypto-policies(8) manual pages.

Checking the system for unlocked user accounts often is considered good security practice, for example by using this command:

for u in $(awk -F: '{print $1}' /etc/passwd;); do sudo passwd -S "$u"; done | sort

The following output is displayed:

adm LK 2023-03-31 0 99999 7 -1 (Alternate authentication scheme in use.)
bin LK 2023-03-31 0 99999 7 -1 (Alternate authentication scheme in use.)
chrony LK 2023-06-20 -1 -1 -1 -1 (Password locked.)
clevis LK 2023-06-20 -1 -1 -1 -1 (Password locked.)
cockpit-wsinstance LK 2023-06-20 -1 -1 -1 -1 (Password locked.)
cockpit-ws LK 2023-06-20 -1 -1 -1 -1 (Password locked.)
...

In the output from this command, the second field shows if a user account is locked (LK), doesn't have a password (NP), or has a valid password (PS). The third field shows the date on which the user last changed their password. The remaining fields show the minimum age, maximum age, warning period, and inactivity period for the password and extra information about the password's status. The unit of time is days.

You can use the passwd command to set passwords on any accounts that aren't protected.

To lock unused accounts, use the passwd -l command. You can also use the userdel command to remove the accounts entirely.

For more information, see the passwd(1) and userdel(8) manual pages.

To specify how users' passwords are aged, edit the settings in the /etc/login.defs file that are described in the following table.

For more information, see the login.defs(5) manual page.

To change the length of time a user's account can be inactive before it's locked, use the usermod command. For example, you would set the inactivity period to 30 days as follows:

sudo usermod -f 30 username

To change the default inactivity period for new user accounts, use the useradd command:

sudo useradd -D -f 30

A value of -1 specifies that user accounts are never locked because of inactivity.

For more information, see the useradd(8) and usermod(8) manual pages.

To verify that no user accounts other than root have a user ID of 0, you would use the following command:

sudo awk -F":" '$3 == 0 { print $1 }' /etc/passwd

The following is the output of the previous command:

root

If you install software that creates a default user account and password, it's considered good security practice to change the vendor's default password immediately. Centralized user authentication using an LDAP implementation such as OpenLDAP can centralize user authentication and management tasks, and also reduce the risks arising from unused accounts or accounts without a password.

By default, an Oracle Linux 9 system is configured to prevent users from signing in directly as root. If a root user hasn't been created during the initial system installation, sign in as a named user and then use either the su or sudo command to perform tasks as the root user so that system accounting can trace the original username of any user who performs a privileged administrative action. To grant certain users authority to perform specific administrative tasks by using the sudo command, use the visudo command to configure the /etc/sudoers file.

For example, the following entry grants the user user1 the same privileges as root when using the sudo command, but defines a limited set of privileges to user2 so that they can run commands such as systemctl, rpm, and dnf:

user1           ALL=(ALL)       ALL
user2           ALL= SERVICES, SOFTWARE

For more information about setting up user accounts and authentication, see Oracle Linux 9: Setting Up System Users and Authentication.

If you follow traditional digital identity policies, the Pluggable Authentication Modules (PAM) feature can be used to enforce strong user authentication and password policies, including rules that decide password complexity, length, age, expiration, and the reuse of previous passwords. You can configure PAM to block user access after too many failed login attempts, after normal working hours, or if too many concurrent sessions are open. Note that some of these policies are no longer considered helpful for security as they can lead users to implement their own poor security practices when storing passwords or when renewing. See https://pages.nist.gov/800-63-3/sp800-63-3.html for more information.

PAM is highly customizable by its use of different modules with customizable parameters. For example, the default password integrity checking module pam_pwquality.so tests password strength. The PAM configuration file (/etc/pam.d/system-auth) contains the following default entries for testing a password's strength:

password    requisite    pam_pwquality.so local_users_only retry=3 authtok_type= enforce_for_root
password    requisite    pam_pwhistory.so use_authtok enforce_for_root remember=4
password    sufficient   pam_unix.so sha512 shadow use_authtok enforce_for_root remember=4
password    sufficient   pam_sss.so use_authtok
password    required     pam_deny.so

The line for pam_pwquality.so defines that a user gets three tries to choose a good password. From the module's default settings, the password length must a minimum of six characters, of which three characters can't be the same as a previous password. The module only tests the quality of passwords for users who are defined in the /etc/passwd file.

The line for pam_unix.so specifies that the module tests the old password that was specified in the stack before prompting for a new password and uses the SHA-512 password hashing and the /etc/shadow file to decide access. Note that pam_pwquality will have performed such checks for users that have been defined in the /etc/passwd file.

The line for pam_pwquality.so specifies that a user is allowed three tries to select a good password, with a minimum of eight characters, of which five characters must be different from the previous password, and which must contain at least one uppercase letter, one lowercase letter, one numeric digit, and one special character.

The line for pam_unix.so specifies that the module doesn't perform password checking, uses SHA-512 password hashing and the /etc/shadow file, and saves information about the previous five passwords for each user in the /etc/security/opasswd file.

For more information, see the pam_deny(8), pam_pwquality(8), and pam_unix(8) manual pages.

The authselect command can be used to switch between system authentication profiles. It automatically changes the /etc/nsswitch.conf configuration file, and configuration files in the /etc/pam.d/ and /etc/dconf/db/distro.d/ directories, as needed. For more information, see the authselect(8) and authselect-migration(7) manual pages.

Using separate disk partitions for OS and user data can prevent a "file system full" error from impacting the operation of a server. For example, you can create separate partitions for /home, /tmp, /oracle, and so on.

Establishing disk quotas can prevent a user from filling up a file system (intentionally or not) and therefore denying access to other users.

To prevent the OS files and utilities from being altered during an intrusion, you can mount the /usr file system with read-only permissions. If you need to update any RPMs on the file system, use the -o remount,rw option with the mount command to remount /usr for both read and write access. After performing the update, you can use the -o remount,ro option to return the /usr file system to read-only mode.

To limit user access to non-root local file systems such as /tmp or removable storage partitions, you can specify the -o noexec, nosuid, nodev options to mount. These options prevent the execution of binaries (but not scripts), prevent the setuid bit from having any effect, and prevent the use of device files.

Unowned files and directories can be associated with a deleted user account, and that might indicate an error with software installation or removal, or they might a sign of an intrusion on the system. You can correct the permissions and ownership of the files and directories that you find, or remove them. Investigating and correcting the problem that led to their creation is considered good security practice.

To check for unowned files and directories on each file system, use the find command:

sudo find mount_point -mount -type f -nouser -o -nogroup -exec ls -l {} \;

Investigating any world-writable directory that's owned by a user other than a system user is considered good security practice. If the user can remove or change any file that other users write to the directory, you can correct the permissions and ownership of any directories that you find or remove them.

To check for world-writable directories on each file system, use the find command:

sudo find mount_point -mount -type d -perm /o+w -exec ls -l {} \;

If the setuid and setgid bits are set, an executable can perform a task that requires other rights, such as root privileges. However, buffer overrun attacks can still exploit those executables to run unauthorized code with the rights of the exploited process.

You can also use the find command to check for setuid and setgid executables.

sudo find path -type f \( -perm -4000 -o -perm -2000 \) -exec ls -l {} \;

The Secure Shell (SSH) provides protected, encrypted communication with other systems. As SSH is an entry point into the system, it's considered good security practice to disable it if it's not required.

You can edit the /etc/ssh/sshd_config file to restrict local access to the root user and remote access to certain users and groups by configuring the settings. You can also configure settings in the /etc/ssh/sshd_config file so that the SSH client automatically times out after of period of inactivity.

Disabling password-based authentication for SSH and to requiring public key authentication instead is considered good security practice. By doing this, you can limit access to users who own an authorized private key.

After making any changes to the configuration file, you must restart the sshd service for the changes to take effect.

For more information, see Oracle Linux: Connecting to Remote Systems With OpenSSH and the sshd_config(5) manual page.

Advanced Intrusion Detection Environment (AIDE) is an application that uses various tools to detect changes to particular files on a system and report on them so that you can maintain baseline file integrity and detect unauthorized changes and potential tootkits.

This tool is installed as follows:

sudo dnf install -y aide

When AIDE is installed, you can change the configuration in /etc/aide.conf. The configuration file is used to decide which files and directories are monitored by AIDE and also how logging and output are handled.

AIDE stores its current information about a system's configuration state in a database stored in the /var/lib/aide/aide.db. If you store a copy of this database file at an external location then you can replace it with a known safe state for AIDE when you perform an audit. If the file doesn't yet exist, you can create one for the current system state by running:

sudo aide --init

sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

When you have created a database, you can check file integrity at any time by running:

sudo aide --check

If no differences are found, AIDE returns the results with the following message:

AIDE found NO differences between database and filesystem. Looks okay!!

If you configure this tool to run as an automated cron job, then you can get regular reports to indicate changes to system configuration and state that could help with early intrusion detection.

See the aide(1) and aide.conf(5) manual pages for more information.

A chroot command changes the visible root directory for running processes and their children, so it can be used to run a program with a root directory other than /. The program can't see or access files outside of the configured directory tree. Such an artificial root directory is called a "chroot jail", and its purpose is to limit the directory access of malicious processes and hackers. The chroot jail locks down each process and any user ID that's using it so that all they can access is the directory in which the process is running. The process is also tricked into thinking that the directory in which it's running is the root directory.

For a chroot process to start successfully, you must populate the chroot directory with all required program files, configuration files, device nodes, and shared libraries at their expected locations relative to the level of the chroot directory.

The Linux kernel features some extra security mechanisms that enhance the security of a system. These mechanisms randomize the layout of the address space for a process or prevent code from being run in non-executable memory.

The kernel uses a ring buffer to surface messages for troubleshooting purposes, and these messages can be viewed by running the dmesg command.

Threat actors can use those messages to find exploits in the system, so it's considered good security practice to ensure that only users with root permissions can run the dmesg command.

On Oracle Linux 10 systems, access is restricted by default regardless of whether the system is running the Red Hat Compatible Kernel (RHCK) or the Unbreakable Enterprise Kernel (UEK) 8.

Since Oracle Linux 8, Oracle Linux provides a facility to set a system-wide cryptographic policy. Many applications implement cryptographic protocols to secure communications or to encrypt data. Historically, applications have maintained their own configuration of cryptographic policies in various ways, which meant that changing cryptographic policy across an entire system needed to be performed for each application and often the configuration method differed from application to application.

The ability to define a system-wide cryptographic policy that applications can hook into often reduces administrative overhead and simplifies the process. An administrator can configure the system-wide cryptographic policy and have confidence that most applications can use the same policy, by default.

Policies enable an administrator to configure:

• TLS/SSL (and DTLS) versions that are accepted
• Ciphersuites that are accepted and the preferred order
• Parameters that are accepted for certificates and key exchange, including:
  • the minimum acceptable size of parameters (DH,ECDH,RSA,DSA,ECDSA),
  • the acceptable elliptic curves (ECDH,ECDSA),
  • the acceptable signature hash functions.
• Other TLS options including safe-renegotiation

Most of the major cryptographic software on Oracle Linux is already configured to use the system-wide cryptographic policy by default. Applications that are configured to behave in this manner include important applications such as OpenSSH and bind, in addition to any applications that use the OpenSSL, GnuTLS, NSS, and libkrb5 libraries.

Configuring system-wide policy doesn't enforce behavior across the system. That policy provides a common configuration across a wide variety of applications. Any application that's not designed to use the system-wide policy continues to function according to the different policy configuration that it uses. Many applications also provide options to override the system-wide cryptographic policy if required. For example, OpenSSH provides options to set different cryptographic policies on the server and client applications, and commands such as wget and curl provide options to define a custom cipher selection and order by using the --ciphers option, effectively overriding the system-wide policy.

The system-wide policy defines the default cryptographic behavior within applications so that you can harden a system and remove insecure protocols to match your security requirements.

Oracle Linux includes the update-crypto-policies command that can be used to configure which cryptographic algorithms, ciphers, and protocols are enabled on a system for use by applications and services. That command can be used to either relax policy or to harden it further.

For more information on this tool and the applications that are affected by it, see the crypto-policies(7) and update-crypto-policies(8) manual pages.

Checking the system for unlocked user accounts often is considered good security practice, for example by using this command:

for u in $(awk -F: '{print $1}' /etc/passwd;); do sudo passwd -S "$u"; done | sort

The following output is displayed:

adm L 2025-01-29 0 99999 7 -1
bin L 2025-01-29 0 99999 7 -1
chrony L 2025-06-13 -1 -1 -1 -1
clevis L 2025-08-28 -1 -1 -1 -1
...

In the output from this command, the second field shows if a user account is locked (L), doesn't have a password (NP), or has a valid password (P). The third field shows the date on which the user last changed their password. The remaining fields show the minimum age, maximum age, warning period, and inactivity period for the password and extra information about the password's status. The unit of time is days.

You can use the passwd command to set passwords on any accounts that aren't protected.

To lock unused accounts, use the passwd -l command. You can also use the userdel command to remove the accounts entirely.

For more information, see the passwd(1) and userdel(8) manual pages.

To specify how users' passwords are aged, edit the settings in the /etc/login.defs file that are described in the following table.

For more information, see the login.defs(5) manual page.

To change the length of time a user's account can be inactive before it's locked, use the usermod command. For example, you would set the inactivity period to 30 days as follows:

sudo usermod -f 30 username

To change the default inactivity period for new user accounts, use the useradd command:

sudo useradd -D -f 30

A value of -1 specifies that user accounts are never locked because of inactivity.

For more information, see the useradd(8) and usermod(8) manual pages.

To verify that no user accounts other than root have a user ID of 0, you would use the following command:

sudo awk -F":" '$3 == 0 { print $1 }' /etc/passwd

The following is the output of the previous command:

root

If you install software that creates a default user account and password, it's considered good security practice to change the vendor's default password immediately. Centralized user authentication using an LDAP implementation such as OpenLDAP can centralize user authentication and management tasks, and also reduce the risks arising from unused accounts or accounts without a password.

By default, an Oracle Linux 10 system is configured to prevent users from signing in directly as root. If a root user hasn't been created during the initial system installation, sign in as a named user and then use either the su or sudo command to perform tasks as the root user so that system accounting can trace the original username of any user who performs a privileged administrative action. To grant certain users authority to perform specific administrative tasks by using the sudo command, use the visudo command to configure the /etc/sudoers file.

For example, the following entry grants the user user1 the same privileges as root when using the sudo command, but defines a limited set of privileges to user2 so that they can run commands such as systemctl, rpm, and dnf:

user1           ALL=(ALL)       ALL
user2           ALL= SERVICES, SOFTWARE

For more information about setting up user accounts and authentication, see Oracle Linux 10: Setting Up System Users and Authentication.

If you follow traditional digital identity policies, the Pluggable Authentication Modules (PAM) feature can be used to enforce strong user authentication and password policies, including rules that decide password complexity, length, age, expiration, and the reuse of previous passwords. You can configure PAM to block user access after too many failed login attempts, after normal working hours, or if too many concurrent sessions are open. Note that some of these policies are no longer considered helpful for security as they can lead users to implement their own poor security practices when storing passwords or when renewing. See https://pages.nist.gov/800-63-3/sp800-63-3.html for more information.

PAM is highly customizable by its use of different modules with customizable parameters. For example, the default password integrity checking module pam_pwquality.so tests password strength. The PAM configuration file (/etc/pam.d/system-auth) contains the following default entries for testing a password's strength:

password    requisite    pam_pwquality.so local_users_only retry=3 authtok_type= enforce_for_root
password    requisite    pam_pwhistory.so use_authtok enforce_for_root remember=4
password    sufficient   pam_unix.so sha512 shadow use_authtok enforce_for_root remember=4
password    sufficient   pam_sss.so use_authtok
password    required     pam_deny.so

The line for pam_pwquality.so defines that a user gets three tries to choose a good password. From the module's default settings, the password length must a minimum of six characters, of which three characters can't be the same as a previous password. The module only tests the quality of passwords for users who are defined in the /etc/passwd file.

The line for pam_unix.so specifies that the module tests the old password that was specified in the stack before prompting for a new password and uses the SHA-512 password hashing and the /etc/shadow file to decide access. Note that pam_pwquality will have performed such checks for users that have been defined in the /etc/passwd file.

The line for pam_pwquality.so specifies that a user is allowed three tries to select a good password, with a minimum of eight characters, of which five characters must be different from the previous password, and which must contain at least one uppercase letter, one lowercase letter, one numeric digit, and one special character.

The line for pam_unix.so specifies that the module doesn't perform password checking, uses SHA-512 password hashing and the /etc/shadow file, and saves information about the previous five passwords for each user in the /etc/security/opasswd file.

For more information, see the pam_deny(8), pam_pwquality(8), and pam_unix(8) manual pages.

The authselect command can be used to switch between system authentication profiles. It automatically changes the /etc/nsswitch.conf configuration file, and configuration files in the /etc/pam.d/ and /etc/dconf/db/distro.d/ directories, as needed. For more information, see the authselect(8) and authselect-migration(7) manual pages.

Using separate disk partitions for OS and user data can prevent a "file system full" error from impacting the operation of a server. For example, you can create separate partitions for /home, /tmp, /oracle, and so on.

Establishing disk quotas can prevent a user from filling up a file system (intentionally or not) and therefore denying access to other users.

To prevent the OS files and utilities from being altered during an intrusion, you can mount the /usr file system with read-only permissions. If you need to update any RPMs on the file system, use the -o remount,rw option with the mount command to remount /usr for both read and write access. After performing the update, you can use the -o remount,ro option to return the /usr file system to read-only mode.

To limit user access to non-root local file systems such as /tmp or removable storage partitions, you can specify the -o noexec, nosuid, nodev options to mount. These options prevent the execution of binaries (but not scripts), prevent the setuid bit from having any effect, and prevent the use of device files.

Unowned files and directories can be associated with a deleted user account, and that might indicate an error with software installation or removal, or they might a sign of an intrusion on the system. You can correct the permissions and ownership of the files and directories that you find, or remove them. Investigating and correcting the problem that led to their creation is considered good security practice.

To check for unowned files and directories on each file system, use the find command:

sudo find mount_point -mount -type f -nouser -o -nogroup -exec ls -l {} \;

Investigating any world-writable directory that's owned by a user other than a system user is considered good security practice. If the user can remove or change any file that other users write to the directory, you can correct the permissions and ownership of any directories that you find or remove them.

To check for world-writable directories on each file system, use the find command:

sudo find mount_point -mount -type d -perm /o+w -exec ls -l {} \;

If the setuid and setgid bits are set, an executable can perform a task that requires other rights, such as root privileges. However, buffer overrun attacks can still exploit those executables to run unauthorized code with the rights of the exploited process.

You can also use the find command to check for setuid and setgid executables.

sudo find path -type f \( -perm -4000 -o -perm -2000 \) -exec ls -l {} \;

The Secure Shell (SSH) provides protected, encrypted communication with other systems. As SSH is an entry point into the system, it's considered good security practice to disable it if it's not required.

You can edit the /etc/ssh/sshd_config file to restrict local access to the root user and remote access to certain users and groups by configuring the settings. You can also configure settings in the /etc/ssh/sshd_config file so that the SSH client automatically times out after of period of inactivity.

Disabling password-based authentication for SSH and to requiring public key authentication instead is considered good security practice. By doing this, you can limit access to users who own an authorized private key.

After making any changes to the configuration file, you must restart the sshd service for the changes to take effect.

For more information, see Oracle Linux: Connecting to Remote Systems With OpenSSH and the sshd_config(5) manual page.

Advanced Intrusion Detection Environment (AIDE) is an application that uses various tools to detect changes to particular files on a system and report on them so that you can maintain baseline file integrity and detect unauthorized changes and potential tootkits.

This tool is installed as follows:

sudo dnf install -y aide

When AIDE is installed, you can change the configuration in /etc/aide.conf. The configuration file is used to decide which files and directories are monitored by AIDE and also how logging and output are handled.

AIDE stores its current information about a system's configuration state in a database stored in the /var/lib/aide/aide.db. If you store a copy of this database file at an external location then you can replace it with a known safe state for AIDE when you perform an audit. If the file doesn't yet exist, you can create one for the current system state by running:

sudo aide --init

sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

When you have created a database, you can check file integrity at any time by running:

sudo aide --check

If no differences are found, AIDE returns the results with the following message:

AIDE found NO differences between database and filesystem. Looks okay!!

If you configure this tool to run as an automated cron job, then you can get regular reports to indicate changes to system configuration and state that could help with early intrusion detection.

See the aide(1) and aide.conf(5) manual pages for more information.

A chroot command changes the visible root directory for running processes and their children, so it can be used to run a program with a root directory other than /. The program can't see or access files outside of the configured directory tree. Such an artificial root directory is called a "chroot jail", and its purpose is to limit the directory access of malicious processes and hackers. The chroot jail locks down each process and any user ID that's using it so that all they can access is the directory in which the process is running. The process is also tricked into thinking that the directory in which it's running is the root directory.

For a chroot process to start successfully, you must populate the chroot directory with all required program files, configuration files, device nodes, and shared libraries at their expected locations relative to the level of the chroot directory.