Ensure ICMP Redirects Are Not Accepted: How to Fix the CIS Linux Finding

Ensure ICMP redirects are not accepted is a CIS benchmark check that fails when the Linux kernel accepts ICMP redirects that can alter its routing. To fix it, set net.ipv4.conf.all.accept_redirects, its default twin and the IPv6 equivalents to 0 in /etc/sysctl.d/, add send_redirects = 0 on hosts that do not route, run sysctl --system and rescan.

What the scanner is actually detecting

This finding combines two CIS Linux benchmark recommendations that Nessus and other Tenable products report as separate items when they run a CIS compliance audit:

• “Ensure ICMP redirects are not accepted”: expects net.ipv4.conf.all.accept_redirects and net.ipv4.conf.default.accept_redirects to be 0, and, if IPv6 is enabled, net.ipv6.conf.all.accept_redirects and net.ipv6.conf.default.accept_redirects as well.
• “Ensure packet redirect sending is disabled”: expects net.ipv4.conf.all.send_redirects and net.ipv4.conf.default.send_redirects to be 0. This item has no IPv6 part.

Item numbers vary by benchmark and version. In the CIS Red Hat Enterprise Linux 7 STIG benchmark v2.0.0 they are 3.3.2 (accept) and 3.2.2 (send). Several older benchmarks number the accept item 3.2.2, and CIS Amazon Linux 2 v3.0.0 numbers it 3.3.5. DISA STIG audits carry equivalent rules, for example RHEL-09-253040 for IPv4 redirects on RHEL 9.

Each recommendation produces several result lines, one per key. Tenable also splits them into checks of the running kernel value (titles containing sysctl) and checks of the configuration files (titles containing files or sysctl.conf/sysctl.d). A host can pass one and fail the other. Both kinds read settings from the host, so they need an authenticated Linux scan over SSH. These are configuration checks, not a network probe.

Real-world risk, stated honestly

ICMP redirects exist so a router can tell a host that a better next hop is available. They are unauthenticated, and the DISA STIG notes that an illicit redirect could result in a man-in-the-middle attack. The CIS rationale is the same: bogus redirects can alter the routing table and send traffic somewhere it can be captured.

The practical attack surface is narrow. Linux still applies the RFC 1122 redirect rules, so a redirect has to look like it came from the current gateway and point to a next hop on the same subnet. In practice the attacker already needs a foothold on the local segment, and from there ARP spoofing gives similar interception. Treat this as a Level 1 hardening item and defense in depth, not an emergency. It does not expose the host to remote compromise on its own.

The sending half matters even less on a plain server. The kernel documentation describes send_redirects as “send redirects, if router”, so a host that never forwards packets rarely sends any. It becomes relevant when forwarding is on, which is why the CIS item limits it to hosts that do not act as routers.

How to confirm it on the host

# The six values the benchmark checks
sysctl net.ipv4.conf.all.accept_redirects net.ipv4.conf.default.accept_redirects 
       net.ipv6.conf.all.accept_redirects net.ipv6.conf.default.accept_redirects 
       net.ipv4.conf.all.send_redirects net.ipv4.conf.default.send_redirects

# Any individual interface still set to 1
sysctl -a 2>/dev/null | grep -E '.(accept|send)_redirects = 1$'

# Which files set these keys
grep -rE 'accept_redirects|send_redirects' /etc/sysctl.conf /etc/sysctl.d/ /run/sysctl.d/ 
  /usr/local/lib/sysctl.d/ /usr/lib/sysctl.d/ /lib/sysctl.d/ 2>/dev/null

# Is this host supposed to route?
sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding

If IPv6 is disabled at boot, the net.ipv6 keys do not exist and sysctl reports an error for them. The benchmark applies the IPv6 settings only when IPv6 is enabled.

The interface check matters. According to the kernel documentation, on an interface that does not forward, IPv4 redirects are accepted if either the all value or that interface’s own value is 1. The same “at least one” logic applies to send_redirects. The scanner checks all and default, so an interface-level 1 can survive a clean scan.

How to fix it

Linux hosts that do not route (most servers)

The method is the same on RHEL and its rebuilds, Amazon Linux, Debian, Ubuntu and SUSE. Save the current values first so you can roll back:

sysctl -a 2>/dev/null | grep -E '_redirects = ' > /root/redirects-before.conf

cat > /etc/sysctl.d/60-netipv4_sysctl.conf <<'EOF'
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
EOF

# Only if IPv6 is enabled
cat > /etc/sysctl.d/60-netipv6_sysctl.conf <<'EOF'
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0
EOF

sysctl --system
sysctl -w net.ipv4.route.flush=1
sysctl -w net.ipv6.route.flush=1

Newer CIS benchmarks use the 60-netipv4_sysctl.conf name in their examples. The name itself only matters for sort order. The two route.flush commands come straight from the benchmark’s remediation and ask the kernel to flush its cached routes. If you prefer not to reload every file, sysctl -w key=0 for each key works too, but the files are what make it persistent.

Three details decide whether the change sticks:

