Linux Server Hardening Checklist for 2026

Every Linux server you deploy starts with a default configuration designed for convenience, not security. Default SSH settings allow password authentication. Unnecessary services listen on open ports. Kernel parameters are tuned for compatibility rather than protection. An unhardened server connected to the internet can be compromised within hours. This checklist gives you a practical, prioritized approach to hardening every Linux server in your fleet, aligned with CIS benchmarks and real-world operational requirements. Whether you manage ten servers or ten thousand, these steps form the foundation of a defensible security posture.

Before hardening, you need visibility. Start with SysWard’s free tier to see exactly what is running across your Linux fleet, what patches are missing, and where your biggest risks are.

How to Use This Checklist

This guide is organized by security domain. Each section includes specific actions, commands where applicable, and the rationale behind each recommendation. Items marked with (CIS) align directly with CIS Benchmark recommendations for major Linux distributions.

Priority levels:

• Critical — do this on every server, no exceptions
• High — do this unless you have a documented reason not to
• Medium — recommended for internet-facing and production servers
• Low — recommended for high-security environments

1. System Updates and Patch Management

Keeping software current is the single highest-impact hardening action. Unpatched vulnerabilities are the leading cause of server compromise.

Checklist

• [ ] Critical — Enable automatic security updates or establish a patching schedule with SLA timelines
• [ ] Critical — Verify all package repositories are configured correctly and use HTTPS
• [ ] Critical — Remove or disable any third-party repositories that are not actively maintained
• [ ] High — Implement a patch management tool for centralized visibility and control
• [ ] High — Establish maximum patch latency: critical within 72 hours, high within 14 days (CIS)
• [ ] High — Subscribe to your distribution’s security advisory mailing list
• [ ] Medium — Automate patch compliance reporting for audit evidence

Key Commands

# Check for available security updates (Ubuntu/Debian)
apt list --upgradable 2>/dev/null | grep -i security

# Check for available updates (RHEL/CentOS)
dnf check-update --security

# Verify repository configuration (Ubuntu/Debian)
apt-cache policy | grep http

# Verify repository configuration (RHEL/CentOS)
dnf repolist -v

A centralized patch management solution like SysWard provides real-time visibility into patch status across Ubuntu, Debian, Red Hat, and CentOS servers from a single dashboard.

2. SSH Configuration

SSH is the primary remote access mechanism for Linux servers and one of the most attacked services. Proper SSH hardening eliminates entire categories of attacks.

Checklist

• [ ] Critical — Disable root login via SSH (CIS)
• [ ] Critical — Disable password authentication; require SSH keys only (CIS)
• [ ] Critical — Use SSH protocol version 2 only (default on modern systems)
• [ ] High — Change the default SSH port (reduces automated scanning noise)
• [ ] High — Limit SSH access to specific users or groups using AllowUsers or AllowGroups (CIS)
• [ ] High — Set idle timeout to disconnect inactive sessions (CIS)
• [ ] High — Disable X11 forwarding unless specifically required (CIS)
• [ ] High — Disable TCP forwarding unless specifically required
• [ ] Medium — Restrict SSH access by source IP using firewall rules or sshd_config
• [ ] Medium — Configure SSH key algorithms to use Ed25519 or RSA 4096-bit minimum
• [ ] Medium — Enable SSH logging at VERBOSE level for audit trails (CIS)
• [ ] Low — Implement SSH certificate-based authentication for large fleets
• [ ] Low — Deploy an SSH bastion host for centralized access control

Recommended sshd_config Settings

# /etc/ssh/sshd_config hardening
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
X11Forwarding no
AllowTcpForwarding no
ClientAliveInterval 300
ClientAliveCountMax 2
MaxAuthTries 3
MaxSessions 3
LoginGraceTime 60
Banner /etc/issue.net
LogLevel VERBOSE
PermitEmptyPasswords no
HostbasedAuthentication no
IgnoreRhosts yes

After modifying SSH configuration, always test with a separate session before closing your current connection:

# Validate configuration syntax
sshd -t

# Restart SSH service
systemctl restart sshd

3. User and Account Management

Weak user management is a common path to privilege escalation. Every unnecessary account and every overly permissive group membership increases your attack surface.

Checklist

