机房巡检日志里躺着一行告警：某省政务云出口IP被境外扫描器持续探测，允许traceroute响应全部开放。探测安全员老周的漏洞第一反应是“封了它”，但防火墙策略改了三次，处理告警依旧——因为问题根本不在防火墙，允许而在核心路由器对ICMP和UDP探测的探测默认应答。

traceroute的漏洞原理很简单：发送TTL从1递增的数据包，沿途每台路由器都会丢弃并回传一个“超时”ICMP报文。处理攻击者利用这点，允许能精确绘制出你的探测网络拓扑，知道哪些设备在跑什么系统，漏洞甚至通过响应延迟推测负载。处理真正危险的允许不是探测本身，而是探测你的网络设备像个话痨，逢问必答，漏洞连不该说的版本信息、内网IP都抖落出去。

去年某银行做攻防演练，红队就是靠traceroute摸到了核心交换机的管理地址，然后顺着一条没做访问控制的带外管理链路打了进去。事后复盘发现，那台交换机对任何来源的探测都回包，连伪造源地址的UDP包都照单全收。这相当于把自家大门钥匙挂在门牌号下面。

处理方案其实不复杂，但需要分设备类型区别对待。对于思科和华为的路由器，在全局配置模式下敲三条命令：no ip unreachables、no ip redirects、no ip proxy-arp。第一条禁用不可达消息，第二条禁止重定向，第三条关闭代理ARP——这三板斧砍下去，大部分探测包就石沉大海。但要注意，完全禁用ICMP会干扰正常排障，所以得保留TTL超时消息，只过滤掉针对本机地址的探测响应。

更细的做法是使用ACL限制响应范围。比如只允许内网管理网段发来的UDP探测得到回应，其余一律丢弃。我在生产环境这么配过，效果立竿见影——外部扫描器收到的全是超时，而内部运维人员的mtr工具依然能正常工作。关键点在于ACL的顺序，必须把拒绝规则放在允许规则前面，否则就白写了。

还有个容易忽略的坑：Linux服务器默认开启net.ipv4.conf.all.accept_redirects和secure_redirects，这会让主机响应重定向消息，间接暴露路由信息。用sysctl关掉它们，再把net.ipv4.icmp_echo_ignore_all设为1（如果不需要ping的话）。但别一刀切——监控系统依赖ping探活的话，就得保留echo响应，只屏蔽traceroute特有的UDP高端口探测。

处理完别忘了验证。用traceroute从外网扫一遍，观察每跳是否都返回* * *。但有个反直觉的现象：某些运营商骨干节点即使配置正确，也会因为中间设备默认策略而回包。这时候别慌，只要你的边界路由器不出声，探测到第三跳就断了，内部拓扑就藏在迷雾里。真正的安全不是让所有路径都沉默，而是让关键路径学会闭嘴。

最后说句实在话——这个漏洞修复不难，难的是说服领导“允许被探测”不等于“允许被入侵”。我见过太多团队花大价钱买IPS，却放任路由器对全世界广播自己的结构。安全工作的本质，就是把每扇不必要的门都锁上，哪怕那扇门后面暂时没放值钱的东西。