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.
Top 10 Critical Security Checks for RHEL 5
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.
- Generate a password hash by using /sbin/grub-md5-crypt
- 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:
#!/bin/sh
/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.
