Enable TCP/IP syncookie support
Requires the kernel to be built with CONFIG_SYN_COOKIES=y, enabling SYN-cookie protection against TCP SYN-flood DoS.
Checked against the resolved running state (e.g. sshd -T, sysctl, systemctl show), catches drop-ins and Includes a file read would miss. Caveat: runtime ≠ persistence; a value correct now may not survive a reboot.
Pavois asserts the effective configuration, the live, resolved state, not a file. File-based scanners (OVAL/SCAP, Lynis) miss Includes, drop-ins and runtime defaults; this check sees what is actually applied.
A mapping is a cross-reference to where each standard places this requirement, anchored and cross-validated, not a claim of equivalence. A passing check is evidence toward these references, how to read it.
Why this rule matters
CONFIG_SYN_COOKIES=y compiles in the kernel's defense against TCP SYN-flood attacks. When the half-open connection (SYN) backlog overflows, the kernel encodes the connection state into the sequence number of the SYN-ACK (a "cookie") instead of allocating memory, so legitimate clients can still complete the handshake while an attacker flooding spoofed SYNs cannot exhaust the queue. Without this option the runtime knob net.ipv4.tcp_syncookies has no effect and the host stays vulnerable to a cheap denial-of-service.
What Pavois checks
Pavois reads the build configuration of the running kernel via /boot/config-$(uname -r) or /proc/config.gz and confirms CONFIG_SYN_COOKIES=y. Reading the booted kernel's effective config proves the SYN-cookie machinery is compiled into the kernel in use, a prerequisite without which the net.ipv4.tcp_syncookies sysctl is inert.
describe command("C=/boot/config-$(uname -r); if [ -r \"$C\" ]; then cat \"$C\"; elif zcat /proc/config.gz 2>/dev/null | head -1 | grep -q .; then zcat /proc/config.gz; else echo PAVOIS_NO_KERNEL_CONFIG; fi | grep -E '^(CONFIG_SYN_COOKIES=|PAVOIS_NO_KERNEL_CONFIG)'") do
its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
its('stdout') { should match(/^CONFIG_SYN_COOKIES=y$/) }
endHow to verify it is applied
grep '^CONFIG_SYN_COOKIES=' /boot/config-$(uname -r) || zcat /proc/config.gz | grep '^CONFIG_SYN_COOKIES='
Expected output: CONFIG_SYN_COOKIES=y. To confirm the feature is actually active at runtime, check sysctl net.ipv4.tcp_syncookies (expect = 1).
Inspect & investigate
When SYN cookies are triggered under load the kernel logs a warning, inspect dmesg or journalctl -k for Possible SYN flooding on port <n>. Sending cookies.. The runtime toggle and counters are visible via sysctl net.ipv4.tcp_syncookies and nstat -z | grep -i syncookie.
Remediation
No automated remediation is shipped: CONFIG_SYN_COOKIES is a compile-time kernel option and cannot be added at runtime. The fix is to boot a kernel built with it enabled, the stock distribution kernels for the supported OSes already do. Once compiled in, ensure the feature is actually on via the related sysctl rule (net.ipv4.tcp_syncookies = 1). For a custom kernel, set CONFIG_SYN_COOKIES=y and rebuild.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| resource | kernel_build |
|---|
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Without SYN cookies compiled in, a host exposing any TCP service can have its SYN backlog exhausted by a low-bandwidth spoofed-SYN flood, denying service to legitimate clients. Precautions: the remedy is a kernel change requiring a reboot, schedule a maintenance window and keep a fallback boot entry. SYN cookies disable some TCP options (e.g. large windows/SACK) only on the cookie-validated connections that occur during an active flood, a negligible trade-off; no precaution is needed beyond enabling the matching net.ipv4.tcp_syncookies sysctl.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R22 | direct | 2.0 | high |
Each reference is a cross-reference anchored in the upstream benchmark and cross-validated against the SCAP Security Guide and ansible-lockdown, not a claim of equivalence. Direct = a prescriptive, line-level requirement; supporting = an abstract control family (NIST) the check provides evidence toward. How to read a mapping.