使用 NGINX Plus 快速轻松地缓解安全漏洞

在 NGINX，我们很自豪，因为世界各地有数以百万计的组织信任我们的软件来支持他们的网站和应用交付基础设施。 考虑到我们的用户对 NGINX 的依赖程度，我们很惊讶他们承认他们并没有认真考虑运行最新版本的重要性，该版本修复了当今互联网上常见的安全漏洞（如常见漏洞和暴露 (CVE)）。

当然，仅仅考虑防范安全威胁是不够的——您需要实施明确的流程来追踪漏洞并在漏洞出现时立即采取保护措施。 如果你必须自己完成所有工作，那么你很容易低估需要花费多少时间和精力，就像开源软件的情况一样。 事实上，快速轻松地保护自己免受安全威胁是 NGINX Plus 等商业支持软件的一个经常被忽视的好处。

在这篇博客中，我们探讨了保护开源软件所面临的挑战，并解释了 NGINX Plus 如何更快、更轻松地缓解 CVE 和其他安全威胁。

处理开源软件中的漏洞

尽管所有开发人员都认为他们编写的代码是完美的，但没有软件是没有错误的。 作为严格的质量合规流程的一部分，开发人员希望大多数错误在开发过程中就能被发现，只有少数错误会在应用程序的整个生命周期中正常使用时出现。最糟糕的情况是，这些错误会被心怀不轨的恶意用户发现。

当您使用多种开源工具、编程语言和平台构建应用堆栈时，错误的后果会大大加剧。 您需要分别检查每个组件以验证其没有错误。 当在开源软件中发现错误时，重要的是制定一个明确的策略来验证、测试和（如果可能）修复它们。

您的开源软件政策至少需要包括三个流程：

1. 定期检查和测试
2. 跟踪漏洞并内部报告
3. 及时修复漏洞

报告漏洞

当发现安全漏洞时，有一个标准的披露事件序列。 第一步是向软件的作者或供应商提交一份详细的报告。 报告者和作者共同决定如何以及何时披露漏洞，通常以通用漏洞和暴露(CVE) 数据库中记录的形式。 按照惯例，作者在披露之前有 90 天的时间来解决该问题，但可以协商延长时间。

NGINX 和 CVE

作为开源软件提供商和商业软件供应商，NGINX 积极参与影响NGINX Open Source和NGINX Plus 的CVE 和其他漏洞的报告和修复过程，以及其其他商业产品（在撰写本文时包括 NGINX Controller [现为F5 NGINX Management Suite ] 、 NGINX App Protect和NGINX Ingress Controller ）以及免费和开源产品，包括NGINX Service Mesh 、 NGINX Unit和NGINX Amplify 。

NGINX 开源的用户受益于 NGINX Plus 基于它的事实，因为我们致力于为 NGINX Plus 客户提供企业级支持和流程标准。 这些标准包括我们与客户签订的服务水平协议 (SLA)，规定了补丁必须遵循的错误修复和测试程序，包括核心软件、依赖项和支持的模块。 SLA 可帮助客户实现法规遵从，从而最大限度地降低遭受漏洞攻击的风险。

NGINX 开源的另一个问题是许多第三方技术利用它并将其嵌入到他们的产品中。 这些技术的提供商有自己的流程来披露和修补发现的软件漏洞。 正如我们在下一节中讨论的那样，我们发布的 NGINX 开源补丁和第三方技术相应补丁的发布之间有时会有相当大的滞后。

NGINX Plus 如何保护用户免受漏洞攻击

在介绍中我们提到，NGINX Plus 的一个经常被忽视的好处是它可以让我们的客户更快、更轻松地保护自己免受漏洞攻击。 处理开源软件中的漏洞可能比许多人想象的要耗费更多时间，因此成本也更高。

在以下部分中，我们将讨论 NGINX Plus 用户更快、更轻松地解决漏洞的五种具体方法。

NGINX 主动向 NGINX Plus 订阅者通知补丁信息

当我们为 NGINX 开源和 NGINX Plus 发布安全补丁时，我们会通过电子邮件主动通知 NGINX Plus 客户。 我们还发布博客宣布大多数补丁的可用，但我们无法直接联系 NGINX 开源用户。 这就给他们带来了监控 CVE 和其他漏洞数据库以及定期检查我们博客的负担。

F5 SIRT 为受到攻击的 NGINX Plus 用户提供实时帮助

当 F5 客户（包括 NGINX Plus 用户）遭受攻击时， F5 安全事件响应团队(SIRT) 会提供实时帮助。 SIRT 可以快速有效地缓解攻击并让您恢复正常运行。 即使攻击停止后，他们仍会继续与您合作——他们“超越所报告的事件，以减少对您组织的整体伤害，并了解、预测和阻止未来的威胁”。

