Kernel Hardening with sysctl, Modules & Lockdown

The kernel is the most privileged component on a Linux host, so a single weakness there can undermine every other control. Hardening it means reducing the information it leaks to unprivileged users, shrinking the attack surface of loadable modules, and restricting runtime modification of the running kernel. This guide focuses on three complementary layers: sysctl tunables in /etc/sysctl.d/, module blacklisting in /etc/modprobe.d/, and kernel lockdown. It pairs well with services hardening and the compliance benchmarks guide.

Hardening sysctl tunables

Drop a dedicated file in /etc/sysctl.d/ rather than editing /etc/sysctl.conf, so your changes are isolated and easy to audit. Files are applied in lexical order; a numeric prefix keeps precedence predictable.

cat > /etc/sysctl.d/60-kernel-hardening.conf <<'EOF'
# Hide kernel pointers from unprivileged users (mitigates KASLR leaks)
kernel.kptr_restrict = 2
# Restrict access to the kernel ring buffer / dmesg
kernel.dmesg_restrict = 1
# Restrict ptrace to parent processes only (Yama)
kernel.yama.ptrace_scope = 1
# Full address-space layout randomization (stack, heap, mmap, VDSO)
kernel.randomize_va_space = 2
# Disable loading a new kernel via kexec at runtime
kernel.kexec_load_disabled = 1
# Forbid unprivileged eBPF program loading
kernel.unprivileged_bpf_disabled = 1
# Harden the BPF JIT against spraying / Spectre-style attacks
net.core.bpf_jit_harden = 2
# Deny unprivileged access to perf events
kernel.perf_event_paranoid = 3
# Protect against hardlink/symlink TOCTOU attacks
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
# Never produce core dumps for setuid binaries
fs.suid_dumpable = 0
EOF

Each key serves a distinct purpose. kernel.kptr_restrict=2 masks kernel addresses in /proc for all users, denying attackers the leaks they use to defeat KASLR. kernel.dmesg_restrict=1 stops non-root users from reading kernel log messages that often contain addresses and stack traces. kernel.yama.ptrace_scope=1 blocks one non-child process from attaching to another, a common credential-theft and injection technique. kernel.randomize_va_space=2 enables the strongest ASLR. kernel.kexec_load_disabled=1 prevents an attacker with root from booting an unsigned kernel image to bypass lockdown or Secure Boot. The BPF and perf keys cut off powerful primitives that unprivileged code can otherwise abuse, and the fs.protected_* and fs.suid_dumpable keys close classic filesystem races and core-dump leaks discussed further in filesystem permissions.

Apply and verify:

sysctl --system
sysctl kernel.kptr_restrict kernel.yama.ptrace_scope fs.suid_dumpable

Blacklisting unused kernel modules

Every loadable module is potential attack surface. Disable uncommon filesystems, rare network protocols, and storage interfaces you do not use. Use install <mod> /bin/true to neutralize explicit loads, and blacklist to stop autoload on hardware match.

cat > /etc/modprobe.d/blacklist-hardening.conf <<'EOF'
# Uncommon filesystems
install cramfs /bin/true
install freevxfs /bin/true
install jffs2 /bin/true
# Rare / risky network protocols
install dccp /bin/true
install sctp /bin/true
install rds /bin/true
install tipc /bin/true
# Niche hardware interfaces
install firewire-core /bin/true
blacklist firewire-ohci
# USB mass storage (only where physical-media policy requires it)
install usb-storage /bin/true
EOF

Inspect what is currently loaded and remove a module if it is not in use:

lsmod
modprobe -r dccp 2>/dev/null

Reserve usb-storage blacklisting for endpoints where removable media is forbidden; on workstations it may break legitimate use. Pair this with the network controls in firewall hardening for protocols you cannot fully remove.

Kernel lockdown and Secure Boot

Kernel lockdown restricts even the root user from modifying the running kernel. It has two levels: integrity, which blocks operations that could alter the kernel (kexec, writing to /dev/mem, unsigned module loading), and confidentiality, which additionally blocks paths that could read kernel memory. On most distributions, enabling Secure Boot automatically activates lockdown in integrity mode, since both rely on a verified boot chain. You can also force it via the boot parameter:

# Add to the kernel command line (GRUB), e.g.:
#   lockdown=integrity   or   lockdown=confidentiality
cat /sys/kernel/security/lockdown

The active mode is shown in brackets, for example [none] integrity confidentiality. Note that lockdown cannot be relaxed at runtime once set; you change it at boot.

A hardened or KSPP-aligned kernel (Kernel Self Protection Project) ships many of these protections as compile-time defaults, which is why some sysctls may already report their hardened value or may not exist at all on your kernel. Treat the lists above as a baseline and validate against your distribution and kernel version.

Verify

# sysctl values
sysctl kernel.kptr_restrict kernel.dmesg_restrict kernel.yama.ptrace_scope
sysctl kernel.randomize_va_space kernel.kexec_load_disabled
sysctl kernel.unprivileged_bpf_disabled net.core.bpf_jit_harden
sysctl kernel.perf_event_paranoid fs.protected_hardlinks fs.protected_symlinks fs.suid_dumpable

# module blacklist is effective (no output = blocked)
modprobe -n -v dccp

# lockdown state
cat /sys/kernel/security/lockdown