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

NGINX | 2021年3月04日

NGINX深感自豪的是，全球数百万家组织信赖我们的软件，用它来支持其网站和应用交付基础设施。用户对NGINX的依赖至关重要，因此，当他们坦言并未充分认识到运行最新版本的重要性时，我们感到意外。最新版本包含针对安全漏洞的修复，例如当今互联网上已十分常见的常见漏洞与披露（CVE）。

当然，仅仅考虑防范安全威胁还不够，还需要实施明确的流程来跟踪漏洞，并在防护措施可用后立即部署。对于开源软件，这些工作都需要自行完成，因此很容易低估所需的时间和精力。事实上，NGINX Plus等提供商业支持的软件有一项常被忽视的优势，那就是可以更快捷、更轻松地防范安全威胁。

本博客将探讨保护开源软件所面临的挑战，并说明NGINX Plus如何帮助您更快速、更轻松地缓解CVE及其他安全威胁。

应对开源软件中的漏洞

尽管所有开发人员都希望自己编写的代码完美无缺，但任何软件都难免存在缺陷。开发人员希望通过严格的质量合规流程，在开发阶段发现大多数缺陷，仅有少数缺陷会在应用的整个生命周期内于正常使用过程中暴露出来。最糟糕的情况是，缺陷被心怀恶意的用户发现。

如果使用多种开源工具、编程语言和平台构建应用堆栈，错误造成的后果会显著加剧。需要逐一审查各个组件，确认其不存在错误。发现开源软件中的错误时，务必要制定明确的策略，对其进行验证和测试，并在可能的情况下予以修复。

开源软件策略至少需要包含以下三个流程：

定期审查和测试
跟踪漏洞并在内部报告
及时修复漏洞

报告漏洞

发现安全漏洞后，通常会按照标准流程进行披露。第一步是向软件作者或供应商提交详细报告。报告者与作者共同决定披露漏洞的方式和时间，通常会在常见漏洞与披露（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 Plus基于NGINX Open Source构建，因此NGINX Open Source用户也能从中受益，因为我们致力于为NGINX Plus客户提供企业级支持并遵循企业级流程标准。这些标准包括与客户签订的服务级别协议（SLA），其中规定了补丁必须遵循的缺陷修复和测试流程，适用于核心软件、依赖项和受支持的模块。SLA有助于客户满足法规要求，并尽可能降低遭受漏洞利用的风险。

NGINX Open Source还面临一个复杂情况：许多第三方技术会利用它，并将其嵌入各自的产品中。这些技术的提供商在发现软件漏洞后，会按照自己的流程披露和修补漏洞。正如我们在下一节中所述，从我们发布NGINX Open Source补丁到第三方技术发布相应补丁，有时会间隔相当长的时间。

NGINX Plus 如何保护订阅用户免受漏洞影响

我们在引言中提到，NGINX Plus有一项常被忽视的优势：它可以帮助客户更快、更轻松地防范漏洞。处理开源软件中的漏洞可能比许多人想象的更耗时，因而成本也更高。

以下各节将介绍NGINX Plus订阅用户能够更快、更轻松地解决漏洞的五种具体方式。

NGINX主动向NGINX Plus订阅用户提供补丁信息

当我们发布适用于NGINX Open Source和NGINX Plus的安全补丁时，会主动通过电子邮件通知NGINX Plus客户。我们还会发布博客，公布大多数补丁已可用，但无法直接联系NGINX Open Source用户。因此，这些用户需要自行监控CVE及其他漏洞数据库，并定期查看我们的博客。

F5 SIRT为遭受攻击的NGINX Plus订阅客户提供实时协助

当F5客户（包括NGINX Plus订阅用户）遭受攻击时，F5 Security Incident Response Team（SIRT）会提供实时协助。SIRT会迅速采取行动，有效缓解攻击，帮助恢复正常运行。即使攻击停止后，团队仍会继续提供支持，“不局限于已报告的事件，致力于减少贵组织遭受的整体损害，并了解、预判和遏制未来威胁”。

NGINX App Protect增强应用保护

NGINX App Protect是一款企业级Web应用防火墙（WAF），依托F5 20年的安全经验，并以NGINX Plus动态模块的形式部署。它通过针对应用的防护，抵御后端应用服务器中更多的CVE，进一步增强NGINX Plus的第7层安全性。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 Open Source用户可获取修正后的源代码以及适用于受支持操作系统的已修补二进制文件，但如上所述，我们无法直接通知NGINX Open Source用户。

采用或嵌入NGINX Open Source的第三方技术可能无法在漏洞披露前获知该漏洞。即使获知，根据我们的经验，其补丁也可能比NGINX补丁晚数月发布。这种情况可以理解，尤其是开源软件通常由志愿者维护，但在漏洞公开披露后，这会使您的基础设施得不到保护，并可能遭到黑客利用。

例如，2018年秋季发现了两个与HTTP/2漏洞相关的CVE（CVE-2018-16843和CVE-2018-16844）。为此，我们为NGINX Plus R16和NGINX Open Source 1.15.6应用了安全补丁。广受欢迎的OpenResty软件基于NGINX Open Source构建，可提供NGINX Plus的部分功能。直到2019年3月3日，即NGINX发布补丁整整4个月后，OpenResty才首次发布包含这些补丁的候选版本。基于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 Open Source用户）必须自行决定是应用OWASP CRS团队提供的补丁，还是继续使用Trustwave未修补的软件，并考虑实施Trustwave提出的缓解措施。

［编者：NGINX ModSecurity WAF已于2022年4月1日正式停止销售，并将于2024年3月31日终止生命周期。有关更多详情，请参阅博客文章《F5 NGINX ModSecurity WAF即将终止生命周期》<.htmla>。］