auditd无法记录ICMP重定向报文，因其不捕获网络层数据包；有效防御是禁用内核重定向功能：设置net.ipv4.conf.all.accept_redirects=0等参数并执行sysctl -p。
想靠 auditd “监控所有 ICMP 重定向日志”来防范中间人攻击，方向上存在根本性误解——这不是日志能力问题，而是功能边界问题。
真正有效的防御方式：从内核参数禁用重定向
防范 ICMP 重定向攻击的核心动作是切断其生效路径，而非事后记录。Linux 提供了明确、轻量、内核级的开关：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 编辑 /etc/sysctl.conf，添加或修改以下行：
net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.all.send_redirects = 0 net.ipv6.conf.all.accept_redirects = 0 net.ipv6.conf.all.send_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 net.ipv4.conf.default.send_redirects = 0
- 执行 sysctl -p 加载配置
- 用 sysctl net.ipv4.conf.all.accept_redirects 验证返回值为 0
- 对非路由器角色的服务器（Web、DB、API 等），这是必须关闭的项
为什么不能依赖 auditd 记录重定向事件？
- ICMP 重定向由内核网络子系统（如 IPv4/IPv6 协议栈）直接处理，不经过 auditd 监控的系统调用路径
- 没有对应的 syscall（如 socket、sendto）会被 auditd 触发审计规则匹配
- 即使你用
-a always,exit -F arch=b64 -S socket等规则监听网络相关调用，也捕获不到重定向报文的生成或接收 - 试图用 auditd 追踪重定向，就像用门禁日志查电梯是否被远程操控——对象错了
可配合 auditd 做的增强防护
虽然 auditd 不管重定向本身，但它能守住“被重定向后可能引发的危险操作”这条线：
- 监控路由表变更：
-w /proc/sys/net/ipv4/conf/ -p wa -k route_change - 审计关键网络配置文件修改（如 /etc/sysctl.conf、/etc/network/interfaces）
- 记录可疑进程执行（如发现 netwox、hping3 等常用于伪造重定向的工具）
- 跟踪 root 用户对 iptables/nftables 的修改，防止攻击者绕过策略
辅助验证与持续观测建议
- 用 tcpdump -i any icmp[icmptype] == icmp-redirect 在测试阶段抓包确认是否还有重定向流入（生产环境慎用）
- 定期检查 ip route show cache，若无重定向生成的缓存条目，说明已生效
- 将 sysctl 配置纳入基线扫描（如 OpenSCAP、Ansible check mode），确保长期合规
