icmp网络掩码请求响应漏洞

2018年，网络某云服务商内部做了一次安全扫描，掩码发现机房里有十几台老旧的请求思科交换机在持续响应来自外网的ICMP掩码请求。这些设备已经运行了七年，漏洞配置从未更新。网络攻击者只需要发一个Type 17的掩码ICMP包，就能拿到内网每台设备的请求子网掩码。这件事后来被写进了他们的漏洞安全复盘报告，但直到今天，网络很多网络管理员仍然不知道这个协议字段的掩码存在。

ICMP网络掩码请求（Type 17）和响应（Type 18）是请求1981年RFC 792里定义的。设计初衷很简单：一台主机刚接入网络，漏洞不知道自己所在子网的网络掩码是多少，就发一个请求出去，掩码网关或路由器告诉它。请求那个年代网络规模小，信任成本低，没人觉得这有什么问题。

问题出在“谁都能问，谁都能答”这个机制上。ICMP没有认证。任何一台设备收到Type 17的请求包，只要自己知道掩码，就会回一个Type 18的响应。攻击者不需要任何凭证，不需要握手，一个数据包就能拿到信息。更麻烦的是，很多操作系统和网络设备默认开启这个功能，而且从不记录日志。

具体能拿到什么？子网掩码本身看起来不起眼，但结合IP地址就能推断出子网大小、广播地址范围、可用主机数量。如果攻击者连续对多个IP发请求，就能画出整个内网的拓扑结构。哪些网段是/24，哪些是/16，哪些是点对点链路用的/30，一目了然。这比端口扫描安静得多，防火墙和IDS通常不会对ICMP Type 17告警。

我翻过一些公开的扫描数据。2016年有个研究团队对IPv4地址空间做了抽样，发现大约2.3%的在线主机仍然响应掩码请求。其中不少是路由器、防火墙和工业控制设备。这些设备往往生命周期很长，固件更新频率极低。一个2010年出厂的西门子PLC，到了2024年还在用默认配置响应Type 17，这种事在工控网络里并不罕见。

有人会说，这算什么漏洞，信息泄露而已。但信息泄露是攻击链的第一步。2019年某次红队演练中，攻击者先通过ICMP掩码请求摸清了目标企业的内网分段，发现财务系统和研发系统在同一个/16里，中间只隔了一台老旧的二层交换机。后续的横向移动路径就是基于这个信息设计的。如果掩码信息不可见，攻击者需要花更多时间做盲扫，被发现的概率会大幅上升。

怎么防？最直接的办法是在边界防火墙和主机防火墙上丢弃所有入站的ICMP Type 17。思科、华为、Juniper的设备都有对应的ACL配置项。Linux下用iptables加一条--icmp-type address-mask-request -j DROP就行。Windows防火墙默认不响应，但某些第三方安全软件会重新打开这个口子，需要手动检查。

另一个思路是只在必要范围内响应。如果内网确实有设备需要动态获取掩码，可以用DHCP Option 1来替代，没必要依赖ICMP。DHCP至少还有租约和认证机制，比裸ICMP可靠得多。

我自己的习惯是，拿到任何一台新设备，先跑一遍nmap -PE -PP --send-ip看看ICMP响应情况，再用hping3 --icmp-ts和--icmp-addr分别测时间戳和掩码请求。这两个老协议字段经常被遗忘，但它们是免费的侦察窗口。关掉它们不需要重启，不需要停机窗口，一条规则的事。不做，就等于在门口挂了个牌子，写着“内网结构请随意取阅”。

RFC 792发布到现在四十多年了。网络环境变了，信任模型变了，但这个字段还在。很多漏洞不是因为技术多复杂，而是因为没人去看那些默认开启的、古老的、不起眼的开关。