Lion Cipher Lab
Harden the Linux kernel network stack with sysctl — and verify it
- Cyber / Security Engineer
- Intermediate
- ~50 min
- Free · no account required
Why it matters
Below your firewall rules and your service configs sits the kernel itself, and it will quietly do things an attacker loves unless you tell it not to: accept packets with forged source addresses, follow ICMP redirects that reroute your traffic, honour source-routed packets that pick their own path back, and fall over under a SYN flood. These behaviours are controlled by a few dozen tunables under /proc/sys/net, read and written with the `sysctl` command. The catch is that defaults vary wildly between distributions and even between a cloud image and a laptop — some ship sane, some ship wide…
What you'll learn
- reading and setting kernel network parameters with sysctl
- writing a persistent /etc/sysctl.d drop-in and applying it with `sysctl --system`
- reverse-path filtering (rp_filter) and anti-spoofing
- auditing a host against a checklist and scoring it before/after
- proving a control works with a safe, synthetic spoofed-packet test in a network namespace
- knowing the honest limits: when strict rp_filter breaks, and why sysctl is not a firewall
Steps in this lab
- What this lab is — and what it deliberately is NOT
- The knobs you're about to turn, in plain language (and why)
- Set up a real kernel to work on (VM, WSL2, or a privileged namespace)
- Audit the baseline FIRST — score the host X/N before you change anything
- Write the sysctl.d drop-in and apply it with `sysctl --system`
- Re-audit (N/N) and spot-check a single key
- PROVE rp_filter works: a SAFE spoofed-packet test in a namespace
- The honest limit: strict rp_filter BREAKS asymmetric routing (use loose=2)
- SYN-flood survival: tcp_syncookies, and the counter to watch (labelled illustration)
- The honest negatives — and what to pair this with
- What you built, and the habit underneath it