• [ ] Critical — Remove or lock all default and unused user accounts (CIS)
• [ ] Critical — Set strong password policies: minimum 14 characters, complexity requirements (CIS)
• [ ] Critical — Ensure no accounts have empty passwords (CIS)
• [ ] High — Configure account lockout after 5 failed login attempts (CIS)
• [ ] High — Set password expiration policies (90 days maximum) (CIS)
• [ ] High — Restrict sudo access to specific users and commands (CIS)
• [ ] High — Require passwords for all sudo commands (no NOPASSWD in production) (CIS)
• [ ] High — Audit sudo configuration for overly permissive entries
• [ ] Medium — Set umask to 027 or more restrictive for all users (CIS)
• [ ] Medium — Disable core dumps for all users (CIS)
• [ ] Medium — Configure PAM modules for authentication hardening
• [ ] Low — Implement multi-factor authentication for SSH access

Key Commands

# Find accounts with empty passwords
awk -F: '($2 == "") {print $1}' /etc/shadow

# Find accounts with UID 0 (root equivalent)
awk -F: '($3 == "0") {print $1}' /etc/passwd

# List users with sudo access
getent group sudo wheel

# Check for NOPASSWD entries in sudoers
grep -r "NOPASSWD" /etc/sudoers /etc/sudoers.d/

# Lock an unused account
usermod -L username

# Set password aging policies
chage -M 90 -m 7 -W 14 username

4. Firewall Configuration

A properly configured firewall limits your server’s exposed attack surface to only the services that need to be accessible.

Checklist

• [ ] Critical — Enable a host-based firewall (iptables, nftables, or firewalld) (CIS)
• [ ] Critical — Default deny all incoming traffic (CIS)
• [ ] Critical — Allow only explicitly required inbound ports
• [ ] High — Allow only required outbound traffic (restrict egress where possible)
• [ ] High — Log denied traffic for security monitoring (CIS)
• [ ] High — Rate limit SSH connections to prevent brute force attacks
• [ ] Medium — Implement network segmentation between server tiers
• [ ] Medium — Configure fail2ban or similar intrusion prevention
• [ ] Low — Implement application-layer filtering where applicable

Example Firewall Configuration (nftables)

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;

        # Allow established connections
        ct state established,related accept

        # Allow loopback
        iif lo accept

        # Allow ICMP (ping)
        ip protocol icmp accept
        ip6 nexthdr icmpv6 accept

        # Allow SSH (adjust port if changed)
        tcp dport 22 ct state new limit rate 4/minute accept

        # Allow HTTP/HTTPS (if web server)
        tcp dport { 80, 443 } accept

        # Log and drop everything else
        log prefix "nftables-drop: " drop
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

SysWard’s server compliance reporting can help you verify that firewall rules are consistently applied across your fleet.

5. Service Management

Every running service is a potential attack vector. Minimize your server’s footprint by disabling everything that is not explicitly required.

Checklist

• [ ] Critical — Identify and disable all unnecessary services (CIS)
• [ ] Critical — Remove unnecessary packages and software
• [ ] High — Disable legacy services: rsh, rlogin, telnet, tftp (CIS)
• [ ] High — Disable Avahi, CUPS, and DHCP server unless required (CIS)
• [ ] High — Ensure NTP or chrony is configured and running (CIS)
• [ ] Medium — Configure services to bind to specific interfaces rather than 0.0.0.0
• [ ] Medium — Run services as non-root users where possible
• [ ] Medium — Use systemd sandboxing features (ProtectSystem, PrivateTmp, NoNewPrivileges)

Key Commands

# List all running services
systemctl list-units --type=service --state=running

# List all listening ports and associated services
ss -tlnp

# Disable an unnecessary service
systemctl disable --now avahi-daemon
systemctl disable --now cups

# List installed packages (Debian/Ubuntu)
dpkg -l | wc -l

# Remove unnecessary packages (example)
apt purge telnet rsh-client

6. Filesystem Security

Filesystem configuration affects how processes interact with storage and can prevent common exploitation techniques.

Checklist

• [ ] Critical — Set nodev, nosuid, and noexec on /tmp (CIS)
• [ ] Critical — Set nodev and nosuid on /var/tmp (CIS)
• [ ] Critical — Set nodev on /home (CIS)
• [ ] High — Ensure /tmp, /var, /var/log, and /home are on separate partitions (CIS)
• [ ] High — Set sticky bit on all world-writable directories (CIS)
• [ ] High — Ensure no world-writable files exist outside of /tmp (CIS)
• [ ] High — Disable automounting (CIS)
• [ ] Medium — Configure aide or tripwire for file integrity monitoring (CIS)
• [ ] Medium — Restrict permissions on sensitive files: /etc/passwd, /etc/shadow, /etc/group (CIS)
• [ ] Medium — Disable USB storage if not required (CIS)

