Apache Tomcat文件包罗毛病复现(详细教程)

一、先弄清 Tomcat 里其实有两个"连接器"

很多运维同学第一次打开 conf/server.xml，都会看到两段长得很像的 Connector 配置：一段监听 8080，一段监听 8009。前者走 HTTP/1.1 协议，就是浏览器访问应用时走的通道；后者走 AJP/1.3 协议，全称 Apache Jserv Protocol，是一个二进制的定向包协议。

AJP 存在的意义是效率。同样的请求内容，用 HTTP 纯文本要传的字符多，解析成本也高；换成二进制格式后请求处理开销明显下降，所以在要做集群、做反向代理的场景里，AJP 一度是优先选项。典型的链路是这样的：浏览器先和 Apache 建立连接，Apache 通过 proxy_ajp 模块用 AJP 协议和 Tomcat 通信，再转成 HTTP 暴露给用户。这么做的原因，是相对于 HTTP 的纯文本协议，AJP 在传输上做了不少优化，某种程度上可以理解为 HTTP 的二进制版。

不过从实际生产情况看，真正用 AJP 做反代的场景并不普遍，多数人直接用 Nginx 反代 8080 就够了。这恰恰是后面"先把 8009 关掉"能成为首选加固手段的底气。

二、这个漏洞到底在说什么

这个漏洞编号 CVE-2020-1938，圈内常叫它 Ghostcat（幽灵猫）。问题出在 AJP 连接器对传入请求的处理上：AJP 协议默认没有对请求内容做足够严格的边界校验，攻击者只要能访问到这个 AJP 端口，就可以构造特定的请求参数，让 Tomcat 把 webapps 目录下任意文件的内容回显出来。

要把边界说清楚：它的能力是读取，不是执行。能被读到的包括 webapps 里的配置文件、JSP 源码，以及一些被随手放在目录下的凭据类文件。所以危害的定性是"信息外泄"，而不是"服务器被直接拿下"。

触发前提非常朴素——只要 AJP 端口能被访问到。Tomcat 装完默认就把 8009 对外监听，很多人只记得在防火墙里放行 8080，却把 8009 一起漏了出来，风险就是这么进来的。

三、影响版本对照表

官方给出的安全版本分三档，自查时对着版本即可：

Tomcat 系列	受影响情况	安全版本
6.x	全系列受影响，官方已停止维护	建议整体迁移
7.x	低于 7.0.100	7.0.100 及以上
8.x	低于 8.5.51	8.5.51 及以上
9.x	低于 9.0.31	9.0.31 及以上

查版本用两条命令就够，一个看包管理器注册的版本，一个看二进制里写死的版本：

rpm -qa | grep tomcat
/usr/share/tomcat/bin/catalina.sh version

四、在手上环境里做一次自查

先确认端口的实际监听面，这是最直观的一环：

ss -lntp | grep 8009
lsof -i :8009

再换到"外部视角"看一眼，8009 是不是真的能被连上：

nmap -p 8009 服务器内网IP

如果外部扫描结果里 8009 显示 open，说明它处在可路由的网络可达范围内，需要立刻处置。另外顺手看一眼 webapps 目录里有没有不该留在明面上的文件：

ls -l /usr/share/tomcat/webapps/
ls -l /usr/share/tomcat/webapps/ROOT/

五、四种加固方式，按推荐度排序

• 升级到安全版本：这是根治办法，把 Tomcat 升到上文表格里的对应版本，重启后复测即可。
• 直接关掉 AJP Connector：如果业务确实没用 AJP（绝大多数情况是），在 conf/server.xml 里把 8009 那一段注释掉，风险直接归零。
• 改成只监听本机：保留 8009，但把监听地址收到 127.0.0.1，外部网络再也连不进来。
• 加认证凭证：确实要在跨主机场景用 AJP 时，给连接器配上高强度的 secret，并限制来源地址。

关 AJP 的写法大致是这样，注意把原本写在一行的属性分行写好：

<!-- <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" /> -->

只监听本机的写法：

<Connector port="8009" protocol="AJP/1.3"
           redirectPort="8443" address="127.0.0.1"
           secret="换成你自己生成的一串高强度字符串" />

改完配置记得让 Tomcat 重新加载配置，重载前先在低峰时段操作，并用管理端确认旧请求已经收尾：

systemctl restart tomcat
tail -f /var/log/tomcat/catalina.out

六、配套的基础加固清单

除了针对这一个漏洞，日常还有几件事值得顺手做：

• 管理端收敛：把示例应用 manager、examples 这类带界面的目录清理掉，减少暴露面。
• 反代层只放行 8080，把 8009 一并挡在防火墙或者安全组外面。
• 日志留存：盯一下访问日志里 400、403、499 这类异常响应的突增。
• 建立跟版机制：订阅 Apache 官方安全公告，版本更新落到排期表里。

七、小结

回顾整条处置链路：先分清 8080 和 8009 各自是什么，再用 ss、lsof、nmap 确认 8009 的实际暴露面，接着对照版本表判断是否在影响范围内，最后按升级、关端口、收监听地址、加认证的顺序逐级加固。对多数只做 HTTP 反代的站点来说，把 8009 关掉这一步的性价比最高，五分钟就能做完，风险直接清掉。

需要说明的一点是，本文只做风险识别与加固方法的介绍，不含任何漏洞利用代码或攻击手法，请仅在自己拥有管理权限的服务器上按上述步骤自查与修补。

qidao123.com企服评测-应用市场 编辑提示