Red Hat Linux Security Hardening Checklist

Red Hat Enterprise Linux (RHEL) is the second most used server OS, behind Microsoft Server, according to the report, “Worldwide Server Operating Environments Market Shares, 2018: Overall Market Growth Accelerates”. The servers are used to store sensitive information, send emails or serve another business purpose.

The average cost of a data breach is USD 4.24 million, according to the 2021 IBM report for data breaches. Additionally to this financial cost, the brand damage can be devastating.

Server security hardening is a process that can address vulnerabilities and unsecure configurations, thus reducing the security risks. It is also one of the key steps to achieve security compliance, alongside network and physical security, regular assessment processes and other requirements.

In this article, I present some of the most important steps for hardening a RHEL 7 system.

Prior to hardening a system, an assessment of the system security posture can be done to identify what does, or does not need to be addressed. A Nessus credentialed compliance scan using the CIS benchmark for RHEL 7 would achieve this.

Note that not all security gaps should be addressed. 
For example, in general you should follow CIS recommendation to disable ip forwarding so the server can not be used to route traffic. A threat example is an attacker using this system to route packets to a destination, thus bypassing a firewall. If this system is exposed to internet (an application server) the risk of this threat increases.

However, if your server should act as a router, you can safely ignore this check fail.

1. Documentation

Information about the server that should be documented include its exposed network interfaces and connected networks, services provided and remote services it communicates with and on which port.

Knowledge sharing is important to facilitate change planning, inter-department communication, a problem or downtime investigation, and facilitate new hire onboarding.

2. Access Control

Use strong passwords

This applies to both local and domain user accounts. Passwords are vulnerable to brute force attacks. In 2021, compromised credentials accounted for 20% of data breaches. Passwords are sought after by attackers to either gain initial access to a system, or elevate their privilege if they already have access.

You should follow industry recommendations for password length, complexity and rotation.

The National Institute of Science and Technology (NIST) recommends to use long passphrases that are easy to remember for the end-user, and to not rotate them. The reasoning is that length is more secure than complexity, and rotating a password quarterly have been shown to be counter productive as end-user fatigue leads some of them to adopt poor password hygiene.

Although, if you aim to achieve PCI compliance, you should implement the PCI recommendations, which includes quarterly rotation.

Local accounts

The file /etc/passwd lists all local user accounts along with information such as whether they use an encrypted password, and if they have a login shell.

The root account should not be able to SSH. This can be configured in the sshd_config file by setting the PermitRootLogin directive to no. Also, it is preferred to not use a shared admin user, except for emergencies. For this, a local super user account should be created. In general, admin users should use their own domain user, for accountability purposes.

The only users that should have a bash are authorized users that need to login and perform tasks, or service accounts that need one for legitimate reasons, such as to authenticate to a remote system. Other users and service accounts should not be able to have a shell as they do not need one.

If an attacker compromises a service account that does not have a shell, they can not execute commands on the system to gather information or compromise the system further.

Integrate with an Identity Store

Domain accounts should be preferred over local accounts, except for the emergency privileged account mentioned in the previous section, and service users running long lived services (web application, database, etc.).

Employees with access to the server, and service accounts that do not fall in the above category should be created in a centralized identity store, such as Active Directory.

We do it so the management and policies applied to these accounts can be centralized.

Least privilege access

The principle of least privilege access states that any user, program, or process should have only the bare minimum privileges necessary to perform their function.

This is a major component of a security strategy, as it reduces the likelihood of escalation of privilege, following an unauthorized access.

In practice, this principle can be declined in many ways. I present 2 examples that need to be verified on every server:

Restrict privileged access

The sudo command provides fine granularity to provide users privileged access when and where needed. sudo’s configuration file, sudoers is used to achieve this. You should ensure that:

• Users who need privileged access, are granted the access without the need to switch to the root user. Their account should be provided with the permissions needed, so that we can keep accountability
• When privilege access is granted, it is restricted to only what is required. This access should be provided on a per program or per directory basis
• This privilege access management should be done at the group level. Users should then be added to these security groups
• Ensure a password is required to switch context to a privileged access

This list is not exhaustive.

Verify which user is running applications.

Run ps aux to see the list of running processes. Verify that applications are not running under the root account. Instead, they should have a dedicated service account with restricted access.

Host Based Firewall


The traffic from and to the server should be limited to only a defined whitelist of allowed connections. firewalld should be enabled and used for this purpose.

3. Backups

Ensure regular backups are scheduled. The backups should be stored offsite. Backups will ensure that your business will not fall on its knees in case a crippling attack such as a ransomware occurs.



4. Ensure only necessary services are running.

• Create the server with the “minimal installation” option so only the required packages will be later installed
• Do not install applications unless they serve a business or IT service
• Open only the required ports. Run netstat -ltnp in order to view the list of services listening, as well as the process running it thanks to the p option

Additionally, disable any unsecure network protocol. 
Telnet, HTTP, FTP should be disabled to force using the secure protocols HTTPS, SFTP, SSH etc. Communications should always be encrypted.

5. Monitoring

HIDS

You should install and configure a Host-based Intrusion Detection system (HIDS). Below are 2 example of its most important components:

• File Integrity Monitoring (FIM). An enterprise server is not a user laptop. It is configured once to serve a purpose and any change on it (new application, new user provided access etc.) should be planned and not occur on a daily basis. Unexpected changes to some files could indicate a malicious activity.

• Log Integrity Monitoring (LIM) is another important tool. You should configure it to choose files and processes to check. A file example could be the audit log file /var/log/audit/audit.log, that tracks security events such as account, group, and role changes.

  An example of process monitoring could be monitoring if a new port has been opened, see this example that uses OSSEC.

Centralized Logging and Alerting

All security logs should be forwarded to a centralized log management solution such as ELK Stack or Splunk. On this product, alerts should be configured to ensure proper actions are taken following certain events. Such alerts should be tailored to only notify when something unexpected, or suspicious is happening.

For example, the file /var/log/secure that contains the authentication and authorization logs should be monitored and all entries sent to the centralized log management product.

If you configure an alert to be fired anytime an entry is logged, you could be flooded with thousands of events related to expected end user and service account activity. You should define what is expected, then configure alerting for everything else. To achieve this, you can look at some of the event’s fields: 


• The event time,
• The event type:
  • A failed attempt to authenticate,
  • A failed attempt to become root privilege (“user is not in sudoers” message)
  • An account was locked
• The name of the user attempting to authenticate

6. Antivirus

You should install an antivirus solution on your server, specially if it is a file server that accepts clients connection to add/ removes files.

7. Vulnerability scan

Run a vulnerability scan and ensure that there are no vulnerabilities posing a risk before the server becomes live.

In conclusion, this article presented a checklist of some of the key components to look for when hardening a RHEL 7 system. It explained why each security measure is required, with examples of how we can detect an attack on our system thanks to some of these safeguards.