Key Commands

# Check /tmp mount options
mount | grep /tmp

# Add secure mount options for /tmp in /etc/fstab
# tmpfs /tmp tmpfs defaults,nodev,nosuid,noexec 0 0

# Find world-writable files
find / -xdev -type f -perm -0002 -ls 2>/dev/null

# Find files without an owner
find / -xdev -nouser -ls 2>/dev/null

# Find files without a group
find / -xdev -nogroup -ls 2>/dev/null

# Check permissions on critical files
stat -c "%a %U %G" /etc/passwd /etc/shadow /etc/group /etc/gshadow

7. Kernel Security and Sysctl Hardening

Kernel parameters control fundamental security behaviors. Proper tuning prevents network-level attacks and limits exploitation techniques.

Checklist

• [ ] Critical — Disable IP forwarding unless the server is a router (CIS)
• [ ] Critical — Disable ICMP redirects (CIS)
• [ ] Critical — Enable TCP SYN cookies to prevent SYN flood attacks (CIS)
• [ ] High — Enable address space layout randomization (ASLR) (CIS)
• [ ] High — Restrict kernel pointer exposure (CIS)
• [ ] High — Disable source-routed packets (CIS)
• [ ] High — Log suspicious packets (martians) (CIS)
• [ ] Medium — Enable ExecShield or equivalent protections
• [ ] Medium — Restrict access to dmesg (CIS)
• [ ] Medium — Disable magic SysRq key in production (CIS)
• [ ] Low — Enable kernel module signing verification

Recommended Sysctl Settings

# /etc/sysctl.d/99-hardening.conf

# Network security
net.ipv4.ip_forward = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# IPv6 hardening (if not using IPv6)
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_source_route = 0
net.ipv6.conf.default.accept_source_route = 0

# Kernel hardening
kernel.randomize_va_space = 2
kernel.kptr_restrict = 2
kernel.dmesg_restrict = 1
kernel.sysrq = 0
kernel.core_uses_pid = 1
fs.suid_dumpable = 0

Apply settings immediately:

sysctl --system

8. Logging and Auditing

Comprehensive logging is essential for incident detection, forensic investigation, and compliance evidence.

Checklist

• [ ] Critical — Ensure rsyslog or journald is configured and running (CIS)
• [ ] Critical — Configure log rotation to prevent disk exhaustion (CIS)
• [ ] High — Install and configure auditd (CIS)
• [ ] High — Audit all authentication events (logins, failures, sudo usage) (CIS)
• [ ] High — Audit file access to sensitive configuration files (CIS)
• [ ] High — Forward logs to a centralized logging system (syslog server, SIEM)
• [ ] High — Set appropriate log file permissions (640 or more restrictive) (CIS)
• [ ] Medium — Audit changes to user and group files (CIS)
• [ ] Medium — Audit changes to network configuration (CIS)
• [ ] Medium — Monitor for unauthorized cron job modifications
• [ ] Medium — Configure log alerting for critical security events
• [ ] Low — Enable process accounting

Essential Audit Rules

# /etc/audit/rules.d/hardening.rules

# Monitor authentication files
-w /etc/passwd -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers

# Monitor SSH configuration
-w /etc/ssh/sshd_config -p wa -k sshd_config

# Monitor login/logout events
-w /var/log/lastlog -p wa -k logins
-w /var/run/faillock/ -p wa -k logins

# Monitor cron configuration
-w /etc/cron.d/ -p wa -k cron
-w /etc/crontab -p wa -k cron

# Monitor kernel module loading
-w /sbin/insmod -p x -k modules
-w /sbin/modprobe -p x -k modules

# Ensure audit configuration is immutable (must be last rule)
-e 2

9. Additional Hardening Measures

AppArmor or SELinux

• [ ] High — Enable and enforce AppArmor (Ubuntu/Debian) or SELinux (RHEL/CentOS) (CIS)
• [ ] High — Ensure no unconfined services are running
• [ ] Medium — Create custom profiles for application-specific services

# Check AppArmor status (Ubuntu/Debian)
apparmor_status

# Check SELinux status (RHEL/CentOS)
sestatus
getenforce

GRUB and Boot Security

• [ ] High — Set a GRUB password to prevent boot parameter modification (CIS)
• [ ] High — Ensure permissions on boot loader config are restrictive (CIS)
• [ ] Medium — Configure secure boot if hardware supports it

Banner and Legal Notices

