关键在于确认路由表是否被篡改、定位篡改来源并验证是否被接受：先用ip route get和route -n检查是否有异常host路由；再查sysctl net.ipv4.conf.all/default.accept_redirects是否为0；最后用tcpdump -i eth0 'icmp[0] == 5'捕获溯源，结合dmesg和rp_filter验证。

排查物理网卡意外接收恶意 ICMP 重定向（Type 5）导致内核路由表被隐式篡改，关键在于“确认是否真发生了篡改”+“定位篡改来源”+“验证是否被接受”。这不是单纯抓包就能闭环的问题，必须结合内核行为、路由状态和网络拓扑交叉验证。

一、立即检查路由表是否已被实际修改

ICMP 重定向报文本身不会自动生效——是否写入路由表，取决于内核参数是否开启接受。先跳过抓包，直查结果：

• 执行 ip route show cache 或 ip route get （如 ip route get 8.8.8.8），看返回的 via 网关是否异常（例如指向了非默认网关的局域网地址）
• 运行 route -n | grep "^"，搜索是否有新增的 host 路由条目（ICMP 重定向通常添加 /32 主机路由）
• 对比故障前后输出：若发现多出类似 10.20.30.40 via 192.168.1.100 dev eth0 的条目，且 192.168.1.100 不是你的合法网关，说明已被篡改

二、确认系统是否真的接受了重定向

Linux 默认关闭该功能，但配置可能被覆盖。需逐层验证：

Skill Weave Chains — 技能链路由引擎

开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。

下载

• 查全局设置：sysctl net.ipv4.conf.all.accept_redirects —— 应为 0
• 查接口级设置：sysctl net.ipv4.conf.eth0.accept_redirects（把 eth0 换成你实际网卡名）—— 也应为 0
• 若任一值为 1，说明该作用域下重定向会被处理；若均为 0，则路由表不可能被自动更新，此时所谓“篡改”实为其他原因（如手动配置、脚本、容器网络干扰）

三、用 tcpdump 定向捕获并溯源攻击源

仅当确认 accept_redirects=1 或怀疑参数被绕过时，才需抓包定位恶意源：

• 在对应网卡上运行：sudo tcpdump -i eth0 -nn 'icmp[0] == 5'，观察是否真有 Type 5 报文流入
• 重点看 源IP：合法重定向只应来自你当前默认网关（ip route show default 输出的 via 地址）。若源IP是陌生地址（如 192.168.1.120），即为伪造
• 加 -v 显示详情：sudo tcpdump -i eth0 -nn -v 'icmp[0] == 5'，可看到报文中建议的“新网关地址”（Gateway Internet Address 字段），比对是否与你网络规划冲突
• 保存样本：sudo tcpdump -i eth0 -nn 'icmp[0] == 5' -w redirect-attack.pcap，后续用 Wireshark 过滤 icmp.type == 5 并分析 Ethernet 源 MAC 是否异常

四、排查常见误触发与加固缺口

很多“疑似攻击”其实源于配置疏漏或环境干扰：

• 检查是否启用了 net.ipv4.ip_forward = 1：若服务器开启转发，又未禁用 send_redirects，它可能自己发重定向，被下游主机误信
• 确认 rp_filter 是否启用：sysctl net.ipv4.conf.all.rp_filter 应为 1，可丢弃源IP不可信的入包（包括伪造重定向）
• 查看内核日志：dmesg | grep -i "redirect"，若出现 “ICMP redirect received” 提示，说明内核确实收到了且尝试处理（此时 accept_redirects 必为 1）
• Docker/K8s 环境注意：某些 CNI 插件会临时修改接口参数，检查 /proc/sys/net/ipv4/conf/veth*/accept_redirects 是否被设为 1