Enable Kernel Parameter to Use Reverse Path Filtering on all IPv4 Interfaces
Forces net.ipv4.conf.all.rp_filter to 1 (strict reverse path filtering) so the kernel drops packets whose source address is not reachable via the receiving interface.
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
Reverse Path Filtering (RPF) makes the kernel verify that an incoming packet's source address is reachable through the interface it arrived on; if not, the packet is dropped. This blocks IP spoofing and asymmetric-route attacks where a forged source address is used to bypass network controls or to hide the real origin of traffic. Strict RPF (1) is appropriate for end hosts and routers on simple, symmetric topologies; on multi-homed routers with asymmetric routing it can drop legitimate traffic, so loose mode (2) may be required there.
What Pavois checks
Pavois reads the live runtime value of net.ipv4.conf.all.rp_filter from the kernel (InSpec kernel_parameter, equivalent to sysctl), not the text of a /etc/sysctl.d/ file. The all key takes the maximum of itself and each per-interface setting, so the effective behaviour can differ from any single config line. Auditing the running parameter reflects what the kernel actually enforces; reading a file misses overrides from later drop-ins or sysctl -w.
describe kernel_parameter('net.ipv4.conf.all.rp_filter') do
its('value') { should cmp 1 }
end
describe command("grep -hsE '^[[:space:]]*net.ipv4.conf.all.rp_filter[[: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.rp_filter. Expected output:
net.ipv4.conf.all.rp_filter = 1
Inspect & investigate
RPF drops are not logged unless log_martians is enabled; with it on, dropped spoofed packets appear in the kernel ring buffer (dmesg | grep -i martian) and via journalctl -k. Check the tunable state with sysctl net.ipv4.conf.all.rp_filter and per-interface values with sysctl -a | grep rp_filter.
Remediation
Pavois's harden plan uses the sysctl resource to set net.ipv4.conf.all.rp_filter to 1, applying it to the running kernel and persisting it in a Pavois-managed drop-in under /etc/sysctl.d/ so it survives reboot. 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.rp_filter |
|---|---|
| resource | sysctl |
| value | 1 |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Strict RPF (1) is safe for the vast majority of hosts and is the recommended default. Caution on routers with asymmetric routing (multiple uplinks, multi-homing, some VPN/policy-routing setups): strict mode will silently drop return traffic that arrives on a different interface than the forward path, which can break connectivity. On such systems use loose mode (2) instead. Before applying on a router, confirm your routing is symmetric or test on a non-production node first. This setting does not affect a normal single-homed server's remote access.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R12 | direct | 2.0 | high |
| CIS | 1.4.3, 3.3.7, 3.3.1.12 | direct | per OS, see the benchmark table | high |
| NIST | 3.1.20, CM-6(a), CM-7(a), CM-7(b), SC-7(a) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| PCI DSS | 1.4.3 | supporting | 4.0.1 | 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.