• [ ] Medium — Configure login banners for legal notice (CIS)
• [ ] Medium — Remove OS identification from login prompts (CIS)

# Set warning banner
echo "Authorized access only. All activity is monitored." > /etc/issue.net
echo "Authorized access only. All activity is monitored." > /etc/issue

10. Ongoing Hardening and Compliance Monitoring

Hardening is not a one-time activity. Servers drift from their hardened state as configurations change, new software is installed, and patches are applied.

Checklist

• [ ] Critical — Schedule regular vulnerability scans and patch assessments
• [ ] High — Run CIS benchmark scans quarterly (using CIS-CAT or OpenSCAP)
• [ ] High — Monitor for configuration drift from hardened baseline
• [ ] High — Review and update hardening standards annually
• [ ] Medium — Automate hardening verification with tools like Ansible, Chef, or Puppet
• [ ] Medium — Include hardening checks in server provisioning pipelines

Maintaining hardened configurations across a fleet of Ubuntu, Red Hat, Debian, and CentOS servers requires continuous monitoring. SysWard provides ongoing visibility into patch status and server compliance, complementing your hardening program with automated tracking and alerting.

CIS Benchmarks Reference

The Center for Internet Security (CIS) publishes detailed hardening benchmarks for every major Linux distribution. These benchmarks are the industry standard for server hardening and are referenced by compliance frameworks including PCI DSS, HIPAA, and SOC 2.

Key CIS benchmark documents for 2026:

Distribution	Benchmark	Levels
Ubuntu 24.04 LTS	CIS Ubuntu Linux 24.04 LTS Benchmark	Level 1, Level 2
RHEL 9	CIS Red Hat Enterprise Linux 9 Benchmark	Level 1, Level 2
Debian 12	CIS Debian Linux 12 Benchmark	Level 1, Level 2
Rocky Linux 9	CIS Rocky Linux 9 Benchmark	Level 1, Level 2
SUSE 15	CIS SUSE Linux Enterprise 15 Benchmark	Level 1, Level 2

Level 1 recommendations are practical for most environments and have minimal performance impact. Level 2 recommendations provide deeper hardening but may affect functionality and require more testing before deployment.

Download the latest benchmarks from the CIS website at no cost (registration required).

Frequently Asked Questions

How long does it take to harden a Linux server?

Initial hardening of a single server takes 2-4 hours for an experienced administrator following a checklist. The real investment is in automation. Once you codify your hardening standards into configuration management (Ansible playbooks, Chef cookbooks, or Puppet manifests), new servers can be hardened automatically in minutes.

Should I harden servers before or after deploying applications?

Harden the base system first, then deploy your application. Some application requirements may conflict with hardening settings (for example, a web application may need specific ports open or particular kernel parameters). Hardening first establishes the secure baseline, and you can then make documented exceptions for application requirements.

How do I balance hardening with system usability?

Start with CIS Level 1 recommendations, which are designed to be practical for production environments. Level 2 recommendations add security but may impact usability or performance. Test all hardening changes in a staging environment before applying to production, and document any deviations from the benchmark with business justification.

How often should I re-audit my hardening configuration?

Run automated CIS benchmark scans monthly and perform manual reviews quarterly. Configuration drift is inevitable as patches are applied, software is updated, and troubleshooting modifications are made. Continuous monitoring catches drift as it happens rather than waiting for a periodic audit.

Does patching undo hardening configurations?

Some patches can reset configuration files to defaults, particularly major version upgrades. This is why configuration management and drift detection are essential. After applying patches, verify that your hardened configurations remain intact. Tools like AIDE or Tripwire detect unexpected file changes, and configuration management tools can enforce desired state.

What is the relationship between hardening and vulnerability management?

Hardening reduces your attack surface by removing unnecessary software, restricting access, and tightening configurations. Vulnerability management addresses known weaknesses in the software you do run. Both are essential. A hardened server with unpatched software is still vulnerable, and a fully patched server with a weak configuration is still at risk. They are complementary practices that together form a strong security posture.

Putting It All Together

Server hardening is a foundational security practice, but it is only effective when applied consistently and maintained over time. Start with the critical items in this checklist, automate your hardening standards, and implement continuous monitoring to catch drift.

The patching component of hardening is where many teams struggle most. Keeping dozens or hundreds of servers current across multiple distributions is operationally demanding without the right tooling. SysWard’s free tier gives you immediate visibility into the patch status of every Linux server in your environment, helping you close one of the most critical gaps in your hardening program.