The security of your RHEL system is paramount in today’s threat landscape. Unauthorized access can lead to data breaches, system compromise, and financial loss. This article delves into critical security measures mandated by RHEL Mandatory Baseline Security Standards (MBSS) to protect your system from vulnerabilities. By implementing these controls, you significantly reduce the risk of unauthorized access and bolster your overall system security.

Understanding the Risks

Before diving into the solutions, let’s understand the potential threats:

• Brute force attacks: Unauthorized attempts to gain access by repeatedly guessing passwords.
• Unauthorized access to single-user mode: Exploiting system vulnerabilities to gain root privileges without proper authentication.
• Weak password policies: Using simple or easily guessable passwords.
• Unrestricted SSH access: Allowing unauthorized users to connect to the system.

The Mandatory Controls

To mitigate these risks, RHEL MBSS mandates the following controls:

Single-User Mode Security

• Require authentication: Enforce password protection for accessing single-user mode. This prevents unauthorized users from bypassing normal login procedures and gaining root privileges.

SSH Configuration

• Limit login attempts: Configure SSH to allow a maximum of three login attempts per connection. This thwarts brute force attacks by preventing excessive password guessing.
• Disable host-based authentication: Eliminate the reliance on trusted hosts for authentication, enhancing security.
• Prohibit root login: Prevent direct root login via SSH to reduce the attack surface.
• Enforce strong password policies: Disallow empty passwords and implement robust password requirements.
• Implement idle session timeout: Automatically terminate idle SSH sessions to prevent unauthorized access.
• Restrict login grace period: Limit the time for successful authentication to minimize the window of opportunity for attackers.
• Control SSH access: Carefully define which users and groups can access the system via SSH, using AllowUsers, AllowGroups, DenyUsers, and DenyGroups.
• Disable non-login system accounts: Prevent unauthorized access through unused system accounts.

Why These Controls Matter

By diligently implementing these measures, you create a fortified defense against common attack vectors. These controls:

• Deter brute force attacks: Limiting login attempts and enforcing strong password policies makes it significantly harder for attackers to crack passwords.
• Protect against unauthorized access: Disabling root login, restricting SSH access, and securing single-user mode prevent unauthorized individuals from gaining control of your system.
• Minimize damage from successful attacks: Idle session timeouts and login grace time limits reduce the potential impact of a successful attack.

Applicability to RHEL-Based Distributions

The security measures outlined in this article are primarily designed for Red Hat Enterprise Linux (RHEL) systems. However, due to their shared codebase and similar configurations, these measures are directly applicable to a wide range of RHEL-based distributions.

CentOS, Rocky Linux, AlmaLinux, and Oracle Linux are direct derivatives of RHEL, inheriting its core security architecture and configuration options. This close relationship ensures that the security best practices established for RHEL are highly relevant to these distributions. As a result, most of the security measures discussed in this article can be applied directly to these systems with minimal adjustments.

Scientific Linux, while also based on RHEL, might have some variations in packaging and configuration. However, the underlying security principles remain consistent. It’s essential to consult the specific documentation of Scientific Linux for any unique security considerations or additional hardening steps.

ClearOS, built on a RHEL foundation, is a specialized operating system tailored for small and medium-sized businesses. While it shares many security fundamentals with RHEL, its focus on server management and network services introduces specific security challenges. While the core security principles discussed in this article are applicable, there might be additional security measures required to address the unique characteristics of ClearOS. It’s crucial to refer to the ClearOS documentation for comprehensive security guidance.

It’s important to note that while these distributions share a common foundation, minor configuration differences or additional security features might exist. Therefore, it’s essential to consult the specific documentation of your chosen distribution for any unique hardening requirements.

By following the general guidelines presented here and incorporating any distribution-specific recommendations, you can effectively enhance the security of your RHEL-based system.

Details List of all Mandatory Authentication Baseline Security for Red Hat Enterprise Linux (RHEL)

