Kernel sysctl Hardening Checklist for a Public Server

Most Linux hardening targets user space: users, passwords, firewalls, services. But the kernel itself exposes dozens of tuning knobs — written as path-like sysctl keys — that decide how the box responds to network floods, packet rewriting, and certain resource-exhaustion attacks. A focused sysctl set is cheap, persistent, and applies at every packet, which makes it a fast way to raise the floor on a public server. This guide walks the sysctl parameters that are worth changing on an internet-facing VPS and the ones you should leave alone.

Know What You Are Tuning

sysctl keys are the live interface to kernel parameters, each rooted at /proc/sys. You inspect one with sysctl and change it with either a runtime command or, permanently, a file under /etc/sysctl.d. The cardinal rule: changes you want to survive reboot belong in a file, and every change — temporary or permanent — should be validated immediately. Tuning the kernel blindly can break a production workload or, worse, silently degrade it, so apply a conservative, purposeful set and test the effect rather than copying a 50-line sysctl dump from a blog and calling it done.

The Highest-Value Network Knobs

Start with the parameters that cheaply limit how much the unknown internet can push around your stack. The reverse-path filter stops packets from arriving on an interface they did not originate from, and ignoring ICMP redirects prevents a malicious peer from steering your traffic. The rfc1337 option hardens the TCP stack against a class of blind send attacks.

sudo sysctl -w net.ipv4.conf.all.rp_filter=1
sudo sysctl -w net.ipv4.conf.all.accept_redirects=0
sudo sysctl -w net.ipv4.conf.all.secure_redirects=0
sudo sysctl -w net.ipv4.tcp_rfc1337=1

These four are sensible for a public server where nothing neighbours on the wire that should be redirecting your traffic. Logging martians — packets with impossible source addresses — turns a silent edge case into a log line you can grep when traffic goes strange. The principle is to reduce the surface the network presents without needing any external dependency.

Restrict Kernel Info Leaks

A public server should not advertise the state of its kernel and memory layout to an unprivileged process. Restricting dmesg output and pointer exposure costs nothing for a normal workload and denies an attacker useful reconnaissance. These are the two classic parameters for this class of concern.

sudo sysctl -w kernel.dmesg_restrict=1
sudo sysctl -w kernel.kptr_restrict=2

With dmesg_restrict set, only privileged processes read the kernel ring buffer, which prevents an unprivileged user from harvesting addresses leaked by driver warnings. kptr_restrict hides kernel addresses from /proc files, and the value matters: 0 exposes them, 1 hides them from unprivileged readers, 2 hides them from everyone unless explicitly allowed. The tradeoff is that some diagnostic tooling becomes awkward, which is acceptable on a locked-down public box.

Fortify SYN Handling and Address Space

Denial of service typically lands on connection setup or memory exhaustion, and a couple of parameters shore up both without external rate limiting. SYN cookies keep the server responsive during a flood of half-open connections, and a sensible backlog prevents a flood from eating the whole queue in a panic. On the memory side, restricting core dumps and increasing the address-space randomization makes common memory-corruption exploitation harder.

sudo sysctl -w net.ipv4.tcp_syncookies=1
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=4096
sudo sysctl -w kernel.randomize_va_space=2
sudo sysctl -w fs.suid_dumpable=0

randomize_va_space=2 is ASLR in its most useful form, and fs.suid_dumpable=0 keeps setuid binaries from dumping core in a way that could leak memory. There is a long tail of parameters people tune in "hardening" guides — TTL customization, source-route handling, and dozens more — but this set covers the cases that are actually exercised on a typical public VPS.

Make Changes Persistent

A sysctl value that reverts on reboot is a checkbox, not a hardening. Put your chosen parameters into a file under /etc/sysctl.d, then reload and verify. Keep the file small, commented, and reviewable, because it is now the documented policy for how this kernel should behave.

sudo tee /etc/sysctl.d/99-security.conf > /dev/null <<'EOF'
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.tcp_rfc1337 = 1
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
net.ipv4.tcp_syncookies = 1
kernel.randomize_va_space = 2
EOF
sudo sysctl --system
sudo sysctl net.ipv4.tcp_syncookies

Applying with sysctl --system reads every file in the load path, so you keep the live and persistent state in sync in one command. The final sysctl query confirms the value actually took. Be explicit about what you changed and why in the file; a future admin (or a future you) auditing sysctl will thank you.

Test Before You Trust the Tweaks

Tuning knobs is not free — each one can break a workload you did not anticipate. Run the server's real traffic load after applying changes: a web request pattern, a database connection test, a fresh SSH login. If a parameter interferes with the app, revert it and confirm the baseline returns. The most common culprit is an overly aggressive network setting that drops legitimate load-balanced or tunnelling traffic, so validate against actual traffic, not a static check.

Takeaway

A focused sysctl set hardens the kernel against network abuse, kernel-info leaks, and resource-exhaustion targeted at a public server, and it persists in one reviewable file. Apply a deliberate, tested subset rather than a blanket dump, and verify each change survives reboot. A Netbay Ubuntu or Rocky VPS boots a clean, tunable kernel that accepts these hardening parameters before your service ever exposes a port — netbayhosts.in.