摘要

Exchange Server 2013 于 2023 年 4 月、Exchange 2016/2019 于 2025 年 10 月终止扩展支持后，不再接收常规安全更新。本文从 CVE 历史数据、攻击面分析和 NIST 安全框架角度，评估 EOL Exchange 服务器的安全态势，提出分层防御策略与应急补丁方案。全文引用 NIST SP 800-45（邮件安全指南）、NIST SP 800-53（安全与隐私控制）和 Microsoft Security Response Center（MSRC）公开数据。

1. Exchange Server CVE 历史趋势（2019–2025）

Exchange Server 在 2019–2025 年间累计披露了超过 120 个 CVE，年度分布呈现显著波动：

年份	严重 (CVSS ≥9.0)	高危 (7.0–8.9)	中低危 (<7.0)	总数	代表性漏洞
2019	1	6	5	12	CVE-2019-1373 远程代码执行
2020	2	8	7	17	CVE-2020-16875 远程代码执行
2021	6	12	8	26	CVE-2021-26855 (ProxyLogon) / CVE-2021-27065
2022	3	11	10	24	CVE-2022-41040 (ProxyNotShell)
2023	2	9	8	19	CVE-2023-21709 特权提升
2024	3	10	6	19	CVE-2024-26198 远程代码执行
2025	1	7	5	13	仅在扩展支持周期内（EOL 前）发布

2021 年 ProxyLogon/CVE-2021-26855 事件是 Exchange Server 安全史上影响最大的攻击。该漏洞组合（CVE-2021-26855 SSRF + CVE-2021-27065 任意文件写入）允许未经身份验证的攻击者在 Exchange 服务器上以 SYSTEM 权限执行代码，HAFNIUM 威胁组织自 2021 年 1 月起对其进行在野利用。微软于 2021 年 3 月 2 日发布紧急带外补丁，但在此之前已有超过 3 万台 Exchange 服务器被攻破。

2. 停更后的攻击面分析

2.1 持续扩大的攻击面

EOL 后不接收安全更新，攻击面随新漏洞发现而持续扩大。关键攻击面包括：

• OWA/ECP 前端接口： HTTPS 443 暴露面最大，历史上 ProxyLogon/ProxyNotShell 均通过 OWA 前端实现初始突破。
• EWS（Exchange Web Services）： SOAP 端点承载邮件/日历/联系人 API，CVE-2021-26855 利用的就是 EWS 虚拟目录。
• Autodiscover 服务： 对外暴露的自动发现接口可被利用进行信息收集与 SSRF 攻击。
• SMTP 接收连接器： 对外暴露端口 25，历史上存在 SMTP 协议栈级别的远程代码执行漏洞。
• PowerShell Remoting (WinRM)： 内部管理通道，一旦攻击者获取初始访问权，可用于横向移动。

2.2 CVE-2021-26855（ProxyLogon）攻击链回顾

ProxyLogon 是理解 Exchange EOL 安全风险的最佳案例。攻击链路如下：

1. 攻击者 → 构造恶意 HTTP 请求 → Exchange OWA 前端
2. CVE-2021-26855 (SSRF) → 伪造服务器端身份验证 → 访问后端 EWS
3. CVE-2021-27065 → 写入 Web Shell 至 OWA 目录 → 持久化
4. CVE-2021-26857 → 反序列化漏洞 → SYSTEM 权限代码执行
5. CVE-2021-26858 / CVE-2021-27078 → 任意文件写入 → 进一步横向移动

关键教训：Exchange 的攻击链通常涉及多漏洞组合。EOL 系统面对新漏洞时，无法获得完整的修复链条，单一漏洞即可导致全系统沦陷。

3. 分层防御策略

NIST SP 800-45 §4 建议邮件系统采用纵深防御模型。对 EOL Exchange 服务器，推荐以下分层架构：

3.1 第 1 层：网络边界安全

