Hardening Linux Servers: The Complete 2026 Checklist

In early 2026, attackers exploited a misconfigured SSH daemon on thousands of internet-facing Ubuntu 24.04 servers — default settings, root login enabled, no rate limiting. The breach pattern was identical across victims. The fixes were all documented. Nobody applied them.

This checklist covers what actually matters in 2026: SSH lockdown, privilege auditing, and kernel-level hardening. Every item includes a command you can run right now.

1. Lock Down SSH Before Anything Else

SSH is still the most abused entry point on Linux servers. Default installs on most distributions leave options open that no production server should have. Start by auditing your current config.

# On web-prod-01 (192.0.2.45), run:
sshd -T | grep -E 'permitrootlogin|passwordauthentication|maxauthtries|x11forwarding|allowtcpforwarding'

# Expected output on a hardened server:
permitrootlogin no
passwordauthentication no
maxauthtries 3
x11forwarding no
allowtcpforwarding no

sshd -T dumps the effective running config — not just what’s in the file, but what SSH is actually using after includes and overrides. If you see permitrootlogin yes or passwordauthentication yes, you have work to do before this server faces another morning.

Apply the fixes directly in /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no
MaxAuthTries 3
X11Forwarding no
AllowTcpForwarding no
AllowUsers deploy sysadmin_jrocha

The AllowUsers directive is the sleeper hit here. It creates an explicit allowlist — any account not listed cannot SSH in, even with valid credentials. Restart with systemctl restart ssh and confirm with another sshd -T run.

2. Audit Who Is Actually Doing What With auditd

auditd is the Linux kernel’s native auditing daemon. It logs system calls, file access, and privilege escalation in a tamper-resistant log. Most servers have it installed but unconfigured — which means it’s watching nothing useful.

Add rules to catch the actions attackers rely on: writing to /etc/passwd, executing commands as root via sudo, and loading kernel modules.

# Add rules to /etc/audit/rules.d/hardening.rules
-w /etc/passwd -p wa -k identity_changes
-w /etc/sudoers -p wa -k sudoers_changes
-a always,exit -F arch=b64 -S execve -F euid=0 -k root_commands
-w /sbin/insmod -p x -k kernel_module_load

Load them immediately with augenrules --load. Now trigger a test — run sudo whoami as user sysadmin_jrocha — and then query the log:

ausearch -k root_commands -ts recent

# Sample output:
type=SYSCALL msg=audit(1757548823.441:3021): arch=c000003e syscall=59
success=yes exit=0 a0=5631abc a1=5631bcd a2=5631cde a3=7ffd1234
items=2 ppid=14322 pid=14323 uid=1001 gid=1001 euid=0 egid=0
comm="whoami" exe="/usr/bin/whoami" key="root_commands"

See uid=1001 (that’s sysadmin_jrocha) with euid=0 (effective root). That’s exactly what a post-exploitation pivot looks like — an attacker who has compromised a regular account and escalated. With these rules running, every such event is on record with a timestamp and PID chain you can trace back.

Forward these logs to a remote syslog server immediately. An attacker with root can clear local logs. Remote logs they cannot touch.

3. Kernel and Network Hardening via sysctl

The kernel exposes runtime tunables through /proc/sys. Several defaults are dangerously permissive — IP forwarding enabled on servers that aren’t routers, ICMP redirects accepted, core dumps writing to predictable paths.

Create /etc/sysctl.d/99-hardening.conf with these settings:

# Disable IP forwarding (unless this IS a router)
net.ipv4.ip_forward = 0

# Reject ICMP redirects — a classic MITM vector
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0

# Prevent SYN flood amplification
net.ipv4.tcp_syncookies = 1

# Disable core dumps for setuid programs
fs.suid_dumpable = 0

# Restrict kernel pointer exposure (defeats many info-leak exploits)
kernel.kptr_restrict = 2

# Restrict dmesg to root only
kernel.dmesg_restrict = 1

Apply with sysctl --system and verify one value to confirm it took:

sysctl net.ipv4.conf.all.accept_redirects
# net.ipv4.conf.all.accept_redirects = 0

kernel.kptr_restrict = 2 deserves a callout. It prevents unprivileged users from reading kernel symbol addresses from /proc/kallsyms. Those addresses are the exact values exploit code needs to bypass KASLR. This single line raises the bar on a large class of local privilege escalation exploits documented through 2025 and 2026.

What To Do Right Now

Pick one server — ideally your most exposed one — and run sshd -T | grep -E 'permitrootlogin|passwordauthentication' right now. If either value comes back as yes, you have an open door. Fix the sshd_config, restart SSH, and schedule the full checklist for the rest of your fleet this week. One command. One server. Start there.