← All rules
SOCLE-CLD-SYS-023// Kernel & network (sysctl)mediumeffective runtime

Disable Accepting ICMP Redirects for All IPv4 Interfaces

Sets net.ipv4.conf.all.accept_redirects=0 so the host ignores unauthenticated ICMP redirect messages that could reroute its traffic.

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.

A pass proves✓ running now✓ on disk✓ survives rebootthe qualified verdict →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
One check, maps to 3 standards

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

ICMP redirect messages let a router tell a host that a more direct route exists for a destination, and the host rewrites its routing table accordingly. These messages are unauthenticated: any device on the segment can forge one. An attacker who injects a malicious ICMP redirect can silently reroute the host's traffic through a machine they control, enabling a man-in-the-middle interception or denial of service. The feature has very few legitimate uses on modern networks, so net.ipv4.conf.all.accept_redirects=0 should be set to ignore them.

What Pavois checks

Pavois reads the live kernel value via kernel_parameter('net.ipv4.conf.all.accept_redirects') and asserts it equals 0. Reading the effective value proves the kernel is actually ignoring redirects right now, a drop-in written but not reloaded, or shadowed by another sysctl.d file, would otherwise leave the host accepting redirects despite a config file that looks correct. File-based scanners miss exactly that gap.

describe kernel_parameter('net.ipv4.conf.all.accept_redirects') do
  its('value') { should cmp 0 }
end
describe command("grep -hsE '^[[:space:]]*net.ipv4.conf.all.accept_redirects[[:space:]]*=[[:space:]]*0([[: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/) }
end

How to verify it is applied

Run sysctl net.ipv4.conf.all.accept_redirects. Expected output:

net.ipv4.conf.all.accept_redirects = 0

Inspect & investigate

  • sysctl net.ipv4.conf.all.accept_redirects shows the current value.
  • cat /proc/sys/net/ipv4/conf/all/accept_redirects is the raw kernel value.
  • Check per-interface effective values too with sysctl -a | grep accept_redirects, since all and an interface key combine. Forged redirects that would have been logged require log_martians; accepted-route changes can be observed with ip route show cache.

Remediation

Pavois's harden plan uses the sysctl resource to set net.ipv4.conf.all.accept_redirects to 0. It writes the key into a Pavois-managed drop-in and reloads it so the host stops honoring ICMP redirects immediately and after reboot. Apply it with pavois harden apply.

Pavois applies this with its own harden engine, the plan below, not a shell script:

keynet.ipv4.conf.all.accept_redirects
resourcesysctl
value0
pavois harden plan local

where the target is local, a user@host SSH alias, or a container , Docs

Impact & precautions

On the vast majority of hosts this is the recommended default with no operational downside. The only environments that legitimately use ICMP redirects are some setups with a non-optimal default gateway that relies on redirects to steer hosts to a better next hop. Before applying, confirm your routing does not depend on redirects (modern networks should advertise correct gateways instead). There is no remote-access lockout risk, since the change only affects how route hints are processed, not connectivity itself.

Standards mapping

StandardReferenceTypeVersionConfidence
ANSSI BP-028R12direct2.0high
CIS3.3.5, 3.3.1.8directper OS, see the benchmark tablehigh
NIST3.1.20, CM-6(a), CM-7(a), CM-7(b), SC-7(a)supporting800-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.

Sources & references