• WAF（Web 应用防火墙）： 在 Exchange OWA/ECP 前端部署 WAF，启用 OWASP 核心规则集（CRS），阻断 SSRF、路径遍历、反序列化等攻击模式。推荐规则：ModSecurity CRS + 自定义 Exchange 专用签名。
• 反向代理过滤： 使用 NGINX 或 HAProxy 在 Exchange 前端建立反向代理层，实施 URL 白名单——仅允许已知 Exchange 合法路径（/owa/, /ecp/, /ews/, /mapi/, /autodiscover/, /microsoft-server-activesync/），拒绝其他路径请求。
• IP 白名单： 如业务允许，限制 443 端口的来源 IP 范围。

NGINX 反向代理参考配置：

# 仅允许 Exchange 合法虚拟目录
location ~ ^/(owa|ecp|ews|mapi|autodiscover|Microsoft-Server-ActiveSync)/ {
    proxy_pass https://exchange_backend;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
}
location / {
    return 403;
}

3.2 第 2 层：主机安全

• Windows Defender / EDR： 启用实时保护与攻击面减少（ASR）规则，特别是"阻止 Office 应用程序创建子进程"和"阻止从 Windows 本地安全认证子系统（lsass.exe）盗窃凭据"。
• 应用程序控制（WDAC）： 限制 IIS 工作进程（w3wp.exe）和 Exchange 进程的子进程创建。
• 凭据保护： 启用 Credential Guard 与 Remote Credential Guard，防御凭据窃取。

3.3 第 3 层：应用层安全

• 扩展保护（Extended Protection）： 启用 Exchange Server 扩展保护（KB5017260），强制要求 Channel Binding Token (CBT)，防御 NTLM 中继攻击。
• 证书吊销检查： 确保 Exchange 启用客户端证书吊销检查。
• 最小权限原则： Exchange 服务账户不应具有域管理员权限；使用 RBAC 组限制管理角色。

4. 应急补丁策略

EOL 后不接收常规安全更新，组织需建立应急补丁流程：

4.1 ESU 方案

Microsoft 为 Exchange 2016/2019 提供了 ESU（Extended Security Update）方案，允许已注册的组织在扩展支持终止后继续接收安全更新。截至 2025 年 10 月，ESU 覆盖 2016 CU23 和 2019 CU15。关键条件：

• 必须在扩展支持终止前完成 ESU 注册与密钥激活
• 仅覆盖标记为"Critical"和"Important"的安全更新
• 不提供技术支持与非安全热修复

4.2 应急缓解脚本

当漏洞公开但官方补丁未及时发布时（如 ProxyLogon 期间微软发布 EOMT），应急缓解措施包括：

# 禁用 OWA 虚拟目录（紧急情况下的临时措施）
Remove-OwaVirtualDirectory -Identity "EXCH01\owa (Default Web Site)" -Confirm:$false

# 通过 IIS 限制 ECP 访问仅允许内网
# 在 IIS 管理器中为 ECP 虚拟目录添加 IP 和域限制规则

# 使用 ExchangeMitigations.ps1 应用已知漏洞缓解
# 引自 Microsoft Exchange On-Premises Mitigation Tool (EOMT)

5. NIST 框架下的合规性影响

NIST SP 800-53 控制项 SI-2（缺陷修复）要求组织在合理时间窗口内安装安全补丁。EOL 系统不接收厂商补丁，无法满足 SI-2 控制要求。NIST SP 800-45 §4.2 指出："邮件服务器应运行在供应商支持的版本上，并及时安装安全更新。"

对受监管行业（金融、医疗、政府），运行 EOL 邮件服务器可能构成合规违规。等保 2.0（GB/T 22239-2019）对邮件系统的安全计算环境、安全区域边界均要求及时漏洞修补。EOL Exchange 无法满足三级等保的测评要求。

6. 从 Exchange 迁移的安全收益

从安全角度看，从 EOL Exchange 迁移至持续维护的邮件系统带来以下安全提升：

• 供应商主动漏洞管理与定期安全补丁发布
• 现代 TLS 1.3 支持与密码套件更新
• 可审计的开源代码基础（针对开源 MTA）
• 与云原生安全工具链（SIEM、SOAR）的原生集成
• 更细粒度的 RBAC 与租户隔离