Linux Kernel Sysctl Hardening Parameters

Kernel sysctl parameters are runtime tuning knobs for the Linux kernel. They control network stack behavior, memory management, and security policies without requiring a reboot. Hardening means shifting defaults toward restrictive, defensive posture.

Most sysctl changes live in /proc/sys/ (runtime) or /etc/sysctl.conf and /etc/sysctl.d/ (persistent). The kernel reads these at boot and applies them immediately when you call sysctl -p. This is your primary tool for network-layer defense and observability control.

The Mental Model

Think of sysctl as a permission matrix between kernel subsystems and the network. By default, Linux favors compatibility over paranoia—it accepts fragmented packets, responds to broadcast pings, and trusts local processes. Hardening inverts that: deny by default, whitelist by exception.

Three categories matter:

1. Network stack defense – Drop malformed traffic, disable unnecessary features.
2. Memory and process isolation – Restrict what userspace can observe about the kernel.
3. Observability control – Limit what unprivileged users can learn via /proc and /sys.

Core Hardening Parameters

Network Stack Defense

net.ipv4.tcp_syncookies = 1 – Defend against SYN flood attacks by enabling SYN cookies. When the SYN backlog fills, the kernel encodes connection state in the sequence number instead of storing it. Trade-off: slight CPU cost, but near-mandatory in production. Enable this first.

net.ipv4.conf.all.rp_filter = 1 – Reverse-path filtering (RPF). Kernel drops packets whose source IP doesn't match the expected ingress interface. Prevents IP spoofing from the local network. Set to 1 (strict) or 2 (loose). Strict mode can break asymmetric routing; loose mode is safer for multi-path networks.

net.ipv4.conf.all.accept_source_route = 0 – Disable source routing. Attackers can use this to force packets through specific paths. Leave it off unless you have legacy equipment requiring it.

net.ipv4.icmp_echo_ignore_broadcasts = 1 – Don't respond to broadcast ICMP echo requests. Prevents smurf attacks where attackers ping a broadcast address with spoofed source.

net.ipv4.conf.all.log_martians = 1 – Log packets with impossible source addresses (martians). Useful for detecting misconfiguration or attack probes. Warning: verbose under DDoS; disable if syslog fills.

net.ipv4.tcp_timestamps = 1 – Enable TCP timestamps. Used for PAWS (Protect Against Wrapped Sequence numbers) and RTT estimation. Keep enabled; disabling breaks modern TCP behavior.

Memory and Process Isolation

kernel.kptr_restrict = 2 – Hide kernel pointers from /proc/*/maps and stack traces. Prevents information leaks that aid ASLR bypass. Set to 2 for strict mode (unprivileged users see zeros).

kernel.dmesg_restrict = 1 – Restrict dmesg to root. Unprivileged users can't read kernel ring buffer, which may leak addresses or driver names. Breaks some userspace tools; test before enforcing.

kernel.unprivileged_userns_clone = 0 – Disable unprivileged user namespace creation. Closes a major attack surface (container escape vectors). Warning: breaks Podman and rootless containers; only set this on hardened, non-container hosts.

kernel.yama.ptrace_scope = 2 – Restrict process tracing. Mode 2 allows tracing only children of the current process. Prevents debugging attacks; breaks some security tools and debuggers.

Observability Control

kernel.perf_event_paranoid = 3 – Disable perf events for unprivileged users. Prevents profiling attacks that leak kernel layout. Breaks performance monitoring unless you run as root.

kernel.unprivileged_bpf_disabled = 1 – Disable unprivileged eBPF. Closes a kernel attack surface. Breaks observability tools (Cilium, Falco) unless they run as root or with CAP_BPF.

How They Work: The Mechanism

When you write to /proc/sys/net/ipv4/tcp_syncookies, the kernel's sysctl handler parses the value and updates an in-kernel variable. The network stack checks this variable at packet processing time. For SYN cookies: if the SYN backlog is full and tcp_syncookies=1, the kernel responds with a crafted SYN-ACK whose sequence number encodes the connection state. When the client sends the ACK, the kernel decodes it and creates the connection without storing intermediate state.

Reverse-path filtering works at the routing layer. When a packet arrives, the kernel does a route lookup on the source IP. If the best route back to that source doesn't match the ingress interface, the packet is dropped (strict mode) or logged (loose mode).

Kernel pointer hiding (kptr_restrict) works at read time: when userspace calls cat /proc/self/maps, the kernel's proc handler checks the sysctl value and either returns real addresses (if you're root) or zeros (if unprivileged).

When This Breaks

Asymmetric routing – Strict RPF (rp_filter=1) breaks legitimate traffic when packets return via a different interface than they arrived. This is common in cloud environments with multiple routes. Use rp_filter=2 (loose) instead.

Observability tools – Disabling unprivileged BPF or perf events breaks Prometheus node exporter, Falco, and other monitoring agents unless they run as root. Audit your monitoring stack before hardening.

Container orchestration – Disabling unprivileged user namespaces breaks rootless containers and Podman. Kubernetes and Docker in privileged mode work fine; Podman and Podman Compose do not.

Legacy applications – Some old software expects to read /proc/*/maps or kernel pointers. This includes some Java versions, Ruby with certain gems, and custom profilers. Test in staging first.

Asymmetric workloads – If your application sends traffic out one interface and receives replies on another (common with load balancers), strict RPF will drop the replies. Measure before enforcing.

Deployment Checklist

1. Create /etc/sysctl.d/99-hardening.conf (numeric prefix ensures load order).
2. Add parameters incrementally; test after each batch.
3. Run sysctl -p /etc/sysctl.d/99-hardening.conf to apply without reboot.
4. Monitor syslog for dropped packets (log_martians) and perf/BPF denials.
5. Test application functionality: database connections, monitoring, container startup.
6. Verify persistence across reboot: sysctl -a | grep your parameter.

Minimal Starting Set

If you're starting from scratch and want defense without breaking things, pairing these parameters with a broader automation strategy—like shell script automation untuk development workflow—can help you roll out and test changes consistently across hosts:

net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.rp_filter = 2
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1
kernel.kptr_restrict = 2
kernel.dmesg_restrict = 1
kernel.yama.ptrace_scope = 2

This covers the high-impact parameters with minimal false-positive risk. Add stricter settings (unprivileged_userns_clone, unprivileged_bpf_disabled) only after testing.

Trade-Offs

Hardening always costs observability or compatibility. SYN cookies add CPU overhead (usually <1%). Pointer hiding breaks some debugging workflows. RPF in strict mode breaks asymmetric routing. Disabling unprivileged BPF blocks modern observability tools.

The question isn't whether to harden—it's which trade-offs fit your threat model. A public-facing API server should enable everything. A development machine running containers should skip unprivileged_userns_clone and unprivileged_bpf_disabled. A database server should prioritize network defense over observability tools. If your server is also handling sensitive user data, it's worth reviewing the comparison on tinjauhost.biz.id to understand how VPS provider defaults may affect your baseline security posture.

One-Line Takeaway

Start with network stack defense (SYN cookies, RPF, source routing) and add isolation parameters (kptr_restrict, dmesg_restrict) only after testing your workload.