• Ensure authentication required for single-user mode: Single user mode (rescue mode) is used for recovery when the system detects an issue during boot or by manual selection from the bootloader. Requiring authentication in single user mode (rescue mode) prevents an unauthorized user from rebooting the system into single user to gain root privileges without credentials.
• Ensure SSH MaxAuthTries is set to 3 or less: The MaxAuthTries parameter specifies the maximum number of authentication attempts permitted per connection. When the login failure count reaches half the number, error messages will be written to the syslog file detailing the login failure. Setting the MaxAuthTries parameter to a low number will minimize the risk of successful brute force attacks to the SSH server.
• Ensure SSH HostbasedAuthentication is disabled: The HostbasedAuthentication parameter specifies if authentication is allowed through trusted hosts via the use of .rhosts, or /etc/hosts.equiv, along with successful public key client host authentication. This option only applies to SSH Protocol Version 2. Even though the .rhosts files are ineffective if support is disabled in /etc/pam.conf, disabling the ability to use .rhosts files in SSH provides an additional layer of protection.
• Ensure SSH root login is disabled: The PermitRootLogin parameter specifies if the root user can log in using ssh(1). The default is no.
• Ensure SSH PermitEmptyPasswords is disabled: The PermitEmptyPasswords parameter specifies if the SSH server allows login to accounts with empty password strings. Disallowing remote shell access to accounts that have an empty password reduces the probability of unauthorized access to the system.
• SSH Idle Timeout is restricted – ClientAliveInterval is configured between 1 and 900 and ClientaliveCountMax is configured to be 3 or less: The two options ClientAliveInterval and ClientAliveCountMax control the timeout of ssh sessions. When the ClientAliveInterval variable is set, ssh sessions that have no activity for the specified length of time are terminated. When the ClientAliveCountMax variable is set, sshd will send client alive messages at every ClientAliveInterval interval. When the number of consecutive client alive messages are sent with no response from the client, the ssh session is terminated. For example, if the ClientAliveInterval is set to 15 seconds and the ClientAliveCountMax is set to 3, the client ssh session will be terminated after 45 seconds of idle time.
• SSH LoginGraceTime is set to one minute or less: The LoginGraceTime parameter specifies the time allowed for successful authentication to the SSH server. The longer the Grace period is the more open unauthenticated connections can exist. Like other session controls in this session the Grace Period should be limited to appropriate organizational limits to ensure the service is available for needed access. Setting the LoginGraceTime parameter to a low number will minimize the risk of successful brute force attacks to the SSH server. It will also limit the number of concurrent unauthenticated connections. This one is secondary, not mandatory. But, I’d still recommend doing it.
• Ensure SSH access is limited: There are several options available to limit which users and group can access the system via SSH. It is recommended that at least one of the following options be leveraged:
  • AllowUsers: The AllowUsers variable gives the system administrator the option of allowing specific users to ssh into the system. The list consists of space separated user names. Numeric user IDs are not recognized with this variable. If a system administrator wants to restrict user access further by only allowing the allowed users to log in from a particular host, the entry can be specified in the form of user@host.
  • AllowGroups: The AllowGroups variable gives the system administrator the option of allowing specific groups of users to ssh into the system. The list consists of space separated group names. Numeric group IDs are not recognized with this variable.
  • DenyUsers: The DenyUsers variable gives the system administrator the option of denying specific users to ssh into the system. The list consists of space separated user names. Numeric user IDs are not recognized with this variable. If a system administrator wants to restrict user access further by specifically denying a user’s access from a particular host, the entry can be specified in the form of user@host.
  • DenyGroups: The DenyGroups variable gives the system administrator the option of denying specific groups of users to ssh into the system. The list consists of space separated group names. Numeric group IDs are not recognized with this variable.
• Ensure system accounts are non-login: There are a number of accounts provided with RHEL that are used to manage applications and are not intended to provide an interactive shell.

Conclusion

Adhering to RHEL MBSS guidelines is essential for maintaining a secure system. By implementing the outlined controls, you take proactive steps to safeguard your RHEL-based system (including CentOS, Rocky Linux, AlmaLinux, Oracle Linux, Scientific Linux, and ClearOS) from various threats. Remember that security is an ongoing process. Regularly review and update your security measures to stay ahead of evolving threats.

Invest the time and effort to secure your system. It’s a crucial step in protecting your organization’s valuable data and resources.

Additional Considerations

• Regular security audits: Conduct periodic security assessments to identify and address vulnerabilities.
• Keep software up-to-date: Apply patches and updates promptly to fix security issues.
• User education: Train users about security best practices to prevent social engineering attacks.
• Incident response plan: Develop a plan to respond to security incidents effectively.

By combining these measures, you can significantly enhance the security posture of your RHEL-based system.

roosho Senior Engineer (Technical Services)

I am Rakib Raihan RooSho, Jack of all IT Trades. You got it right. Good for nothing. I try a lot of things and fail more than that. That's how I learn. Whenever I succeed, I note that in my cookbook. Eventually, that became my blog. 

See Full Bio

IT Support Specialist Server and Storage Specialist Dell MidRange Storage Solutions Specialist