CVE-2017-12615漏洞修复与配置审计：从1个高危参数到5项安全加固实践

Tomcat安全加固实战：从CVE-2017-12615到企业级防护体系

1. 漏洞背景与核心风险

2017年曝光的CVE-2017-12615漏洞揭示了Tomcat在Windows环境下可能面临的重大安全威胁。当服务器配置了readonly=false参数时，攻击者可通过精心构造的PUT请求实现任意文件上传，进而获取服务器控制权。

漏洞本质源于两个关键因素：

1. DefaultServlet默认处理PUT/DELETE请求
2. Windows文件系统特性允许特殊字符绕过后缀检测

受影响版本包括Apache Tomcat 7.0.0至7.0.81，但实际影响范围可能更广。企业环境中常见的风险场景包括：

• 开发测试环境使用默认配置
• 运维人员为方便文件管理临时开启写权限
• 历史遗留系统未及时更新安全配置

2. 漏洞深度解析与技术原理

2.1 请求处理机制分析

Tomcat对HTTP请求的处理流程如下：

HTTP请求 → 前端控制器 → 匹配Servlet → 调用对应方法(PUT/GET等)

关键Servlet的职责划分：

2.2 漏洞触发条件

必须同时满足三个条件：

1. 运行在Windows平台（Linux需其他绕过方式）
2. web.xml中配置<param-name>readonly</param-name><param-value>false</param-value>
3. 攻击者能够访问Tomcat管理端口

典型攻击流程：

1. 扫描发现开放8080端口的Tomcat服务
2. 检查OPTIONS响应头是否包含PUT方法
3. 构造特殊文件名绕过检测：
   • shell.jsp%20
   • shell.jsp::$DATA
   • shell.jsp/

2.3 安全配置审计要点

检查conf/web.xml中是否存在以下危险配置：

<init-param> <param-name>readonly</param-name> <param-value>false</param-value> <!-- 高危配置 --> </init-param>

3. 五维加固方案与实践

3.1 基础防护：禁用危险方法

操作步骤：

1. 定位conf/web.xml中的DefaultServlet配置
2. 确保readonly参数为true或完全移除该配置
3. 添加以下安全限制：

<security-constraint> <web-resource-collection> <url-pattern>/*</url-pattern> <http-method>PUT</http-method> <http-method>DELETE</http-method> </web-resource-collection> <auth-constraint/> </security-constraint>

注意：修改后需重启Tomcat服务使配置生效

3.2 版本升级与补丁管理

官方修复版本对照表：

升级建议流程：

1. 备份现有配置和应用
2. 下载官方安全版本
3. 验证新版本兼容性
4. 灰度部署观察业务影响

3.3 虚拟主机安全隔离

通过server.xml配置实现应用隔离：

<Host name="example.com" appBase="webapps/example" unpackWARs="true" autoDeploy="false"> <Context path="" docBase="/path/to/safe/dir" /> <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="192.168.1.*" /> </Host>

关键参数说明：

• autoDeploy="false"禁止自动部署
• unpackWARs="true"强制解压WAR包
• docBase指向非默认目录

3.4 权限最小化实践

Linux系统层防护：

# 创建专用用户组 groupadd tomcat_grp useradd -g tomcat_grp -s /bin/false tomcat_user # 设置目录权限 chown -R tomcat_user:tomcat_grp /opt/tomcat chmod -R 750 /opt/tomcat find /opt/tomcat/webapps -type d -exec chmod 2750 {} \;

Tomcat启动参数优化： 在catalina.sh中添加：

export CATALINA_OPTS="$CATALINA_OPTS -Djava.security.egd=file:/dev/./urandom" export UMASK="0027"

3.5 纵深防御体系建设

网络层防护：

• 使用iptables限制管理端口访问

  iptables -A INPUT -p tcp --dport 8080 -s 192.168.1.0/24 -j ACCEPT iptables -A INPUT -p tcp --dport 8080 -j DROP

应用层监控：

1. 配置log4j记录所有PUT请求
2. 部署OSSEC监控web目录变化
3. 定期审计webapps目录文件哈希值

应急响应方案：

graph TD A[发现异常请求] --> B[立即阻断源IP] B --> C[备份当前现场] C --> D[检查web.xml配置] D --> E{确认入侵?} E -->|是| F[下线受影响节点] E -->|否| G[加强监控] F --> H[全面安全审计]

4. 企业级安全加固清单

提供可直接执行的检查项：

1. 配置审计

   • [ ] 确认readonly=true
   • [ ] 禁用PUT/DELETE方法
   • [ ] 关闭autoDeploy

2. 系统加固

   • [ ] 使用非root用户运行
   • [ ] 设置umask 0027
   • [ ] 限制JSP执行目录

3. 监控方案

   • [ ] 部署文件完整性监控
   • [ ] 启用访问日志审计
   • [ ] 设置异常请求告警

4. 应急准备

   • [ ] 备份安全配置模板
   • [ ] 准备干净版本安装包
   • [ ] 建立回滚流程

5. 持续安全运维策略

配置模板管理： 维护标准化的安全配置模板库，包含：

• 安全版web.xml
• 加固版server.xml
• 权限控制脚本

自动化检查工具： 使用Ansible实现批量检测：

- name: Check Tomcat security config hosts: tomcat_servers tasks: - name: Verify readonly parameter shell: grep -A1 "readonly" {{ tomcat_home }}/conf/web.xml | grep -q "true" register: readonly_check failed_when: readonly_check.rc != 0

安全演进路线：

1. 短期：漏洞修复+基础加固
2. 中期：建立安全配置基准
3. 长期：实现DevSecOps流程

在实际运维中，我们曾遇到因业务需要必须开放PUT方法的情况。此时可采用折中方案：通过Nginx前置过滤，只允许特定URL路径的PUT请求，同时配合严格的权限控制和文件类型检查。这种平衡安全与业务需求的做法，往往比简单粗暴的禁用更可持续。