CIS Benchmark Hardening Guide for Ubuntu and RHEL Linux

CIS Benchmark Hardening Guide for Ubuntu 24.04 and RHEL 9

Linux servers form the backbone of modern infrastructure. From web servers and databases to Kubernetes nodes and container hosts, Linux systems handle critical workloads across every industry. Hardening these systems against CIS benchmarks is essential for both security and regulatory compliance.

This guide covers the practical steps to harden Ubuntu 24.04 LTS and RHEL 9 using their respective CIS benchmarks, including the controls that matter most, common pitfalls, and how to maintain compliance over time.

Understanding Linux CIS Benchmarks

Ubuntu 24.04 LTS Benchmark (CIS Ubuntu Linux 24.04 LTS v1.0.0)

The Ubuntu 24.04 benchmark contains 311 security controls organized across:

Initial Setup (filesystem configuration, software updates, process hardening)

Services (inetd, special purpose, service clients)

Network Configuration (network parameters, firewall)

Logging and Auditing (system logging, audit configuration)

Access, Authentication, and Authorization (cron, SSH, PAM, user accounts)

System Maintenance (file permissions, user/group settings)

RHEL 9 Benchmark (CIS Red Hat Enterprise Linux 9 v2.0.0)

The RHEL 9 benchmark contains 296 security controls with similar organization:

Initial Setup (filesystem, package management, mandatory access control)

Services (time synchronization, special purpose services)

Network Configuration (network parameters, firewall, wireless)

Logging and Auditing (audit daemon, log configuration)

Access, Authentication, and Authorization (SSH, PAM, privilege escalation)

System Maintenance (file permissions, user accounts)

Pre-Hardening Checklist

Before applying any hardening controls, complete these preparation steps:

1. Inventory Running Services

Document all services running on the system. Hardening will disable unnecessary services — know what your applications depend on before disabling anything.

Run on both Ubuntu and RHEL:

List all enabled services

List all listening ports

Document application dependencies

2. Create a System Snapshot

Take a full backup or VM snapshot before applying changes. CIS hardening can break applications if controls conflict with application requirements.

3. Identify Your Profile Level

Level 1: Practical hardening that should not impact most applications. Recommended as a baseline for all systems.

Level 2: Aggressive hardening for high-security environments. May impact application functionality. Test thoroughly.

4. Establish a Test Environment

Never apply CIS hardening directly to production. Use a staging environment that mirrors production (same OS version, same applications, same configuration).

Critical Hardening Categories

1. Filesystem Configuration

Filesystem hardening prevents privilege escalation and limits attack surface.

Key Controls (Ubuntu and RHEL):

Separate partitions: Mount /tmp, /var, /var/tmp, /var/log, /var/log/audit, and /home on separate partitions. This prevents a single filesystem from being filled to deny service.

Mount options: Apply nodev, nosuid, and noexec to /tmp, /var/tmp, and /dev/shm. This prevents execution of binaries and device files from temporary directories.

Disable unused filesystems: Prevent loading of cramfs, squashfs, udf, and other unnecessary filesystem modules. Reduces kernel attack surface.

Common Pitfall: Applications that write executables to /tmp will break if noexec is applied. Java applications and some installers commonly do this. Test before applying.

2. Authentication and Password Policy

Authentication hardening is the highest-impact category for auditors. These controls are frequently checked first.

Key Controls:

Password quality: Enforce minimum length (14 characters), complexity (uppercase, lowercase, digits, special characters), and password history (remember at least 24 passwords)

Account lockout: Lock accounts after 5 failed attempts. Set lockout duration to at least 15 minutes. Configure root lockout separately.

Password aging: Maximum password age of 365 days. Minimum password age of 1 day (prevents rapid cycling). Warn users 7 days before expiry.

PAM configuration: Configure pam_pwquality for password strength enforcement. Configure pam_faillock for account lockout. Ensure pam_unix uses sha512 hashing.

Ubuntu-specific:

Configure /etc/security/pwquality.conf for password requirements

Configure PAM modules in /etc/pam.d/common-auth and /etc/pam.d/common-password

RHEL-specific:

Configure /etc/security/pwquality.conf for password requirements

Configure PAM modules in /etc/pam.d/system-auth and /etc/pam.d/password-auth

Use authselect for PAM profile management (do not edit PAM files directly on RHEL 9)

Common Pitfall: Editing PAM files incorrectly can lock you out of the system entirely. Always keep a root session open while testing PAM changes.

3. SSH Hardening

SSH is the primary remote access method for Linux servers. Hardening SSH is critical for preventing unauthorized access.

Key Controls (Both Distributions):

Protocol: Ensure SSH uses Protocol 2 only (Protocol 1 is deprecated and insecure)

Root login: Disable direct root login (PermitRootLogin no). Require sudo escalation.

Authentication: Disable password authentication where possible. Use key-based authentication.

Timeouts: Set ClientAliveInterval to 300 seconds and ClientAliveCountMax to 3. Idle sessions disconnect after 15 minutes.

Ciphers: Restrict to modern ciphers (aes256-gcm, chacha20-poly1305). Remove legacy ciphers (3des, blowfish).

MACs: Restrict to HMAC-SHA2 algorithms. Remove MD5 and SHA1 MACs.

Key exchange: Use curve25519-sha256 and diffie-hellman-group16-sha512. Remove weak key exchange algorithms.

Banner: Display a legal warning banner before authentication (set Banner /etc/issue.net).

