Beyond the patch: Protecting your NetScaler gateway against future vulnerabilities

总有一个零号病人：在补丁之前保护NetScaler网关 | Cloudflare博客

post

WAF

零信任

Cloudflare Access

安全

漏洞

2026年10月19日

补丁之外：如何防范未来针对NetScaler网关的攻击

Grant Bourzikas 和 Kenny Johnson

10分钟阅读

复制链接

近期披露的Citrix NetScaler重大漏洞揭示了一个普遍存在的薄弱环节：登录页面是攻击者可利用的入口点，能够入侵并访问应用服务器。事实上，此次披露的漏洞中包含一个正在被利用的缺陷，攻击者无需登录即可在受影响的网关上执行命令。与任何紧急补丁一样，管理员必须在切断或中断用户访问与延迟关键安全更新的风险之间做出权衡。

如果你是NetScaler用户且尚未修补实例，请立即停止阅读并执行修补。这是一个非常严重的漏洞。完成修补后，我们将探讨如何通过部署额外的安全控制措施，避免未来再次陷入类似困境。

此问题的影响范围超越NetScaler，适用于任何可通过互联网访问的内部应用。远程桌面门户、管理控制台及其他公开的认证页面都应接受同等程度的审查：目标用户是否需要不受限制的互联网访问权限？攻击者能否绕过认证检查直接访问应用服务器？

Citrix已发布软件更新以修复该漏洞，Cloudflare也在10月1日推出了紧急的Web应用防火墙（WAF）规则。但补丁的存在并不能保证绝对安全：每个实例都必须被识别、更新并测试。在生产环境中部署更新过程非常痛苦——可能导致停机或影响员工在更新期间对桌面的访问需求。对于依赖远程桌面用户的服务（如客户、患者等），他们根本不会关心你的安全补丁。

使用Web应用防火墙（WAF）可以在补丁全面部署前争取更多时间，但这种防护是被动的，无法应对未来新发现的攻击方式。Cloudflare及其他安全厂商虽尽力覆盖各种变体和类似攻击，但人工智能正在加速攻击者发现新型攻击方式的速度。这就是为什么必须构建纵深防御体系，确保任何特定的软件缺陷或攻击手段都不会引发关键安全问题。

Cloudflare通过访问策略、Web应用安全防护和限制源连接等手段，在新漏洞披露前就保护认证服务。访问控制限制可访问应用服务器的人员范围；WAF检测评估网络请求中的攻击特征；源连接限制防止直接连接绕过这些防护。这些措施无需等待新攻击特征或替换现有桌面平台即可降低暴露风险。

NetScaler漏洞利用

Citrix 2026年9月27日发布的安全公告报告称，已观察到对CVE-2026-88771和CVE-2026-88772漏洞的利用。第一个漏洞允许攻击者在受影响的设备上执行未认证的命令，包括默认配置场景。第二个漏洞影响使用数据报传输层安全协议（DTLS）的配置。10月3日和10月8日发布的后续公告进一步披露了SAML配置中的其他漏洞。这些漏洞使攻击者能够执行任意脚本并发起拒绝服务攻击。

CISA的警报和Mandiant的技术分析报告对这些漏洞、观察到的利用行为及响应指导进行了更详细的说明。如需了解现有Web应用防护的细节，请参阅Cloudflare针对CVE-2026-88771的紧急WAF发布。

在典型的Citrix部署中，用户通过NetScaler网关进行身份验证，网关随后使用安全票据授权机制连接到StoreFront。StoreFront会展示该用户可访问的应用和桌面。本地安装的Citrix应用会利用这些信息，通过Citrix独立计算架构（ICA）协议建立独立连接。网关会在代理桌面连接前验证票据。Citrix将这些流程描述为连接工作流的独立阶段。整个攻击的根本原因在于网关必须在互联网上公开可访问，否则用户将无法发起桌面连接。

将访问决策前置到认证服务器

在完成所有实例补丁更新后，最佳做法是将任何公开可访问的登录页面或应用置于单点登录（SSO）之后，确保请求在到达目标服务器前即通过访问控制。Cloudflare Access可以在请求抵达现有网关服务器前实施独立的访问策略。Citrix环境仍负责确定用户可启动的桌面并验证生成的票据。这种额外的边界确保攻击者永远无法接触到网关服务器尝试运行特定攻击。他们将只能看到Cloudflare Access的登录页面。

这一决策不再依赖于识别攻击特征并进行阻断，而是基于零信任策略集判断用户是否本应存在于该位置。类似攻击将越来越多，因此在整个网络中采用零信任控制措施是您下一步最重要的行动。

这遵循了Cloudflare自身架构中描述的"客户零"原则：降低暴露面并使用独立防御机制，确保单一漏洞不会导致整体妥协。实际的起点是用户进入应用前首先访问的服务。

网络认证与桌面传输的逻辑隔离。网关角色可能运行在同一设备上。

保护Web认证路径会在现有Citrix控制机制前增加一道边界。这不会自动将该边界扩展到其他网关服务（包括启用DTLS的监听器）。这些接口仍需单独进行暴露面评估和适用的安全更新，即使它们支持的桌面会话已要求认证。

原始连接必须强制实施相同边界

更改 DNS 记录和实施访问策略并不足以提供全面防护。如果攻击者能够连接到原始地址或备用主机名，他们就可以绕过设置的控制措施。访问策略强制要求使用特定主机名：如果认证服务器可以通过 IP 地址或备用主机名访问，那么访问策略的实施将形同虚设。必须采取措施确保所有流量都来自经过访问系统验证的请求。根据内部架构的不同，有几种不同的实现方式。

