Red Hat Security: Linux in Physical, Virtual, and Cloud
Every additional software component on your system increases the chance that the system is subject to some security vulnerability. If that software is not used, then you are needlessly increasing your risk by including it.
Red Hat recommends creating a Standard Operating Environment (SOE). The SOE is a standardized baseline installation with only the required software packages for your server installations. When you develop applications to run in your SOE, you can ensure that they add only the components that they need and which the SOE does not supply.
When building a prototype SOE and you are installing from DVD or USB media, then include only the minimum required software. Alternatively, you can use RHEL Image Builder to create a custom SOE image from an existing installation. If additional packages become necessary, then you can add them to the system later.
To specify which packages to install, click on the page. The package groups are organized into . These environments are predefined sets of packages with a specific purpose. You can choose only one base environment at installation time.
You can customize your system by using the predefined environments and add-ons, but a manual installation does not provide individual packages to install. If you are not sure which packages to install, then Red Hat recommends that you choose .
A minimal installation installs a basic version of Red Hat Enterprise Linux with a minimal amount of additional software.
This installation substantially reduces the chance of a vulnerability affecting the system.
After the system is installed and you log in for the first time, you can use the dnf package manager to install any additional software.
Kickstart installations partially or fully automate the installation process. Kickstart files contain all the information that the installation program requires, such as what time zone you want the system to use, how the drives must be partitioned, and which packages must be installed. By providing a prepared Kickstart file when the installation begins, you can install automatically without any user intervention. This process is especially useful when deploying Red Hat Enterprise Linux on many systems at once.
Automating the installation with a Kickstart file enables much higher control over installed packages.
You can specify environments, groups, and individual packages in the %packages section of the Kickstart file.
A server typically runs many processes that are not associated with a terminal to provide various support functions for the system, users, and local or remote programs. These processes are called daemons.
Red Hat Enterprise Linux includes various daemons that act as network services. If a daemon acts as a network service, then its processes listen for connections on one or more network ports. Treat each of these services as a potential security risk.
Network services can pose many risks for Linux systems. You should be familiar with common attacks:
- Denial of Service Attacks (DoS)
A denial of service attack overwhelms the service with requests, and can render a system unusable as it tries to log and answer each request.
- Distributed Denial of Service Attacks (DDoS)
A DDoS attack is similar to a DoS attack, but a DDoS attack uses multiple compromised machines (which often number in the thousands) to direct a coordinated attack on a service, which overwhelms the service with requests and renders it unusable.
- Script Vulnerability Attacks
When a server uses scripts to execute server-side actions, which web servers commonly do, an attacker can target incorrectly written scripts. These script vulnerability attacks can lead to a buffer overflow condition or allow the attacker to alter files on the system.
- Buffer Overflow Attacks
Services that listen on privileged ports, such as ports 1 through 1023, must either be started with administrative privileges or the
CAP_NET_BIND_SERVICEcapability must be set for them. When a process is bound to a port and is listening on it, the privileges or the capability are often dropped. If the privileges or the capability are not dropped, and the application has an exploitable buffer overflow, then an attacker could access the system as the user that runs the daemon. Because exploitable buffer overflows exist, exploiters use automated tools to identify systems with vulnerabilities. When exploiters gain access, they use automated rootkits to maintain their access to the system.
To promote strong security measures, most network services that are installed with Red Hat Enterprise Linux 9 are turned off by default.
Notable exceptions are services such as the cups default print server and the sshd OpenSSH server.
Any network service is potentially a security risk, which is why turning off unused services is so important.
Identifying which network services are available to start at boot time is not enough. You must also determine which ports are open and listening.
Use the ss command to list open ports in the listening state.
The -tlw options display TCP sockets, listening sockets, and raw sockets, respectively.
Raw sockets receive packets of a type that the kernel does not explicitly support.
[root@host ~]# ss -tlw
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
tcp LISTEN 0 128 *:sunrpc *:*
tcp LISTEN 0 128 *:ssh *:*
tcp LISTEN 0 100 127.0.0.1:smtp *:*
tcp LISTEN 0 128 :::sunrpc :::*
tcp LISTEN 0 128 :::ssh :::*
tcp LISTEN 0 100 ::1:smtp :::*Note
On some systems, the deprecated netstat command might be installed instead of the ss command.
The netstat command is part of the earlier net-tools package, which is not always available.
The netstat command also takes slightly different options.
The ss command is part of the modern iproute package, which is included in a minimal installation as part of the Core package group.
Your environment often determines whether to leave services running. Network services that you think are secure can quickly become a security risk. Exploits for services are routinely discovered and patched, which is why it is important to regularly update packages that are associated with any network service.
When you use the ssh-keygen command to generate a key pair, you are prompted to enter a passphrase.
This passphrase encrypts the private key, and is required to decrypt the key for use.
Red Hat recommends protecting your private key with a passphrase, because it helps to prevent unauthorized access to machines that the key is registered to.
If the private key is stolen, then it is difficult for someone other than the issuer to use a passphrase-protected key.
To avoid the inconvenience of entering a passphrase every time, use the ssh-add command to provide your passphrase to the ssh-agent utility.
The ssh-agent utility stores the passphrase and provides it as needed while you remain logged in to your current session.
By default, the generated SSH keys are stored in your home directory.
You can specify a different file name or directory interactively, or by setting the ssh-keygen command -f option.
The private key permissions must be set to 600, and the public key permissions must be set to 644.
The ssh command automatically rejects keys with incorrect permissions.
Additionally, SELinux in Enforcing mode rejects ssh keys without the ssh_home_t context label.
[user@host ~]$ ls -lZ /user/home/.ssh
total 8
-rw-------. 1 user user unconfined_u:object_r:ssh_home_t:s0 2602 10:57 id_rsa
-rw-r--r--. 1 user user unconfined_u:object_r:ssh_home_t:s0 571 10:57 id_rsa.pubRed Hat Enterprise Linux 9 is configured to automatically reject root user login.
Earlier systems might not be configured to reject root user login by default.
If your environment contains earlier systems, then consider modifying the SSH service configuration on these systems to disable root login.
Red Hat recommends allowing login only for non-privileged users, and then allowing specific users to escalate privileges with the sudo or sudo -i commands.
Over time, Red Hat deprecates cryptographic ciphers when the ciphers become less secure. From this deprecation process, some legacy systems such as Red Hat Enterprise Linux 6 might become inaccessible. Legacy systems that do not support modern cryptographic standards require more modern systems to use earlier protocols to communicate. Although some earlier protocols are removed in modern systems, most of those protocols are disabled by system-wide cryptographic policies.
Cryptographic policies are lists of service and protocol combinations that define which combinations are permitted. Red Hat Enterprise Linux 9 has the following preconfigured cryptographic policies:
- LEGACY
The
LEGACYpolicy is more permissive and therefore less secure than theDEFAULTpolicy. TheLEGACYpolicy enables maximum compatibility with legacy systems.- DEFAULT
The
DEFAULTpolicy is suitable for modern standards. This policy aligns with most systems and also remains secure. TheNEXTpolicy is the same as theDEFAULTpolicy.- FUTURE
The
FUTUREpolicy is more restrictive than theDEFAULTpolicy, and is designed to have a high likelihood of withstanding near-future attacks. The policy might prevent communication with common systems that use weaker protocols.- FIPS
The
FIPSpolicy conforms to theFederal Information Processing Standard (FIPS) 140-2requirements, which might be required by law in some countries and sectors.
Red Hat recommends using the DEFAULT policy in most circumstances and using the LEGACY policy only when necessary.
The LEGACY policy might introduce security vulnerabilities by permitting outdated protocols.
You can verify the current cryptographic policy with the update-crypto-policies --show command.
Although this command returns the active cryptographic policy, it might not indicate whether all services are using the policy.
Because some long-running services might not restart when the policy is changed, Red Hat recommends rebooting a system after changing the cryptographic policy.
[user@host ~]$ update-crypto-policies --show
DEFAULTYou can verify that the current policy matches the generated policy files by using the update-crypto-policies --check command.
The command shows a discrepancy if the generated policy files are updated but the policy is not reapplied.
[user@host ~]$ update-crypto-policies --check
The configured policy matches the generated policyTo change the cryptographic policy, use the update-crypto-policies --set command.
This command applies a cryptographic policy, and restarts any known affected services.
The command requires administrative privileges.
[user@host ~]$ sudo update-crypto-policies --set LEGACY
sudo user@host:
Setting system policy to LEGACY
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.The update-crypto-policies command detects additional cryptographic policy files in the /etc/crypto-policies/policies/ directory.
You can copy an existing policy file in the /usr/share/crypto-policies/policies/ directory and modify it with a text editor.
A policy file contains a list of key-value pairs.
Each key is a type of protocol or policy.
The value is a list of algorithms that are enabled for the type.
The following example allows the AES-256-GCM and AES-256-CCM algorithms for the cipher type:
cipher = AES-256-GCM AES-256-CCM
You can use the type@subtype syntax to define subtypes.
You can also use an asterisk (*) to match multiple items, or prepend a hyphen (-) to disable an item.
The following example disables all CBC algorithms for the SSH subtype of the cipher type:
cipher@SSH = -*-CBC
As a system administrator, you perform certain tasks with administrative access.
Directly accessing the system as the root user is potentially dangerous and can compromise your entire computing infrastructure.
The sudo command allows specific users to perform tasks that would normally be available only to the root user, and also maintains a higher level of control and system security.
The sudo command offers an approach to give users administrative access.
When trusted users precede an administrative command with sudo, they are prompted for their own password.
Then, when the user is authenticated, and assuming that the administrative command is permitted, the administrative command executes as if they were the root user.
The format of the sudo command is as follows:
[user@host ~]$ sudo commandIn the preceding example, command would be replaced by a command that is normally reserved for the root user, such as mount.
Another advantage of the sudo command is that an administrator can allow different users access to specific commands based on their needs.
Use the visudo command to edit the /etc/sudoers configuration file.
To give administrative privileges to a user called user, type the visudo command and add the following line to the section on user privilege specification:
user ALL=(ALL) ALL
In the preceding example, a user named user can use sudo from any host and execute any command.
Use the sudo -i command to switch to the root user's login environment.
The -i option is an abbreviation for the --login options.
The sudo -i command changes to the root user's home directory and opens an interactive login shell based on the root user's environment variables.
Because you have an entry in the /etc/sudoers file, you do not need to know the root password.
[user@host ~]$sudo -iPassword:[root@host ~]#user's passwordwhoami; pwd; echo $PATHroot /root /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin [root@host ~]#
Important
The sudo command resets the PATH variable based on the secure_path directive in the /etc/sudoers file.
The PATH variable might then be modified based on which command sudo is executing.
The case of sudo -i is discussed in more detail in the sudoers(5) man page.
References
ssh-keygen(1), ssh-copy-id(1), ssh-agent(1), ssh-add(1), crypto-policies(7), update-crypto-policies(8), sudo(8), visudo(8), and su(1) man pages
For more information, refer to the Configuring Software Selection chapter in the Red Hat Enterprise Linux 9 Installation guide at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/performing_a_standard_rhel_9_installation/graphical-installation_graphical-installation#configuring-software-selection_configuring-software-settings
