关键在于确认路由表是否被篡改、定位篡改来源并验证是否被接受：先用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
