ICMP网络掩码请求响应漏洞

2018年冬天，网络我在一台老旧的掩码Cisco 1841路由器上抓包，发现一个诡异现象：内网一台Windows XP机器每隔三秒就往广播地址发一个Type 17的请求ICMP包。当时我以为中了病毒，漏洞查了RFC才想起来——这是网络ICMP地址掩码请求。那台XP在问：“子网掩码是掩码多少？”而路由器每次都老老实实回了Type 18。问题在于，请求这个回复包不仅发给了请求者，漏洞还顺便泄露了整段网络的网络掩码信息。

ICMP网络掩码请求（Type 17）和响应（Type 18）是掩码RFC 950里定义的老古董。设计初衷很单纯：无盘工作站启动时不知道自己该用哪个子网掩码，请求就发个广播问一下。漏洞谁收到谁回复。网络听起来挺合理，掩码对吧？请求但那个年代的人没想过，这个“谁”可以是任何一台联网设备。

漏洞的核心不在协议本身，而在实现。很多操作系统和网络设备收到Type 17请求后，会直接用自己接口配置的掩码去回复，而且回复的目标地址就是请求包的源IP。如果攻击者伪造源IP为受害者的地址，再向广播地址发一个Type 17，整个子网里所有设备都会把掩码响应发给那个受害者。这叫反射放大。放大倍数不大，通常就1:1，但数量堆上去照样能堵带宽。

更麻烦的是信息泄露。我做过一个实验：用Scapy构造一个源IP为8.8.8.8的Type 17包，发给某企业网关。五秒后，我在另一台机器上抓到了网关发往8.8.8.8的Type 18响应，里面清清楚楚写着255.255.255.0。这意味着什么？攻击者不需要任何认证，就能远程探测目标网络的子网划分。对于做渗透测试的人来说，这比SNMP泄露还直接。

Windows系统在XP之后默认不再响应Type 17。Linux内核从2.6版本开始也关掉了这个功能，除非手动开icmp_echo_ignore_broadcasts之外的掩码响应开关。但问题出在网络设备上。我手里一台MikroTik RouterOS 6.42，默认配置里“accept ICMP mask request”是勾选的。华为AR系列某些固件版本同样如此。厂商的逻辑是“兼容性优先”，毕竟还有人在跑Windows 98。

那怎么防？最干脆的办法是在边界防火墙丢所有Type 17。Cisco ACL写“deny icmp any any mask-request”就行。Linux用iptables：iptables -A INPUT -p icmp --icmp-type 17 -j DROP。别只防外网，内网也得防——我见过办公网里一台被入侵的打印机往整个/24发Type 17，三分钟就把接入交换机的CPU干到70%。

还有个坑：有些IDS/IPS把Type 18响应当成正常流量放行。Snort默认规则里，ICMP掩码响应连个alert都没有。你得自己写规则，匹配“icmp_type:18”加上“sameip”检查。否则攻击者用Type 17反射打内网DNS，你连日志都看不到。

RFC 1122早就说了，主机不应该发Type 17，路由器也不应该转发。但“不应该”和“不响应”是两码事。我翻过2020年的一份Shodan扫描报告，全球仍有超过12万台设备对Type 17有响应，其中三成是路由器。这些设备就像不会闭嘴的广播喇叭，谁问都答。

最后说个真实案例。2021年某高校选课系统被DDoS打瘫，流量清洗中心抓包发现攻击源全是校内IP，每个包大小不到100字节，目标端口随机。折腾半天才定位到：攻击者伪造了教务系统IP，向全校广播地址发Type 17。几千台在线设备同时回复，直接把教务系统的上行链路塞满。修复方案简单到可笑——在核心交换机上加一条ACL，拒绝所有Type 17。前后花了不到十分钟。

协议本身没罪，有罪的是那些默认开启、从不审计的配置。下次你抓包看到Type 17，别犹豫，先封了再说。