在Ubuntu环境下部署Tomcat，安全加固不是可选项，而是运维工作的基本起点。面对层出不穷的漏洞，一套清晰、可执行的防范清单至关重要。下面，我们就来系统梳理一下从基础加固到深度防护的关键措施。
一、基础加固与访问控制
安全始于基础。第一步，就是清理门户，收紧入口。
- 删除默认与示例应用：这是减少攻击面的首要操作。直接清理掉
CATALINA_HOME/webapps目录下的 docs、examples、ROOT、host-manager、manager 等默认应用，它们往往是攻击者最先试探的目标。 - 降权运行：切勿以 root 身份启动 Tomcat。务必创建一个专用的低权限系统用户（例如
tomcat），并确保所有 Tomcat 进程都以此用户身份运行。定期检查进程属主和文件权限，确保没有权限“膨胀”。 - 管理界面最小化：后台管理应用（manager/host-manager）是高风险点。若非必需，直接删除最为彻底。如果必须保留，务必仅分配必要的角色，设置高强度密码，并利用
RemoteAddrValve严格限制访问来源 IP，只允许受信的管理终端接入。 - 禁用自动部署：在
server.xml中，将autoDeploy和deployOnStartup属性设为false。这能防止攻击者通过上传恶意 WAR 包等方式滥用热部署功能。 - 文件与目录权限：精细化控制文件权限。logs、work、temp 等目录应仅对 tomcat 用户可写；而部署的应用目录和 Web 应用包，必须禁止全局写入权限，防止被篡改。
- 防火墙隔离：使用 UFW（Uncomplicated Firewall）等工具，严格限制暴露的端口。通常仅开放业务端口（如 8080 或 8443），并且确保后台管理端口仅在内网可达。
- 开启访问日志：启用
AccessLogValve，详细记录客户端的 IP 地址、请求方法、URL、状态码、传输字节数等信息。完整的访问日志是事后审计和攻击溯源不可或缺的依据。
二、协议与端口安全
网络层面的配置，直接决定了攻击者能接触到什么。
- 审慎处理 AJP 协议：AJP 协议历史上曾多次曝出严重漏洞（例如臭名昭著的 CVE-2020-1938 “幽灵猫”）。如果架构中没有使用 Apache 等前置袋里，建议直接在
server.xml中注释掉 AJP Connector。如果必须使用，务必设置secretRequired="true"并配置强密钥，同时将其绑定到 127.0.0.1 或特定的受控内网网段。 - 强制使用 HTTPS：明文 HTTP 传输敏感信息无异于“裸奔”。应使用 JDK 的
keytool生成或导入证书，在server.xml中配置 TLS 连接器（通常端口 8443），并确保对外只暴露 HTTPS 服务，关闭 HTTP 端口或将其重定向至 HTTPS。 - 限制 HTTP 方法：在应用的
web.xml中，将DefaultServlet的readonly参数设为true。这可以默认禁用 PUT、DELETE 等危险的 HTTP 方法，除非业务逻辑有明确需求。 - 控制连接与超时：合理设置
connectionTimeout（例如 30000 毫秒，即 30 秒），并依据服务器性能和应用负载调整maxThreads和acceptCount参数。这能有效缓解慢速攻击和连接资源耗尽的风险。
三、版本升级与漏洞处置
保持软件更新是应对已知漏洞最有效的手段。近期有几个需要重点关注的 Tomcat 漏洞：
- CVE-2025-55752（RewriteValve 路径遍历）：影响 Tomcat 11.0.0-M1 至 11.0.10、10.1.0 至 10.1.44、9.0.0 至 9.0.108 版本。修复版本为 11.0.11+、10.1.45+、9.0.109+。
- CVE-2025-61795（多部分上传临时文件清理缺陷导致 DoS）：影响范围较广，包括 11.0.0–11.0.11、10.1.0–10.1.46、9.0.0–9.0.109、8.5.0–8.5.100。修复版本为 11.0.12+、10.1.47+、9.0.110+。
升级操作需要有条不紊：
- 升级路径：在 Ubuntu 上，优先通过 APT 更新系统仓库中的 tomcat9、tomcat10 等软件包。如果官方仓库版本滞后于安全需求，则需要评估直接从 Apache 官网下载二进制包，并务必校验其 SHA-512 或 PGP 签名。
- 升级步骤：升级前，完整备份
conf、webapps、logs等关键目录。升级后，先在测试环境验证应用兼容性，并仔细检查启动日志，确保无异常报错。 - 持续关注：建立固定补丁窗口，并持续关注 Debian Security Tracker、Ubuntu Security Notices 以及 Apache Tomcat 官方安全公告，确保漏洞情报的及时获取。
四、本地提权与运行环境防护
除了远程漏洞，本地环境的安全性同样不容忽视。一个经典的案例是 CVE-2016-1240。
该漏洞源于 Debian/Ubuntu 系统打包的 Tomcat 初始化脚本（如 /etc/init.d/tomcat*）存在缺陷。脚本中以 root 权限执行了对日志文件的 chown $TOMCAT7_USER 操作，低权限用户可通过创建符号链接进行劫持，最终实现本地提权。
处置方式很明确：
- 立即将受影响的 Debian/Ubuntu 系统上的 Tomcat 包升级至已修复的版本。
- 若无法立即升级，可采取临时缓解措施：审查并修改（或注释掉）初始化脚本中相关的
chown语句。改为由系统管理员在必要时手动设置权限，避免 root 进程去操作由 tomcat 用户控制的文件路径。
五、运维与监控实践
安全是一个持续的过程，需要融入日常运维。
- 配置基线化：将
server.xml、web.xml、tomcat-users.xml等核心配置文件及其中的用户、权限、端口设置纳入版本控制系统（如 Git）。任何变更都应经过评审，确保可追溯、可回滚。 - 最小化管理面：重申一遍，管理后台应仅在内网暴露，或彻底移除。对外只提供必要的业务接口，这是原则。
- 集中化日志与告警：不仅启用访问日志和
catalina.out日志，更应将其集中收集到 rsyslog、ELK 等平台。基于日志设置告警规则，例如针对异常的 4xx/5xx 状态码、频繁的登录失败、可疑的 User-Agent 或来源 IP 进行告警。 - 定期安全巡检：定期检查是否存在弱口令、已废弃的应用、残留的临时文件或备份文件（如 .bak, .old）。对公网开放的端口和服务，应进行周期性的漏洞扫描和渗透测试。
- 应用层加固：确保 CGI Servlet 被禁用（默认如此），特别是在 Windows 环境下，这可以避免类似 CVE-2019-0232 的远程代码执行风险。对于文件上传功能，要确保上传目录没有执行权限，并对上传文件的 Content-Type、大小、后缀名进行严格校验。
说到底，Tomcat 的安全并非一劳永逸。它需要我们将这些清单中的措施，从一次性的“ checklist ”转变为持续性的“ muscle memory ”，结合主动监控和快速响应，才能构建起有效的防御纵深。
