Top 10 Red Hat Enterprise Linux 5 Security Checks

Top 10 Red Hat Enterprise Linux 5 Security Checks

Abstract shapeAbstract shape
Join 27,000+ cybersecurity newsletter subscribers

Despite crossing over the half-decade mark since its release, Red Hat Enterprise Linux (RHEL) 5 is still in widespread use—and will continue to be supported by Red Hat through November 30th 2020. Security enhancements in later versions of RHEL like improved Security Enhanced Linux (SELinux) and virtual machine security (i.e., Svirt) warrant a timely upgrade, but organizations unable to do so can still bolster RHEL 5 for a strong security posture.

The following are 10 critical security checks for ensuring that your RHEL 5 deployment is adequately hardened against cyber attacks.

1. Mount filesystems with user-writable directories on separate partitions.

Ensure that filesystems with user-writable directories are mounted on separate partitions during initial installation. The following are examples of such directories:

  • /home
  • /tmp
  • /var/tmp

2. Use nosuid, nodev, and no exec.

In many cases hackers will use temporary storage directories such as /tmp to store and execute malicious programs. Altering mount options in /etc/fstab to restrict user access on appropriate filesystems during system configuration can prevent this:

  • noexec prevents execution of binaries on a file system
  • nosuid will prevent the setuid bit from taking effect
  • nodev option prevents use of device files on the filesystem

3. Disable booting from removable media.

Configuring your system's BIOS to disable booting from CDs/DVDs/USB drives prevents malicious software from being surreptitiously loaded. Additionally, access to BIOS settings should be password-protected. 

4. Set a password for the GRUB bootloader.

The GRUB bootloader should be password protected, as would-be attackers can use it to boot into single user mode to gain root access.

  1. Generate a password hash by using /sbin/grub-md5-crypt
  2. Add the hash to the first line of /etc/grub.conf: password --md5 passwordhash

This effectively prevents users from entering single user mode.

5. Don’t use default yum-updatesd.

Updates are critical to keeping your system secure, but default versions of yum-updatesd are faulty; instead, apply updates by setting up a cron job. This can be accomplished through the following steps:

1. Disable the yum-updatesd service: /sbin/chkconfig yum-updatesd off
2. Create the yum.cron file:

/usr/bin/yum -R 120 -e 0 -d 0 -y update yum
/usr/bin/yum -R 10 -e 0 -d 0 -y update

This file should executable and placed in /etc/cron.daily or /etc/cron.weekly.

6. Remove X Windows from the system.

Chances are you won't be needing a GUI for general server administration tasks. It's therefore best to remove X Windows to eliminate the possibility of it being exploited:

  • yum groupremove “X Window System"

7. Make sure /boot is read-only.

This folder is set to RW mode by default, despite only being used for reading/loading modules and the kernel. It should therefore be set to read-only in /etc/fstab:

  • /dev/sda1 /boot ext2 defaults ro 1 2

8. Restrict SSH Access.

SSH should be both restricted from root access and limited to a subset of users. This can accomplished by adding the following to /etc/ssh/sshd_config:

PermitRootLogin no
Protocol 2

The sshusers group should then be added to /etc/ssh/sshd_config:

AllowGroups sshusers

9. Ensure that unnecessary services are disabled.

Use the following command to disable superfluous services:

  • /sbin/chkconfig servicename off

The following services can safely be disabled if not in use:

  • anacron
  • apmd
  • autofs
  • avahi-daemon
  • bluetooth
  • cups
  • firstboot
  • gpm
  • haldaemon
  • hidd
  • hplip
  • isdn
  • kdump
  • kudzu
  • mcstrans
  • mdmonitor
  • messagebus
  • microcode_ctl
  • pcscd
  • readahead_early
  • readahead_later
  • rhnsd
  • setroubleshoot

10. Configure your system to prompt for the root password before entering single user mode.

Your system should be configured to prompt for the root password before entering single user mode to prevent potential exploitation (e.g., dumping password hashes). This can be accomplished by adding the following line to /etc/inittab:

  • su:S:wait:/sbin/sulogin

Looking for a way to verify that these security checks are in place automatically, with just a few mouse clicks? ScriptRock's policy-driven testing suite can validate that these security checks are in place and consistent across all your RHEL 5 server nodes. Give it a test drive today on us.



UpGuard logo in white
UpGuard free resources available for download
Learn more

Download our free ebooks and whitepapers

Insights on cybersecurity and vendor risk management.
UpGuard logo in white
eBooks, Reports & Whitepapers
UpGuard free resources available for download
UpGuard customer support teamUpGuard customer support teamUpGuard customer support team

See UpGuard In Action

Book a free, personalized onboarding call with one of our cybersecurity experts.
Abstract shapeAbstract shape

Related posts

Learn more about the latest issues in cybersecurity.
Deliver icon

Sign up to our newsletter

Get the latest curated cybersecurity news, breaches, events and updates in your inbox every week.
Abstract shapeAbstract shape
Free instant security score

How secure is your organization?

Request a free cybersecurity report to discover key risks on your website, email, network, and brand.
  • Check icon
    Instant insights you can act on immediately
  • Check icon
    13 risk factors, including email security, SSL, DNS health, open ports and common vulnerabilities
Website Security scan resultsWebsite Security scan ratingAbstract shape