HOME

Windows PDF 服务器修复 Ghostcat 与 SWEET32 漏洞实测

1960字 预计阅读时间：9.8分钟 Windows Server
文章目录18 节

这次在一台 Windows PDF 服务器上处理了两个漏洞：Tomcat AJP 端口存在 CVE-2020-1938 (Ghostcat)，Windows 远程桌面的 TLS 服务支持 DES/3DES，存在 CVE-2016-2183 (SWEET32) 风险。

业务已确认不使用 AJP 功能，因此本次采用的方法是：关闭未使用的 8009 端口，并在 Windows Schannel 中禁用 DES/3DES。两项调整已在测试环境完成验证，PDF 业务和远程桌面均正常。

适用范围

本文适用于以下场景：

  • Windows Server 上的业务系统自带 Tomcat，并监听 AJP 8009 端口。
  • 业务和软件维保已确认没有使用 AJP 转发或负载均衡。
  • 漏洞扫描在 3389 端口检出 DES/3DES 密码套件。
  • 可以安排 Windows 重启窗口，并具备本地控制台或带外管理通道。

本次现场使用的 Tomcat 目录为：

E:\apache-tomcat-6.0.29

这是本次环境的实际路径，不是 Tomcat 的固定安装位置。其他环境需要替换为实际路径。

变更前确认

在修改配置前，先完成以下检查：

  1. 业务部门和软件维保确认 AJP 模块没有使用。
  2. 确认已经取得业务验证窗口和 Windows 重启窗口。
  3. 确认本地控制台或 iLO/iDRAC 等带外入口可用，避免 Schannel 调整异常时无法通过 RDP 回退。
  4. 记录 8009 和 3389 的当前监听状态：
:: 确认 AJP 8009 是否监听
netstat -ano | findstr ":8009"

:: 确认 RDP 3389 是否监听
netstat -ano | findstr ":3389"

处理 Ghostcat: 关闭未使用的 AJP

1. 备份 server.xml

本次需要修改的文件为：

E:\apache-tomcat-6.0.29\conf\server.xml

修改前先复制一份备份，例如：

:: Tomcat 路径必须按实际环境修改
copy "E:\apache-tomcat-6.0.29\conf\server.xml" "E:\apache-tomcat-6.0.29\conf\server.xml.bak"

2. 注释 AJP Connector

在 server.xml 中找到 8009 端口对应的 AJP Connector：

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

使用 XML 注释将整个 Connector 包起来：

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

只处理 protocol="AJP/1.3" 的 Connector，不要修改 8080 或 8443 对应的 HTTP/HTTPS Connector。保存后确认文件名仍为 server.xml，没有被文本编辑器另存为 server.xml.txt。

3. 确认 Tomcat 的重启方式

这台服务器使用 HouSoft 定时执行 restarttomcat.bat。脚本的主要内容如下：

set CATALINA_HOME=E:\apache-tomcat-6.0.29
taskkill /f /t /im java.exe
call %CATALINA_HOME%\bin\shutdown.bat
ping -n 3 localhost > nul
call %CATALINA_HOME%\bin\startup.bat
exit

其中这条命令会强制结束服务器上所有 java.exe 进程：

taskkill /f /t /im java.exe

因此，不要在未盘点 Java 进程的情况下手工执行该脚本。先使用以下只读命令确认是否还有其他 Java 业务：

:: 查看所有 Java 进程
tasklist /fi "imagename eq java.exe"

:: 老版 Windows Server 可用 WMIC 查看进程路径和启动参数
wmic process where "name='java.exe' or name='javaw.exe'" get ProcessId,ParentProcessId,ExecutablePath,CommandLine

如果服务器上还有其他 Java 程序，应由业务维保确定正确的 Tomcat 停启方式，不应直接杀掉所有 Java 进程。

处理 SWEET32: 禁用 Schannel DES/3DES

本次扫描在 TCP 3389 端口检出 SWEET32。3389 是 Windows 远程桌面端口，加密能力由 Windows Schannel 提供，与 PDF 软件自身的 OpenSSL 配置不是一回事。

1. 备份 Schannel 注册表

在管理员 CMD 中执行：

:: 备份 Schannel 配置到 C:\SCHANNEL-backup.reg
reg export "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL" C:\SCHANNEL-backup.reg /y

出现“操作成功完成”后，确认 C:\SCHANNEL-backup.reg 已生成。

同时记录两个密码算法子项在变更前是否存在、Enabled 的原始值是什么。这一步是为了区分“恢复原值”和“删除本次新建的子项”：

:: 子项不存在时会提示找不到，记录该结果即可
reg query "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168"
reg query "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56/56"

2. 禁用 Triple DES 和 DES

