Tomcat漏洞扫描：别让你的漏洞中间件变成筛子

凌晨两点，某电商平台的扫描告警群里炸了锅。运维老张盯着屏幕上跳动的漏洞红色警告——后台管理接口被连续爆破，日志里密密麻麻的扫描401响应码像一串串绝望的敲门声。事后排查发现，漏洞攻击者利用的扫描正是Tomcat 8.5.51版本里那个臭名昭著的AJP文件读取漏洞（CVE-2020-1938）。这个漏洞，漏洞只需要一条精心构造的扫描HTTP请求，就能读取服务器上任意文件，漏洞甚至能直接上传webshell。扫描

Tomcat作为Java生态里最常见的漏洞Web容器，几乎成了企业级应用的扫描标准配置。但越是漏洞普及的东西，越容易被忽视。扫描很多团队把应用代码的漏洞安全测试做得滴水不漏，却对底层的中间件放任不管。这就像把家门锁得严严实实，却任由地下室窗户敞开着——攻击者根本不需要走正门。

我见过太多真实案例了。某金融机构的运维手册里，Tomcat版本还停留在7.0.47，官方早在2017年就停止维护了。问起来，负责人一脸无奈：“系统跑得好好的，谁敢动啊？”结果呢？去年等保测评时，安全工程师用几行Python脚本就复现了反序列化攻击，直接拿到了服务器权限。那一刻，所有人的脸色都很难看。

扫描Tomcat漏洞，绝不是跑个Nessus扫一遍就完事。真正的检测要分三层看：版本层——比对当前版本与官方CVE库，找出已知漏洞编号；配置层——检查是否开启了不必要的manager接口、AJP连接器是否暴露在公网、默认端口8005是否被访问控制；行为层——通过发送畸形请求或探测特定路径，观察响应差异，判断是否存在逻辑缺陷。比如CVE-2020-1938的检测，就要尝试通过AJP协议发送包含特定属性的请求，看看能不能读到/WEB-INF/web.xml的内容。

工具选择上，别迷信那些动辄几十万的商业平台。开源方案完全可以打出一套漂亮的组合拳：用sqlmap的--tomcat模块做基础版本探测，配合vulhub的漏洞镜像环境验证攻击路径，再用OWASP ZAP的主动扫描规则集做深度渗透。记得把扫描频率调到非业务高峰时段，否则误报和性能损耗会让你被业务部门追着骂。

有个细节很多人会忽略：Tomcat的日志文件catalina.out里藏着大量攻击痕迹。扫描前先翻翻日志，如果发现异常IP反复访问/manager/html路径，或者出现类似“javax.servlet.ServletException”的堆栈错误，那基本可以断定已经有人在试探了。这时候的扫描就不是预防性的，而是救火式的——先隔离，再排查，最后修补。

修补本身也不轻松。升级版本是最直接的，但大型系统往往依赖特定Tomcat版本的类加载机制，贸然升级可能引发兼容性灾难。更务实的做法是：关闭不必要的连接器，给管理端加IP白名单，用防火墙限制AJP端口只对内部开放。这些配置层面的加固，往往比升级版本更立竿见影。

说句掏心窝的话，Tomcat漏洞扫描不是一次性的项目，而是持续对抗的过程。每季度做一次全量扫描，每次代码上线前做增量检测，遇到高危漏洞先评估影响面再决定修复策略。这活儿确实枯燥，但真出了事，你连后悔的时间都没有。毕竟，中间件一旦被攻破，你引以为傲的代码安全，不过是攻击者眼中的一层薄纸。