NGINX App Protect 加强application保护

NGINX App Protect是一款企业级 Web应用防火墙 (WAF)，由 F5 20 年的安全经验提供支持，并作为 NGINX Plus 动态模块部署。 它通过特定于应用的保护增强了 NGINX Plus 的第 7 层安全性，以防御后端应用服务器中的更多 CVE。 NGINX 和 F5 致力于提供与特定攻击活动相关的签名。 结果如何？ NGINX App Protect 使 NGINX Plus 用户无需构建自己的签名并处理多个误报。

NGINX Plus 支持基于 JWT 和 OpenID Connect 的身份验证

即使没有需要修补的特定漏洞，复杂的身份验证协议也有助于防止不良行为者访问您的应用程序和基础设施。 除了 NGINX Open Source 中提供的方法之外，NGINX Plus 还支持基于JSON Web Token (JWT) 和OpenID Connect 的身份验证，适用于Web和API客户端。

NGINX Plus 订阅者立即获得补丁

如报告漏洞中所述，当漏洞影响 NGINX 软件时，我们通常会在其作为 CVE 公开披露之前收到通知。 提前警告使我们能够在公开披露之前准备好补丁，并且我们通常会在披露当天（或在某些情况下几天内）发布补丁。 该修复程序以修补二进制文件的形式提供给 NGINX Plus 客户。 它以修正的源代码和支持的操作系统的修补二进制文件的形式提供给 NGINX 开源用户，但如上所述，我们无法直接通知 NGINX 开源用户。

利用或嵌入 NGINX 开源的第三方技术可能在漏洞披露之前并没有意识到该漏洞。 即使他们这样做了，我们的经验是他们的补丁可能会比 NGINX 补丁落后几个月。 这是可以理解的，特别是对于通常由志愿者维护的开源软件而言，但在漏洞公开披露后，您的基础设施将得不到保护，容易受到黑客的利用。

例如，2018 年秋季发现了两个有关 HTTP/2 漏洞的 CVE（ CVE-2018-16843和CVE-2018-16844 ）。 作为回应，我们对NGINX Plus R16和 NGINX Open Source 1.15.6 应用了安全补丁。 流行的 OpenResty 软件基于 NGINX 开源软件，提供 NGINX Plus 中的部分功能，该软件于 2019 年 3 月 3 日首次发布了包含这些补丁的候选版本，这比 NGINX 发布补丁整整晚了 4 个月。基于 OpenResty 构建的解决方案通常需要更长的时间来修补其代码库。

有时，漏洞的状态并不清楚，或者软件提供商认为即使漏洞构成潜在的攻击媒介，也没有必要进行修补。 2020 年，使用最广泛的开源 WAF 软件 ModSecurity 就曾出现过这种情况。 维护OWASP ModSecurity 核心规则集(CRS) 的团队发现，ModSecurity v3 对正则表达式进行全局匹配的方式可能导致 OWASP CRS 团队所认为的拒绝服务漏洞( CVE-2020-15598 )。 维护 ModSecurity 本身的组织 Trustwave对该行为是否属于安全问题提出异议，并拒绝发布补丁。

NGINX ModSecurity WAF是基于 ModSecurity v3 构建的 NGINX Plus 动态模块。 NGINX 团队认为CVE-2020-15598中描述的行为很有可能导致 DoS 漏洞，因此我们于 2020 年 9 月发布了补丁。 正如我们在宣布补丁的博客中所解释的那样，开源 ModSecurity 版本的用户（包括 NGINX 开源用户）必须自行决定是否应用来自 OWASP CRS 团队的补丁，或者继续使用 Trustwave 未打补丁的软件并可能实施 Trustwave 提出的缓解更改。

[编辑– NGINX ModSecurity WAF 于2022 年 4 月 1 日正式停止销售，并将于2024 年 3 月 31 日停止使用。 有关更多详细信息，请参阅我们博客上的“F5 NGINX ModSecurity WAF 正在过渡到终止使用<.htmla>”。]

结论

在当今竞争日益激烈的商业环境中，软件团队面临着尽快提供新的和更新的代码以提供最具创新性的服务的压力。 与此同时，针对基础设施和应用的复杂攻击日益增多，使得追踪漏洞并尽快缓解威胁变得至关重要，这是一项繁琐且耗时的工作。

NGINX Plus 订阅减轻了这一负担，使应用团队能够专注于他们的主要任务 - 更快地交付代码 - 同时组织仍然免受安全漏洞的侵害。

亲自尝试 NGINX Plus 的所有高级功能 - 立即开始30 天免费试用或联系我们讨论您的用例。