Cloudflare Tunnel 是最常用的方法。它从应用服务器建立仅出站的隧道，允许你关闭所有入站 IP 流量。这意味着服务器将不再拥有可被任何人访问的公网 IP。

当必须保留公网源 IP 地址或无法运行连接器软件时，网络限制和源认证需要对接受的连接进行约束。例如，专用 CDN 出站 IP 会为账户分配专用源地址，用于 Cloudflare 到源站的流量。应用服务器的防火墙可以允许这些地址并拒绝其他来源。这使得网络限制特定于账户流量，而不是广泛允许来自 Cloudflare 共享地址范围的流量。

认证源拉取可以通过双向 TLS 进一步增强对 Cloudflare 到源站连接的验证。

如果源站支持，还可以验证 Access JSON Web Token，包括其签名、签发者、过期时间以及预期的应用受众。这是确保请求经过访问系统认证的最佳方式。

如果不确定从哪里开始，可以联系 Cloudflare 专家，审查你的架构并确定适合你环境的控制措施。

保护面向 Web 的认证服务

Cloudflare Access 确定哪些用户可以访问 Web 应用；Cloudflare 的 Web 应用防火墙（WAF）会检查对同一受保护服务的 HTTP 请求。WAF 在任何访问认证检查之前运行，使你能够完全阻止已知恶意 IP、特定国家、ASN 或其他你明确知道不应访问应用的属性。防火墙持续运行在所有请求上，还会识别成功认证的用户尝试运行具有已知 CVE 签名的漏洞利用。

除了管理的 CVE 签名外，WAF 攻击评分使用机器学习来识别不完全匹配已知规则的潜在恶意请求。管理员可以使用该评分在规则中阻止或挑战请求。WAF 攻击评分由 Cloudflare 全球网络流量的网络观察和 Cloudforce One 调查信息流提供支持，后者是 Cloudflare 的共享威胁情报平台。

拥有 Cloudforce One 威胁情报订阅的客户还可以在 WAF 策略中使用实时威胁指标。这可以将已知恶意来源的上下文信息与请求本身的检查结合起来。

减少暴露并不能移除已经取得立足点的攻击者。认真对待：如果你尚未这样做，请立即修补系统，并遵循 Citrix 的疑似入侵指导。他们详细说明了如何保留证据、撤销凭证和证书、调查连接的系统，并从已知的良好状态进行重建或恢复。

将零信任扩展至桌面访问或移除桌面依赖

保护网络身份验证可以作为初始步骤，而无需将其作为最终架构。Cloudflare 的虚拟桌面零信任架构也支持对桌面基础设施本身进行访问控制。通过 Cloudflare One 客户端和私有网络连接，团队可以限制哪些用户和设备能够访问承载桌面流量的端点，包括现有的独立计算架构（ICA）路径。这需要独立的路由和策略设计；仅靠浏览器身份验证代理本身无法实现该功能。

某些工作流程可以完全移除 ICA 依赖。对于支持的 Windows 工作负载，Cloudflare 的基于浏览器的远程桌面访问可通过 Cloudflare Tunnel 连接到 Windows 主机，无需本地远程桌面客户端。如果用户仅需通过桌面打开 Web 应用，访问和浏览器隔离功能可以替代该 Web 访问场景，无需完整的虚拟桌面。

首先保护身份验证服务和现有桌面连接。然后逐步替换仅用于 Web 访问的虚拟桌面，并将支持的 Windows 工作流程迁移至基于浏览器的远程桌面。减少暴露风险无需等待完整的桌面迁移完成。

确定哪些认证服务需要公开访问

这一评估原则不仅适用于虚拟桌面。员工门户或管理控制台可能需要被授权用户从任何位置访问，而无需接受所有用户的申请请求。

并非所有认证页面都需要预先验证员工身份。消费者登录页面和用于建立初始会话的身份提供商端点可能需要保持公开可访问。应有针对性地保护这些服务，避免引入循环认证依赖。关键在于将可访问性作为设计决策，而非默认继承的配置。

从一个受限服务开始。将 Web 和非 Web 路径映射到该服务中，然后将访问决策置于其认证界面之前。在扩大部署前，验证自身环境中的边界：

• 在未登录的情况下请求受保护的主机名。确认请求在 Cloudflare 停止，而非到达源站。

• 使用测试账户（不属于授权组）登录。确认仍无法访问受保护的应用。

• 测试直接源站地址和备用主机名。确认无一能绕过访问策略。

• 以授权用户身份登录。确认认证、桌面启动和会话重连功能仍正常运作。

检查相关策略、防火墙和源站日志，而非仅依赖浏览器显示内容。当路由、身份或故障转移设置发生变更时，重复这些检查，确保下一次配置更新不会悄悄重新开放已关闭的路径。

整合控制措施

完整架构将访问决策、Web 检查和可用性控制置于 NetScaler 前端，并对连接源站的流量实施限制。公共源站和 Tunnel 路径是可选方案。原生桌面连接保持独立，该流量周围可选配零信任网络访问层。

逻辑参考架构，而非客户部署方案或严格的处理顺序。可选控制功能需要适当的配置和权限。源端令牌验证补充了上游限制，但不会取代它们。

入门

与Cloudflare专家联系，为您的环境规划合适的控制措施。下载解决方案简介并注册即将举行的网络研讨会。

Andrei Migia、Nathan Sackett 和 Doug Shepherd 贡献了本文。

目录列

讨论列

相关标签及社交媒体链接

相关标签

在社交媒体上关注

• Cloudflare

• Grant Bourzikas

• Kenny Johnson

电子邮件注册