icmp权限许可和访问控制漏洞怎么处理

去年某省级运营商的权限城域网遭遇了一次奇怪的故障——核心路由器CPU利用率飙到90%以上，业务时断时续。和访抓包发现大量ICMP重定向报文从一台被入侵的问控接入层设备涌向核心层。攻击者没用什么高级漏洞，制漏就是洞处利用了设备默认开启的ICMP重定向功能，把流量路径给劫持了。权限这个案例暴露的和访问题很典型：ICMP权限许可和访问控制配置不当，足以让整个网络瘫痪。问控

ICMP这东西，制漏设计之初就是洞处网络诊断用的。ping、权限traceroute、和访路径MTU发现，问控都靠它。制漏问题在于，洞处很多设备出厂默认允许所有类型的ICMP报文进出，包括重定向、时间戳请求、地址掩码请求这些几乎用不到的功能。攻击者拿这些当跳板，要么做侦察，要么直接搞流量劫持。

先搞清楚哪些ICMP类型该关

RFC 792定义了十几种ICMP类型。实际生产环境里，真正需要的没几个。Echo request/reply（类型0和8）用来ping，得留着。Destination unreachable（类型3）对路径MTU发现至关重要，关了小包能通大包全丢。Time exceeded（类型11）是traceroute的基础，也建议保留。

但下面这些，能关就关：ICMP重定向（类型5）——这玩意儿允许路由器告诉主机“下次发另一个网关”，攻击者伪造一个重定向报文就能把流量引到自己的机器上。地址掩码请求（类型17/18）在无盘工作站时代有用，现在纯属多余。时间戳请求（类型13/14）会泄露设备运行时间，给攻击者提供指纹信息。还有源抑制（类型4），早就被RFC 6633废弃了，留着只会增加攻击面。

具体怎么配

以Cisco IOS为例。全局关重定向：no ip redirects。关源路由：no ip source-route。接口下限制ICMP速率：ip icmp rate-limit unreachable 1000，这个数字是毫秒，1000表示每秒最多1个不可达报文。再配合ACL，只允许信任的网段ping设备本身。

华为设备上，undo icmp redirect send关发送，undo icmp redirect receive关接收。有些版本命令略有差异，得查对应文档。Linux主机的话，sysctl -w net.ipv4.conf.all.accept_redirects=0，再写进/etc/sysctl.conf持久化。Windows防火墙默认就拦ICMP重定向，这点比很多Linux发行版做得好。

别一刀切全禁

见过有运维图省事，直接在边界ACL里deny icmp any any。结果呢？PMTUD失效，用户访问某些HTTPS网站卡死——因为大包被丢弃后，路由器应该回ICMP need to fragment，但被ACL拦了，发送方一直重传。这种故障排查起来极其痛苦，因为ping小包正常，大包就是不通。

正确做法是分层控制。边界路由器上，允许必要的ICMP类型进出，但限制速率。内部设备之间，按需放行。主机层面，默认拒绝所有入站ICMP，只放行echo reply和destination unreachable。这样既不影响诊断，又把风险压到最低。

监控和审计不能少

配完不等于完事。得盯着ICMP流量。NetFlow或者sFlow里看ICMP的type/code分布，如果突然出现大量type 5或者type 3 code 4，八成有人在扫描或者攻击。设备日志里开log trap informational，ICMP重定向被丢弃时会记日志。定期用Nessus或者nmap的ICMP相关脚本扫一遍，看有没有漏配的设备。

有个细节容易忽略：IPv6的ICMPv6和IPv4的ICMP是两码事。ICMPv6承担了邻居发现、地址自动配置等关键功能，不能照搬IPv4的封锁策略。RA（路由器通告）和NS（邻居请求）必须放行，但RA Guard得在接入层开启，防止伪造的路由器通告。

说到底，ICMP权限控制的核心就一句话：只放行业务真正需要的类型，其余全部丢弃，并且限制速率。配起来不复杂，难的是持续维护——新设备上线、网络拓扑变更、业务系统升级，都可能让之前的策略失效。把ICMP策略纳入变更管理流程，每次网络调整后重新验证，比什么高级防护设备都管用。

最新评论