Red Hat Security: Linux in Physical, Virtual, and Cloud
This course is now legacy content
This course is using an outdated version of the technology and is now considered to be Legacy content. It will be removed from our catalog on June 28, 2024. Please be sure to complete your course and finish any remaining labs before that date. We recommend moving to version 9.2, which is the latest version currently available.
Objectives
After completing this section, students should be able to implement basic recommended practices to improve the security of a server.
Baseline Standard Operating Environment
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 by including it you are increasing your risk needlessly.
Red Hat's recommended practice is to create a standard operating environment (SOE). The SOE is a standardized baseline installation that consists only of the software packages required for all 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, if you are installing from the DVD media, take the opportunity to limit the installation to include only the minimum required software. If additional packages become necessary, you can add them to the system later.
Manual Installations
During installation, to specify which packages to install, click Software Selection on the Installation Summary page. The package groups are organized into Base Environments. These environments are predefined sets of packages with a specific purpose. You can only choose one base environment at installation time.
The predefined environments and add-ons allow you to customize your system, but in a manual installation, there is no way to select individual packages to install. If you are not sure which packages to install, Red Hat recommends that you choose Minimal Install.
A minimal installation only installs a basic version of Red Hat Enterprise Linux with a minimal amount of additional software. This substantially reduces the chance of the system being affected by a vulnerability. After the system is installed and you log in for the first time, you can use the Yum package manager to install any additional software.
Kickstart Installation
Kickstart installations offer a means to automate the installation process, either partially or fully. Kickstart files contain all the information required by the installation program, such as what time zone you want the system to use, how the drives should be partitioned, and which packages should be installed. Providing a prepared Kickstart file when the installation begins allows you to perform the installation automatically, without need for any intervention from the user. This is especially useful when deploying Red Hat Enterprise Linux on a large number of systems at once.
Automating the installation with a Kickstart file allows for a much higher degree of control over installed packages.
You can specify environments, groups, and individual packages in the %packages section of the Kickstart file.
Securing Services
A server typically runs a number of processes that are not associated with a terminal in order to provide various support functions for the system and local or remote programs and users. These processes are called daemons.
Red Hat Enterprise Linux 7 includes a number of daemons that act as network services. If a daemon acts as a network service, its processes listen for connections on one or more network ports. Each of these services should be treated as a potential risk for attack.
Understanding Potential Risks to Services
Network services can pose many risks for Linux systems. It is important to understand and be familiar with common attacks such as the following:
- Denial of Service Attacks (DoS)
A denial of service attack floods the service with requests and can render a system unusable as it tries to log and answer each request.
- Distributed Denial of Service Attack (DDoS)
Similar to a DoS attack but DDoS uses multiple compromised machines (often numbering in the thousands) to direct a coordinated attack on a service, flooding it with requests and making it unusable.
- Script Vulnerability Attacks
When a server uses scripts to execute server-side actions, such as 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 unprivileged ports, such as ports 1 through 1023, must start either with administrative privileges or the CAP_NET_BIND_SERVICE capability 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, an attacker could gain access to the system as the user running the daemon. Because exploitable buffer overflows exist, crackers use automated tools to identify systems with vulnerabilities, and when they have gained access, they use automated rootkits to maintain their access to the system.
To promote strong security measures, most network services installed with Red Hat Enterprise Linux 7 are turned off by default.
Notable exceptions are services such as cups, the default print server, and sshd, the OpenSSH server.
Any network service is potentially a security risk, which is why turning off unused services is so important.
Determining which network services are available to start at boot time is not enough. You should also determine which ports are open and listening.
Use the ss utility to list open ports in the listening state.
The -tlw options display TCP sockets, listening sockets, and raw sockets respectively.
Raw sockets are used to receive packets of a type that the kernel does not explicitly support.
[root@demo ~]#ss -tlwNetid 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
Some systems may have the older netstat command installed as an alternative to ss.
However, ss is part of the modern iproute package which is included in a minimal installation as part of the Core package group, while netstat is part of the earlier net-tools package which is not always available.
The netstat command also takes slightly different options.
Whether or not to leave services such as these running is often determined by your environment. However, it is best to use common sense and avoid taking any risks. 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 so important to regularly update packages associated with any network service.
Configuring SSH Key-based Authentication
Users can authenticate SSH logins without a password by using public key authentication. SSH allows users to authenticate using a private-public key scheme. This means that two keys are generated, a private key and a public key. The private key file is used as the authentication credential, and like a password, must be kept secret and secure. The public key is copied to systems the user wants to log in to, and is used to verify the private key. The public key does not need to be secret. An SSH server that has the public key can issue a challenge that can only be answered by a system holding your private key. As a result, you can authenticate using the presence of your key. This allows you to access systems in a way that does not require typing a password every time, but is still secure.
Generating SSH Keys
Use the ssh-keygen command to generate a key pair.
This generates the private key ~/.ssh/id_rsa and the public key ~/.ssh/id_rsa.pub.
During key generation, you are prompted to enter a passphrase. This passphrase is required to access your private key. In the event the private key is stolen, it is very difficult for someone other than the issuer to use it when protected with a passphrase.
You should protect your private key with a passphrase because the key allows access to destination machines. However, this means that the passphrase must be entered every time the key is used, which means the authentication process requires a password. To avoid entering a passphrase every time, you can use the ssh-add command at the start of a session 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.
Use the ssh-keygen command to generate a public-private key pair:
[user@demo ~]$ssh-keygenGenerating public/private rsa key pair.Enter file in which to save the key (/home/user/.ssh/id_rsa):EnterCreated directory '/home/user/.ssh'.Enter passphrase (empty for no passphrase):passphraseEnter same passphrase again:Your identification has been saved in /home/user/.ssh/id_rsa. Your public key has been saved in /home/user/.ssh/id_rsa.pub. The key fingerprint is: SHA256:BYE3jBXru0EVeXhAAigBFsgj9622lYyTZDhIVCqkGyk user@demo The key's randomart image is: +---[RSA 2048]----+ |=*+o ..**+++ | |*=+ . o ++o.o | |E+.+ . ...oo | |+oo + .. o | |. + = .S | | * +. . | | . + o | | . o | | . | +----[SHA256]-----+passphrase
When the SSH keys have been generated, they are stored by default in your home directory. Permissions should be 600 on the private key and 644 on the public key.
[user@demo ~]$ls -l /user/home/.sshtotal 8 -rw-------. 1 user user 1675 Aug 2 18:59 id_rsa -rw-r--r--. 1 user user 396 Aug 2 18:59 id_rsa.pub
Use the ssh-copy-id command to copy the public key to the destination system. Key-based authentication can now be used to authenticate to the destination system.
[user@demo ~]$ssh-copy-id user@remote/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/user/.ssh/id_rsa.pub" The authenticity of host 'remote (172.25.250.N)' can't be established. ECDSA key fingerprint is SHA256:BMdnasLF5CBGg42Dx77nuXodXdI9dKoEBQGFK5O0HRI. ECDSA key fingerprint is MD5:9e:a8:ec:0c:86:d2:70:34:ef:5a:94:15:6d:48:73:db.Are you sure you want to continue connecting (yes/no)?yes/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keysuser@remotes's password:Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'user@remote'" and check to make sure that only the key(s) you wanted were added.password
When you log in to the remote server as user, you are not required to provide a password.
[user@demo ~]$ssh user@remoteLast login: Wed Aug 1 16:26:59 2018 from demo.lab.example.com[user@remote ~]$
Customizing Your SSH Service Configuration
If your environment does not require logging in as the root user, you should consider modifying the SSH service configuration to disable this.
You can determine which users have root privileges after they log in as regular users.
Typically, the OpenSSH server configuration does not require modification, however, additional security measures are available.
Edit the /etc/ssh/sshd_config file to customize the OpenSSH server configuration.
Prohibiting the root User from Logging in Using SSH
As a security measure, it is advisable to prohibit the root user from directly logging in to the system using ssh.
Direct SSH authentication to systems by the root user presents the following security risks:
The
rootuser exists on every Linux system by default, so a potential attacker only has to guess the password, instead of a valid user name and password combination.The
rootuser has unrestricted privileges.
Modify the /etc/ssh/sshd_config file on the OpenSSH server to prohibit logging in as the root user.
The configuration file contains one keyword-argument pair per line.
Many of the keyword-argument pairs are commented out by default.
#PermitRootLogin yes
Remove the leading comment from the keyword and change the argument value to no to enable the option.
PermitRootLogin no
Reload the sshd service.
[root@demo ~]#systemctl reload sshd
Note
In general it is not a good practice to allow direct logins as root to a system.
It is better to make administrators log in to an unprivileged account and then switch to the root account using a tool such as sudo.
There are a number of reasons for this.
One reason is that root is a well-known account that has administrative privileges on the system.
If a remote attacker can successfully get an interactive shell as root, they have full or nearly-full control of the server.
If password authentication is enabled for root, attackers may try brute-force password guessing in an attempt to log in.
Even if password authentication is not enabled, that is not the only attack they might attempt.
A second reason is that if an attacker has to break into an unprivileged user account and use sudo or su to escalate privileges, it makes attacks on the root account more difficult.
It may provide additional audit logs of the attack or enable you to implement defensive measures with sudo or SELinux confined users.
For example, you can require most administrators to use sudo with their own credentials to get an interactive shell as root.
Then you can limit knowledge of the root password to administrators who may need it to log in on the local console for emergency purposes.
This practice also leaves an audit log of who logged in as root at what time.
Finally, it requires attackers to determine which unprivileged users exist that might have that level of sudo access.
While none of these are perfect defenses, they do increase the difficulty of a successful attack.
Prohibiting Password Authentication Using SSH
SSH password authentication is a potential vulnerability that can be avoided. Allowing only SSH key-based authentication to your account is one way to minimize security risks. Some advantages of using only SSH key-based authentication are listed below:
Eliminates exposure to password-based brute-force attacks
Less effort to initiate remote shell access after the initial setup
To prohibit password-based authentication for all users, modify the /etc/ssh/sshd_config file on the OpenSSH server.
The default configuration is to allow password-based authentication.
PasswordAuthentication yes
Change the argument value to no to prevent password-based authentication.
PasswordAuthentication no
Reload the sshd service.
[root@demo ~]#systemctl reload sshd
Important
If you disable password authentication for logins using ssh, you must make sure that permitted remote SSH users have another way to authenticate to the server.
If you are using SSH public key authentication, you must be able to populate the user's ~/.ssh/authorized_keys file.
This could be through manual entry after a local login, configuration by the local root user, or through some other provisioning mechanism.
Another approach would be to configure the system to use Kerberos authentication, which would require less user configuration on each SSH server after it has been set up.
Escalating User Privileges
As a system administrator, you perform certain tasks with administrative access.
Directly accessing the system as the root user is potentially dangerous and could compromise your entire computing infrastructure.
Programs such as su and sudo allow specific users to perform tasks which would normally be available only to the root user while maintaining a higher level of control and system security.
Using the su Command to Gain Privileges
When you execute the su command, you are prompted for the root user's password and, after authentication, are given a root shell prompt.
After you have logged in using the su command, you have root user privileges, which means you have absolute administrative access to the system.
Note that this access is still subject to the restrictions imposed by SELinux, if it is enabled.
Note that as the root user you can use the su command to change to any other user on the system without being prompted for a password.
There is a significant difference between using the su command with no options and the su - command with the dash option.
- su
Switches to the target user (which is
rootby default), but provides a normal shell with the same environment as the user who invoked the su command.[user@demo ~]$suPassword:root's password[root@demo student]#whoami; pwd; echo $PATHroot /home/student /usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/student/.local/bin:/home/student/bin[root@demo student]#- su -
Switches to the target user and invokes a login shell based on the target user's environment. A login shell resets most environment variables, including the target user's PATH.
[user@demo ~]$su -Password:root's password[root@demo ~]#whoami; pwd; echo $PATHroot /root /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin[root@demo ~]#
Using the sudo Command to Gain Privileges
The sudo command offers another approach to giving users administrative access.
When trusted users precede an administrative command with sudo, they are prompted for their own password.
Then, when they are authenticated, assuming that the administrative command is permitted, the administrative command is executed as if they were the root user.
The basic format of the sudo command is as follows:
[user@demo ~]$sudocommand
In the above example, command would be replaced by a command 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 sudo configuration file, /etc/sudoers.
To give someone full administrative privileges to a user account named user, type visudo and add the following line to the user privilege specification section:
user ALL=(ALL) ALL
In the above 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 --login options.
Similar to the su - command, sudo -i changes to the root user's home directory and opens an interactive login shell based on the root user's environment variables.
The big difference is that because you have an entry in the /etc/sudoers file you do not need to know the root password.
[user@demo ~]$sudo -iPassword:user's password[root@demo ~]#whoami; pwd; echo $PATHroot /root /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin[root@demo ~]#
Important
One subtle difference between su, su -, and sudo is in how the user's PATH environment variable is set.
su changes the current user but does not update the
PATHvariable.su - acts like a login shell and uses the new user's
dotfiles to reset the currentPATHvariable to that used when the user logs in.sudo resets the
PATHvariable based on thesecure_pathdirective in the/etc/sudoersfile, which may then be modified based on what command sudo is executing. For example, thePATHvariable that is the result of sudo -i may be different from the result of sudo su -. The case of sudo -i is discussed in more detail in thesudoers(5) man page.
References
ssh-keygen(1), ssh-copy-id(1), ssh-agent(1), ssh-add(1), sudo(8), visudo(8), and su(1) man pages
For more information, refer to the Hardening Your System With Tools and Services chapter in the Red Hat Enterprise Linux 7 Security Guide at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/security_guide/#chap-Hardening_Your_System_with_Tools_and_Services
The Software Selection chapter in the Red Hat Enterprise Linux 7 Installation Guide at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/installation_guide/#sect-package-selection-x86
The Gaining Privileges chapter in the Red Hat Enterprise Linux 7 System Administrator's Guide at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/system_administrators_guide/#chap-Gaining_Privileges