Access restrictions: Use AllowUsers or AllowGroups to restrict SSH access to authorized accounts only.

MaxAuthTries: Set to 4 (limits brute force attempts per connection).

Common Pitfall: Restricting ciphers or key exchange algorithms can break connectivity from older clients (PuTTY versions before 0.78, legacy SCP tools). Test with all clients before applying.

4. Audit and Logging Configuration

Audit logging is essential for both security monitoring and compliance evidence.

Key Controls:

auditd installation: Ensure the audit daemon is installed and enabled

Audit rules: Configure rules to monitor:

Changes to date and time (adjtimex, settimeofday, clock_settime)

User/group modifications (/etc/passwd, /etc/shadow, /etc/group, /etc/gshadow)

Network environment changes (/etc/hosts, /etc/network)

Mandatory access control changes (/etc/selinux, /etc/apparmor)

Login/logout events (faillog, lastlog, tallylog)

Session initiation (utmp, wtmp, btmp)

Permission modifications (chmod, chown, fchmod, fchown)

Unauthorized access attempts (EACCES, EPERM)

Privileged commands (sudo, su)

Kernel module operations (insmod, rmmod, modprobe)

Log rotation: Configure log rotation to prevent disk exhaustion

Remote logging: Forward logs to centralized SIEM via rsyslog or syslog-ng

Ubuntu-specific: Configure AppArmor audit events

RHEL-specific: Configure SELinux audit events. Ensure auditd is configured with immutable rules (-e 2) to prevent tampering.

Common Pitfall: Audit rules generate significant log volume on busy systems. Ensure adequate log storage and rotation before enabling comprehensive auditing.

5. Network Configuration

Network hardening controls traffic flow and prevents common network-based attacks.

Key Controls:

IP forwarding: Disable IP forwarding unless the system is a router (net.ipv4.ip_forward = 0)

Source routing: Disable source routed packets (net.ipv4.conf.all.accept_source_route = 0)

ICMP redirects: Do not accept ICMP redirects (net.ipv4.conf.all.accept_redirects = 0)

Broadcast requests: Ignore broadcast ICMP requests (net.ipv4.icmp_echo_ignore_broadcasts = 1)

SYN cookies: Enable TCP SYN cookies for SYN flood protection (net.ipv4.tcp_syncookies = 1)

IPv6: If IPv6 is not needed, disable it entirely. If needed, apply the same hardening as IPv4.

Firewall: Configure UFW (Ubuntu) or firewalld (RHEL) with default deny inbound and allow only required ports.

Wireless: Disable wireless interfaces on servers (rarely needed).

6. Service Hardening

Disable services that are not required. Each running service is a potential attack vector.

Services commonly disabled:

avahi-daemon (zero-configuration networking — not needed on servers)

cups (printing — rarely needed on servers)

dhcpd (DHCP server — only if the system is not a DHCP server)

slapd (LDAP server — only if the system is not an LDAP server)

nfs-server (NFS — only if the system is not an NFS server)

rpcbind (RPC — only if NFS/NIS is not used)

rsync (only if rsync service is not needed)

snmpd (SNMP — only if SNMP monitoring is not used)

telnet (always disable — use SSH instead)

vsftpd (FTP — always use SFTP instead)

Common Pitfall: Disabling rpcbind will break NFS mounts. Disabling cups will break network printing. Always verify service dependencies before disabling.

Post-Hardening Verification

After applying hardening controls:

1. Run a full CIS benchmark scan to verify all controls pass

2. Test all applications to confirm functionality is not impacted

3. Verify remote access (SSH connectivity with new cipher restrictions)

4. Check audit logging (ensure events are being captured and forwarded)

5. Validate firewall rules (confirm required services are accessible)

6. Document any exceptions with business justification

Maintaining Compliance Over Time

Linux hardening is not a one-time activity. Configuration drift will erode compliance through:

Package updates that reset configuration files

Application deployments that modify system settings

Emergency changes during incident response

New server provisioning without hardened templates

Strategies for Continuous Compliance

Golden images: Create hardened base images for new server provisioning. Rebuild images when benchmark versions are updated.

Configuration management: Use Ansible, Puppet, or Chef to enforce hardening configurations. Infrastructure-as-code prevents manual drift.

Continuous scanning: Automated CIS benchmark scanning at least weekly to detect regressions

Drift alerting: Immediate notification when any control transitions from pass to fail

Change management integration: Require CIS benchmark scan as a gate in your CI/CD pipeline before deploying configuration changes to production

Ubuntu vs RHEL Hardening Differences

While most CIS controls are conceptually identical between Ubuntu and RHEL, the implementation differs:

Package management: Ubuntu uses apt/dpkg; RHEL uses dnf/rpm

Firewall: Ubuntu uses UFW by default; RHEL uses firewalld

Mandatory access control: Ubuntu uses AppArmor; RHEL uses SELinux

PAM configuration: Ubuntu uses /etc/pam.d/common-; RHEL 9 uses authselect profiles

Init system: Both use systemd, but service names may differ

Audit rules: File paths for audit rule configuration differ between distributions

When operating a mixed Ubuntu/RHEL environment, ensure your scanning tool evaluates each system against its platform-specific benchmark rather than applying a generic Linux standard.

CIS benchmark hardening transforms Linux servers from convenience-configured installations into security-hardened infrastructure. The investment in initial hardening pays dividends through reduced attack surface, regulatory compliance, and operational maturity.