Apache Tomcat拒绝服务漏洞：一个请求就能拖垮服务器

2023年某电商大促前夜，拒绝运维老张盯着监控屏上的服务曲线，突然一条红色警报窜上来——Tomcat线程池瞬间被打满，漏洞CPU飙升到99%，拒绝页面响应从200ms变成20秒。服务查了半天，漏洞攻击者只发了一个HTTP请求，拒绝就干掉了整个集群。服务这不是漏洞黑客炫技，而是拒绝CVE-2023-28709这类漏洞的典型玩法。

Tomcat的服务AJP协议和HTTP/2多路复用模块里藏着几个“死穴”。比如HTTP/2的漏洞流量控制窗口处理不当，一个客户端就能把服务器内存耗光。拒绝更阴险的服务是，攻击者不需要登录，漏洞不需要传恶意文件，只要反复发送特定格式的HEAD请求，就能让Tomcat的请求解析器陷入死循环。老张那次事故，就是有人用脚本每秒发500个畸形请求，每个请求只占几KB流量，却让服务器的GC（垃圾回收）线程忙到崩溃。

这类漏洞的可怕之处在于“低门槛高收益”。你不需要什么高级工具，curl命令加个参数就能试探出目标是否中招。我做过实验，在本地搭了个Tomcat 9.0.73版本，用Python写了段20行的socket脚本，模拟HTTP/2的PING帧乱序发送。结果不到10秒，JVM堆内存占用就从200MB涨到2GB，然后服务直接假死。别以为生产环境有防火墙就安全——有些漏洞利用的是合法请求的边界条件，WAF根本拦不住。

修补方案其实不复杂。升级到Tomcat 9.0.80以上版本，或者至少把AJP连接器禁用掉（默认8009端口很多人根本没关）。但麻烦的是，不少老系统的业务逻辑依赖AJP协议，尤其是和Apache httpd整合的场景。我见过一家银行，因为内部系统用了十年前的Tomcat 7，无法直接升级，只能临时用iptables限制8009端口只允许内网访问。这种“打补丁式”的缓解措施，治标不治本。

还有个常被忽视的点——Tomcat的配置参数。很多人用默认的maxThreads=200，却不知道HTTP/2的并发流数上限是独立的。攻击者可以开启100个并发流，每个流只发半个请求头，挂起等待。这样200个线程全被占住，正常用户排队排到天荒地老。我建议把maxSwallowSize设小点，甚至直接关闭HTTP/2（如果业务不依赖的话）。别迷信“新功能一定更好”，HTTP/2的复杂状态机本身就是攻击面。

最后说句实在话，这类漏洞年年有，但真正被攻击的案例里，八成是运维没及时打补丁。Tomcat的官方安全公告页我每周都会刷一次，但凡有“DoS”字样的，当天就要评估影响范围。别等被打了才想起看日志——那会儿日志文件可能已经被攻击流量刷爆了。