Enable Kernel Parameter to Log Martian Packets on all IPv4 Interfaces
Sets net.ipv4.conf.all.log_martians=1 so the kernel logs dropped packets with impossible/spoofed source addresses.
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
"Martian" packets carry impossible or illegitimate source addresses (e.g. a packet claiming to come from a local or reserved address while arriving from outside). Their presence, alongside spoofed, source-routed and redirected packets, is a strong indicator of spoofing, reconnaissance or misconfiguration. With net.ipv4.conf.all.log_martians=1, the kernel logs each dropped martian packet, giving defenders the visibility to detect these attacks and the audit trail to investigate them. Without it, the packets are silently dropped and the malicious activity leaves no trace.
What Pavois checks
Pavois reads the live kernel value via kernel_parameter('net.ipv4.conf.all.log_martians') and asserts it equals 1. Whether martian logging is actually happening depends on the running kernel value, not on a config file: a sysctl.d entry written but not reloaded, or overridden by a per-interface key, would silence the logging despite a correct-looking file. Reading the effective value confirms the logging is truly active.
describe kernel_parameter('net.ipv4.conf.all.log_martians') do
its('value') { should cmp 1 }
end
describe command("grep -hsE '^[[:space:]]*net.ipv4.conf.all.log_martians[[:space:]]*=[[:space:]]*1([[:space:]]|$)' /etc/sysctl.conf /etc/sysctl.d/*.conf /run/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf 2>/dev/null") do
its('stdout') { should match(/\S/) }
endHow to verify it is applied
Run sysctl net.ipv4.conf.all.log_martians. Expected output:
net.ipv4.conf.all.log_martians = 1
Inspect & investigate
sysctl net.ipv4.conf.all.log_martiansconfirms the value.- Once enabled, dropped martian packets appear in the kernel log:
journalctl -k | grep -i 'martian'(ordmesg | grep -i martian), with lines likeIPv4: martian source <ip> from <ip>, on dev <iface>. cat /proc/sys/net/ipv4/conf/all/log_martiansis the raw kernel value.
Remediation
Pavois's harden plan uses the sysctl resource to set net.ipv4.conf.all.log_martians to 1. It writes the key into a Pavois-managed drop-in and reloads it so martian-packet logging is active immediately and persistent across reboots. Apply it with pavois harden apply.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| key | net.ipv4.conf.all.log_martians |
|---|---|
| resource | sysctl |
| value | 1 |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
This rule only enables logging; it does not change which packets are accepted, so there is no connectivity or lockout risk. The single caveat is log volume: on a noisy or hostile network segment the kernel log can fill with martian entries, adding disk and journal pressure. Before applying at scale, ensure rate limiting (the kernel already rate-limits these messages) and log rotation are in place, and consider forwarding kernel logs to your SIEM so the alerts are actually used. Otherwise this is a safe, observability-only improvement.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 3.3.9, 3.3.1.16 | direct | per OS, see the benchmark table | high |
| NIST | 3.1.20, CM-7(a), CM-7(b), SC-5(3)(a) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
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.