在同一个管理员 CMD 中逐条执行：

:: 禁用 Triple DES 168
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168" /v Enabled /t REG_DWORD /d 0 /f

:: 禁用 DES 56/56
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56/56" /v Enabled /t REG_DWORD /d 0 /f

这两条命令会在子项不存在时自动创建子项，并将 Enabled 设为 REG_DWORD 0。这是 Schannel 系统级变更，会影响该服务器上所有使用 Schannel 的服务，不只是 RDP。

这是本次旧版 Windows Server 测试环境验证的方法。较新的 Windows Server 应先确认 TLS 密码套件是否由域组策略、MDM 或 PowerShell 统一管理；如果存在上级策略，本地配置可能被重新覆盖。

3. 检查写入结果

:: 两项的 Enabled 都应显示为 REG_DWORD 0x0
reg query "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168"
reg query "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56/56"

此时只能说明注册表已经写入，Schannel 需要重启 Windows 后才能完整加载新配置。

重启与验证

本次同时修改了 Tomcat 和 Schannel 配置，因此在变更窗口内重启 Windows 服务器，让两项配置一次生效。

重启前需要完成以下盘点：

  • PDF 服务、HouSoft 和 Tomcat 是否随系统自动启动。
  • 服务器上是否还有其他 Java 程序需要手工恢复。
  • PDF 上传、转换、预览和下载等关键业务的验证人员已就位。
  • 本地控制台或带外管理入口可用。

重启完成后按以下顺序验证。

1. 验证 AJP 8009

netstat -ano | findstr ":8009"

预期没有输出，表示 Tomcat 已不再监听 8009。

2. 验证 RDP 3389

netstat -ano | findstr ":3389"

预期 3389 仍处于 LISTENING 状态。再使用正常运维客户端完成一次 RDP 登录，确认远程管理正常。

部分较新的 Windows Server 支持以下 PowerShell 命令：

# 检查系统密码套件列表中是否还有 DES/3DES
Get-TlsCipherSuite | Where-Object { $_.Name -match '3DES|DES' }

这条命令只是辅助检查。如果仍列出 3DES，需继续检查本地或域组策略中的 TLS 密码套件顺序；如果提示找不到 Get-TlsCipherSuite，说明当前 Windows 版本不支持该命令。无论输出如何，都应以 3389 端口的实际握手结果或原漏洞扫描器复扫作为最终证据。

3. 验证 PDF 业务

本次测试环境的验证结果为：

验证项结果
8009 端口已停止监听
3389 端口仍正常监听
RDP 登录正常
PDF 业务正常

4. 漏洞复扫

注册表查询只能证明“已写入禁用配置”，不能单独证明 3389 已经不再接受 3DES。最终应使用原漏洞扫描器复扫，确认以下风险不再报出：

CVE-2020-1938
CVE-2016-2183
TLS_RSA_WITH_3DES_EDE_CBC_SHA

回退方法

如果 Tomcat 启动或 PDF 业务出现异常：

  1. 将备份的 server.xml.bak 恢复为 server.xml。
  2. 使用业务维保确认的方式重启 Tomcat。
  3. 确认 8009 恢复监听并重新验证 PDF 业务。

如果禁用 DES/3DES 后出现 RDP 或其他 Schannel 业务兼容问题，应根据变更前的查询结果回退：

  • 如果子项原本存在，恢复 Enabled 的原始值。
  • 如果子项是本次新建的，在本地控制台或带外管理中删除本次新建的子项：
reg delete "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168" /f
reg delete "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56/56" /f

变更前导出的文件仍应保留，可用于恢复原有的 Schannel 值：

:: 导入变更前备份的 Schannel 注册表
reg import C:\SCHANNEL-backup.reg

注意，导入 .reg 文件不会自动删除备份之后新建的子项，因此不能只导入备份就认为已完整回退。完成回退后需要再次重启 Windows，然后验证 RDP、PDF 业务和其他使用 Schannel 的服务。

实测结论

在已确认业务不使用 AJP 的前提下，注释 8009 对应的 AJP Connector 可以直接消除该端口的 Ghostcat 暴露面。在 Schannel 中禁用 DES/3DES 后，测试环境的 RDP 登录和 PDF 业务均未受影响。

需要注意，本次环境使用的 Tomcat 6.0.29 已经停止维护。关闭未使用的 AJP 解决的是本次 8009/Ghostcat 暴露问题，不代表这个 Tomcat 版本已经完成整体安全升级。后续如需升级，应使用 PDF 软件厂商提供的兼容版本或补丁，不宜直接手工替换内置 Tomcat 目录。

参考资料

Windows Tomcat 安全加固 RDP