Tomcat漏洞：别以为换个端口就安全了

2023年某电商平台被拖库，漏洞事后排查发现攻击者根本没碰什么高端0day，漏洞就用了CVE-2020-1938——那个被念叨了三年多的漏洞AJP文件读取漏洞。运维委屈，漏洞说我们明明把8080端口换了。漏洞可Tomcat默认监听8009的漏洞AJP协议还开着，攻击者直接往那个口子发个特殊请求，漏洞WEB-INF下的漏洞配置文件就乖乖交出来了。这破事每年都有人栽跟头，漏洞说明很多人对Tomcat的漏洞认知还停留在“改个端口就万事大吉”的层面。

Tomcat的漏洞漏洞其实分两类。一类是漏洞它自己的实现缺陷，比如上面说的漏洞AJP问题，本质是漏洞协议解析时没校验好属性。另一类更阴险——它作为Java Web容器，漏洞会把你部署的应用的类加载逻辑暴露出来。2017年那次RCE漏洞（CVE-2017-12615），就是利用PUT方法往服务器写JSP马。当时很多人懵了：Tomcat默认不是禁用PUT吗？对，但如果你配了readonly=false，或者用了Windows系统，斜杠处理差异就能绕过限制。这种漏洞压根不是纯Tomcat的锅，是配置和环境的组合拳。

我见过最离谱的案例是个政府网站，管理员把Tomcat的manager页面直接暴露在公网，密码还是admin/123456。攻击者登录后，用自带的部署功能上传个war包，直接拿下服务器。这不算什么技术漏洞，纯粹是管理疏忽。但Tomcat官方文档里白纸黑字写着：manager页面别对外网开放。很多人看都不看，装完默认配置就跑，不出事才怪。

真正让运维头疼的是漏洞的连锁反应。比如Log4j2那个Log4Shell漏洞爆发时，Tomcat用户特别慌——因为很多应用依赖库间接引用了log4j。你修Tomcat本身没用，得排查每个web应用里嵌套的jar包。这就像你换了大门的锁，但窗户还是破的。有些团队用自动化工具扫描，扫出来一堆“高危”，结果全是误报，反而把真正暴露的AJP端口给漏了。

说点实际的防御经验。第一，别迷信官方补丁，Tomcat版本更新频繁，但很多漏洞是配置问题，补丁根本覆盖不到。第二，用iptables或者安全组把8009、8443这些非必要端口全禁了，只留80/443。第三，如果非要用AJP，至少改成监听127.0.0.1，别对外暴露。我见过最狠的做法是有人直接把AJP协议注释掉，反正现代架构都用Nginx转发HTTP，那个协议基本是历史包袱。

最后提醒一句：别以为用Docker容器就安全了。有次我检查某个微服务集群，发现容器里的Tomcat还是默认配置，AJP端口映射到宿主机，外部网络直接能访问。容器隔离的是文件系统，不是网络风险。说到底，Tomcat漏洞大多不是天灾，是人祸——懒于改配置，疏于查端口，倦于更新版本。你把基础工作做扎实了，比装十个WAF都管用。