The Linux kernel ships with defaults tuned for the internet of two decades ago, when connectivity outranked hostility, and a modern production server inherits those defaults unless someone says otherwise. Sysctl is the mechanism for saying otherwise: a small interface into kernel tunables covering network behavior, memory disclosures, execution permissions and logging, where a dozen deliberate values close entire classes of abuse while breaking nothing. This article works through the set that earns its keep on real servers: how sysctl values load and persist, the network line of defense from SYN cookies to redirect rejection, the disclosure family that stops the kernel from leaking its own layout, the execution and ptrace restrictions, and the honest tradeoffs, because a few of these values interact with real workloads and deserve a staging pass rather than a blind copy-paste.
How sysctl works and where values survive reboot
The runtime interface is one command: sysctl -w kernel.dmesg_restrict=1 sets a value immediately, in the running kernel, with no ceremony. Runtime settings vanish at reboot, which is why every meaningful change lives in a file under /etc/sysctl.d/, and the loading mechanism deserves thirty seconds of understanding before the file is written. At boot, the systemd-sysctl service reads every file in /etc/sysctl.d/ in lexical order, and the sysctl --system command applies the same rules on a live system, walking the directories and applying each file in order. A single dedicated file is the clean pattern:
/etc/sysctl.d/60-hardening.conf
Named so that it sorts after distribution defaults, 50- prefixed files, and overrides anything it needs to. The syntax inside is one assignment per line, keys with dots, values after the equals sign, and comments explaining the why. A file without comments is a settings dump, and a settings dump is the artifact that nobody dares touch in three years, which is why the comment discipline starts with the first line.
The verification habit completes the loop: after writing the file, sysctl --system, and after that, spot-check the values by reading them back, sysctl net.ipv4.tcp_syncookies, because the loading order across files can surprise anyone, and a value that silently lost to a later file is a protection that exists only on paper.
The network line of defense
The network family defends against the classic remote noise and the quieter reconnaissance channels. The headline value is the SYN cookie:
net.ipv4.tcp_syncookies = 1
When a flood of half-open connections exhausts the backlog queue, cookies let the server continue accepting legitimate connections by encoding the queue state into the SYN-ACK itself, a defense that costs nothing in normal operation and pays for itself the first time an ill-mannered scanner arrives. The value defaults to enabled on current kernels, but an explicit line documents the intent and survives any future default flip.
The routing family rejects the conversation tricks that date from an era when networks trusted each other:
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
Source-routed packets, carrying a path decided by the sender, have no legitimate role on a production server, and ICMP redirects, which tell the host a better route exists, are a pivoting tool in the wrong hands and a misconfiguration amplifier in confused ones. The one member of this family with a real tradeoff is reverse-path filtering, rp_filter: strict filtering, value 1, drops packets whose return path disagrees with the routing table, which is excellent hygiene on symmetric routes and breakage on asymmetric ones, the keepalived pairs and certain cloud topologies where return traffic legitimately leaves through another interface. The safe rollout is value 1 on hosts with known-symmetric routing, and where the topology is legitimately asymmetric, the loose variant, value 2, keeps the sanity check while tolerating the asymmetry.
The ICMP family rounds out the network posture: icmp_echo_ignore_broadcasts stops the host from answering broadcast pings, the smurf-amplifier pattern, and icmp_ignore_bogus_error_responses keeps malformed error messages from cluttering logs. Both are pure hygiene, both default correctly on modern kernels, and both belong in the file as statements of intent.
Stopping the kernel from leaking its own layout
The disclosure family addresses a subtle class of weaknesses: information that helps an attacker turn a memory bug into a working exploit. The kernel log is the first member, and the topic's canonical value:
kernel.dmesg_restrict = 1
restricts the dmesg buffer to privileged users, because unfiltered kernel logs broadcast memory addresses, hardware details and driver messages that make exploit development measurably easier. The cost on a well-run server is nil, because unprivileged users have no legitimate reason to read the ring buffer, and the benefit is the removal of a free reconnaissance channel.
The second member hides kernel pointers from other interfaces:
kernel.kptr_restrict = 2
Value 2 zeroes kernel addresses in /proc and elsewhere for everyone without privileges, closing the pointer-leak paths that pair with memory bugs. Value 1 hides them from unprivileged readers only, and is the reasonable fallback on systems where some monitoring tooling reads pointer-bearing files with reduced privileges. The third member guards the performance counters, perf_event_paranoid = 3, which removes unprivileged access to the hardware counters, a side channel that has carried real attacks, at the cost of breaking unprivileged profiling, which on production servers is exactly the trade wanted. The family's philosophy in one sentence: a production kernel tells its layout to its administrators and to nobody else.
Execution, ptrace and the privilege walls
The process family walls off the ways one process reaches inside another. Yama's ptrace scope is the headline:
kernel.yama.ptrace_scope = 2
where value 0 is the historical anyone-can-inspect-anyone, value 1 restricts ptrace to direct parent relationships, and value 2 restricts it further to processes carrying a specific capability, effectively administrators only. Debuggers and strace continue to work under sudo, which is the correct production trade: diagnostics belong to the people already trusted with root. The famous caveat is the crash-handler pattern, where a wrapper process tries to inspect a crashed child without privileges, and the fix is configuration of the handler, or scope 1 where such a handler is business-critical, rather than abandoning the restriction fleet-wide.
The filesystem family hardens the classic privilege escalation helpers:
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
fs.suid_dumpable = 0
Protected links and symlinks follow the ownership rules that turn the historical /tmp races into dead ends, and the suid-dumpable switch prevents core dumps of privileged processes, which would otherwise write secrets from root memory to disk in plain sight. The companion randomize_va_space = 2, full address-space randomization, completes the memory-hardening posture and has been a default for years, present in the file as an anchor against any exotic kernel configuration that shipped without it.
The modern attack surfaces, BPF and user namespaces
Two newer values guard the sharpest tools in the kernel toolbox, and both carry the honest tradeoffs that deserve a paragraph rather than a slogan. Unprivileged BPF is the first:
kernel.unprivileged_userns_clone = 0
kernel.unprivileged_bpf_disabled = 1
User namespaces are the mechanism that lets unprivileged users create containers and private mounts, and disabling unprivileged cloning closes a large, actively-exploited attack surface, at the price of breaking rootless containers and some sandboxed desktop applications. On a server, the price is usually zero, because containers on servers run under real privileges through the container runtime, and the rootless pattern, where it matters, belongs on dedicated nodes with the value left at 1 there deliberately. The first line is Debian-family specific, since the distribution carries the toggle, while the upstream kernel exposes the same control through unprivileged_userns in the user namespace sysctls, and the file comments should name which applies.
The BPF disable is blunter: unprivileged_bpf_disabled = 1 removes BPF from unprivileged users entirely, which closes eBPF-based reconnaissance and the speculative-execution channels that rode it, while breaking nothing that a production server runs, because BPF tools run under privileges on hosts that need them. The value that pairs with both, perf_event_paranoid from the disclosure section, deserves its mention here again, because the three values together form the modern wall between unprivileged users and the kernel's instrumentation machinery.
Staging, ordering and the fleet checklist
Every value in this article costs a staging pass, and the pass is cheap: apply the file on a test host, run the workload, and watch for the two symptoms that matter. The loud symptom is breakage, the rootless container that fails on the namespace restriction, the monitoring agent that loses its counters, and each loud failure either earns a documented exception for that class of host or confirms the value belongs. The quiet symptom is absence, the protection that looks applied but was overridden by a later file or a distribution default that changed under it, and the reading-back habit, sysctl -a | grep against the intended list, is the only reliable check.
The file structure that survives fleet scale is one hardening file plus one role-specific file, 60-hardening.conf everywhere and 70-loadbalancer.conf on the load balancer that needs the loose rp_filter, with each exception living next to its reason. Configuration management distributes both, and the quarterly review reads the files rather than trusting the tooling, because sysctl files rot in the specific way of being technically applied and semantically forgotten. The checklist version of the whole article: one file under /etc/sysctl.d/, network values first, disclosure values second, execution restrictions third, comments throughout, staging pass with the real workload, and the reading-back verification after every change. A server with that file is measurably harder to reconnoiter, harder to exploit and exactly as functional as the day before it was written.
## The complete file as it leaves the staging host
The reference file below is what a mid-size production host carries after the staging pass, every line with its reason, ready for the configuration management role to distribute:
/etc/sysctl.d/60-hardening.conf # Network defenses net.ipv4.tcp_syncookies = 1 net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.default.rp_filter = 1 net.ipv4.icmp_echo_ignore_broadcasts = 1 net.ipv4.icmp_ignore_bogus_error_responses = 1 # Kernel disclosure limits kernel.dmesg_restrict = 1 kernel.kptr_restrict = 2 kernel.perf_event_paranoid = 3 # Execution and process walls kernel.yama.ptrace_scope = 2 fs.protected_hardlinks = 1 fs.protected_symlinks = 1 fs.suid_dumpable = 0 kernel.randomize_va_space = 2
The naming of the conf.all keys versus the conf.default pair in the rp_filter line is the one syntax detail worth its own sentence: the all keys apply to interfaces that already exist at load time, the default keys apply to interfaces created later, and writing both is the pattern that keeps the rule true after a reboot re-enumerates the NICs in a different order. The all and default duplication is harmless where both appear, and its absence is the classic way a value passes verification on the console and fails on the host that boots with a renamed interface.
Reading the file top to bottom against the article's sections is the review that each line has a story, a tradeoff considered and a comment that names it, and the file ends where every hardening artifact should end: short enough to read in one sitting, complete enough that the next administrator inherits a policy rather than a puzzle.