• Put it in /etc. The benchmark’s solution names /etc/sysctl.conf or a file in /etc/sysctl.d/. Do not rely on /usr/lib/sysctl.d/, which belongs to packages.
• Remove conflicts. Per sysctl.d(5), when several files set the same key, the file with the lexicographically latest name wins. sysctl --system reads /etc/sysctl.conf last, so a stray accept_redirects = 1 there overrides your file. Delete or comment out any line the grep above found.
• Watch IP forwarding changes. The kernel documentation warns that changing net.ipv4.ip_forward resets IPv4 configuration parameters to host or router defaults, and the host default for accept_redirects is on. If a service or another sysctl file toggles forwarding after yours is applied, check the values again.

Interfaces that still show 1

The systemd sysctl.d(5) page explains that a default value covers interfaces added later, and it handles interfaces detected earlier with separate per-interface settings. If the interface check still lists an entry after sysctl --system, set it explicitly and add the same line to your file (replace eth0 with the real name):

sysctl -w net.ipv4.conf.eth0.accept_redirects=0
sysctl -w net.ipv4.conf.eth0.send_redirects=0
sysctl -w net.ipv6.conf.eth0.accept_redirects=0

The same man page notes that interface-specific settings in sysctl.d files are applied to each interface as it appears, so a per-interface line in the file persists across reboots.

Routers, VPN gateways and container hosts

If ip_forward is 1 because the host routes by design, apply the accept part only. Sending redirects is normal router behavior, and the CIS description scopes the send item to host-only configurations. On container hosts and VPN gateways, test the send change on one system before a fleet rollout, and record a documented exception wherever you keep redirects enabled.

How to verify the fix and rescan

1. Rerun the first command above. All six keys should print 0 (four if IPv6 is disabled).
2. Rerun the interface grep. It should return nothing, apart from interfaces on a host that routes by design.
3. Check that sysctl --system lists your file among the files it applies, and that no file applied after it sets these keys again.
4. Reboot one host and repeat steps 1 and 2. This catches a later file or a service that restores the old values.
5. Rerun the credentialed CIS compliance audit with the same policy. Both the running-value and the file-based items must pass.

What can break and how to roll back

On a normal server, very little. Without redirects the host keeps sending traffic through the gateway in its routing table. If a network relied on redirects to steer hosts toward a second router on the same subnet, that traffic now takes an extra hop through the default gateway, or fails if that gateway will not forward it. The fix there is a proper static route, not redirects. On a host that routes, disabling send_redirects stops it from telling clients about a better next hop.

To roll back, remove the files and restore the saved values:

rm /etc/sysctl.d/60-netipv4_sysctl.conf /etc/sysctl.d/60-netipv6_sysctl.conf
sysctl -p /root/redirects-before.conf

Removing a file alone does not change the running values until the next reboot, which is why the saved copy helps. Errors for interfaces that no longer exist are harmless.

Common false positive reasons

• The host is a router by design. A firewall, VPN concentrator or NAT gateway that sends redirects is working as intended. Record the exception for the send item.
• IPv6 is disabled. The IPv6 keys do not apply. If they still appear, confirm how IPv6 is disabled on the host and attach that as evidence.
• Running value and files disagree. The runtime check passes after a sysctl -w, but the file check fails because nothing persists it. The reverse also happens when a later file or /etc/sysctl.conf wins at boot.
• The setting lives outside /etc. A value set only in /usr/lib/sysctl.d/ or /run/sysctl.d/ may be active but not where the benchmark looks.
• Stale results. The report predates the fix, or the scan fell back to unauthenticated checks.

FAQ

Does disabling ICMP redirects break networking?

Not on a typical server. Traffic follows the routing table and default gateway. Only networks that depend on redirects to reach a second router on the same subnet notice a change.

Do I need to reboot after changing these settings?

No. sysctl --system applies them immediately. Reboot one host only to prove they persist.

Does net.ipv4.conf.all.accept_redirects = 0 also cover IPv6?

No. IPv6 uses net.ipv6.conf.all.accept_redirects and net.ipv6.conf.default.accept_redirects, and the benchmark expects both at 0 when IPv6 is enabled.

What about “Ensure secure ICMP redirects are not accepted”?

That is a separate CIS item for secure_redirects, which accepts redirects only toward gateways already in the interface’s gateway list. It sits next to this item in the benchmark and is fixed the same way, with the all and default keys set to 0.

Tracking this finding across many hosts

On a large Linux estate, the usual problem is the host where a later sysctl file or a forwarding change brings the old value back. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners, including Nessus results uploaded as a .nessus export. Its AI can write a host-specific remediation script like the sysctl.d change above, which runs only after human approval and is deployed by SITEY agents on Linux endpoints, followed by a re-test to verify closure.

Sources

• Tenable audit item: CIS RHEL 7 STIG v2.0.0, 3.3.2 Ensure ICMP redirects are not accepted
• Tenable audit item: CIS RHEL 7 STIG v2.0.0, 3.2.2 Ensure packet redirect sending is disabled
• Linux kernel documentation: IP sysctl (accept_redirects, send_redirects, ip_forward)
• sysctl.d(5) manual page: file precedence and per-interface settings
• sysctl(8) manual page: –system and file order