ten sysctl lines that harden a linux kernel for good

the kernel is doing you a favor, if you let it

most people think hardening a linux box means installing something. a firewall, an intrusion detection tool, maybe fail2ban. all fine. but before any of that, the kernel itself has a pile of switches that decide whether your machine survives basic network attacks or just eats them like it's nothing. these switches are called sysctl parameters and most distros ship with them set to defaults from an era when the internet was a friendlier place. it isn't that place anymore.

this post walks through a small set of these settings, what each one actually blocks, and how to apply them so they stick even after a reboot.

what sysctl actually is

sysctl is the interface for reading and changing kernel parameters while the system is running. no recompiling, no reboot required for most of them. the kernel exposes these as files under /proc/sys, and sysctl is just a clean way to view or set them without you manually catting and echoing into proc files like it's 2004.

you can set values live for testing, but the way to make them permanent is dropping them into a config file that gets read on boot. that's what the file below does.

# /etc/sysctl.d/99-hardening.conf
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.accept_redirects = 0
kernel.randomize_va_space = 2
kernel.kptr_restrict = 2

sysctl --system

tcp_syncookies, surviving a syn flood

a syn flood is an old but still-used denial of service technique. the attacker sends a wave of tcp connection requests (syn packets) and never finishes the handshake. normally your kernel holds each half-open connection in a queue waiting for the reply that never comes, and once that queue fills up, real connections get dropped on the floor.

syncookies change the approach entirely. instead of storing state for each half-open connection, the kernel encodes the connection info into the sequence number of its reply and forgets about it. if the real handshake completes, the info comes back in the ack and the kernel reconstructs the connection from that. no queue to fill, no memory to exhaust. setting this to 1 means your server can absorb a flood that would otherwise choke a default configuration, without you touching a firewall rule.

accept_redirects, shutting the door on icmp trickery

icmp redirects are a legitimate feature meant to let a router tell your machine "hey, there's a better route to this destination, use this gateway instead." the problem is nothing stops a machine on your network from sending you a fake redirect and quietly pointing your traffic through itself instead. that's a man in the middle setup that costs the attacker almost nothing.

setting net.ipv4.conf.all.accept_redirects = 0 tells your kernel to ignore these messages entirely. your routing table stays exactly what you configured, and nobody on your lan gets to reroute your traffic just by asking nicely.

randomize_va_space, making memory exploits harder to land

a lot of exploitation techniques depend on the attacker knowing where things live in memory, like the stack, the heap, or shared libraries. aslr (address space layout randomization) shuffles those locations every time a process starts. setting this to 2 turns on full randomization, covering the stack, heap, and mmap base addresses.

it doesn't make a vulnerable program not vulnerable, but it turns a reliable exploit into a guessing game, and guessing games crash processes instead of owning them. that's a trade defenders should always take.

kptr_restrict, hiding the kernel's own address book

the kernel exposes pointer addresses in places like /proc/kallsyms and various debug interfaces. normally this is handy for driver developers. it's also handy for an attacker trying to defeat kernel aslr, because leaked pointers tell them exactly where kernel code and structures sit in memory.

setting kernel.kptr_restrict = 2 hides these pointers from everyone except processes with real kernel-level privileges. one less leak, one less shortcut for anyone poking around your box.

applying it and making it permanent

drop the four lines above into a file under /etc/sysctl.d/, name it something like 99-hardening.conf so it loads late, then run:

sysctl --system

this command reloads all sysctl config files in order, applies the values immediately, and prints exactly what got set, which is handy for confirming nothing got overridden by a conflicting file. no reboot needed, and the settings persist across every reboot after this because they live in a config file, not just the running kernel state.

the takeaway

none of these four settings are exotic. they're not a substitute for patching, a firewall, or watching your logs. what they are is free. no performance hit worth mentioning, no new software, just the kernel doing something smarter with capabilities it already had. check your own systems, homelab boxes included, diff your current sysctl values against these, and close the gap. ten minutes of work for defenses that quietly sit there working every single day you don't think about them.