全世界數以百萬計的企業與組織信任NGINX並通過NGINX軟體承載他們的網站並將NGINX應用交付基礎架構，這讓我們倍感自豪。 鑒於使用者對 NGINX 的依賴程度，我們十分驚訝的發現很多使用者並沒有意識到運行最新版本軟體（包含安全漏洞，例如CVE漏洞的修復）的重要性，而這種情況在如今的互聯網上十分普遍。
當然，僅僅考慮防範安全威脅還不夠，您還需要實施完善的流程來跟蹤漏洞並在漏洞出現後立即實施防護措施。 如果您必須自行完成這些工作（就像使用開源軟體），您會很容易低估所需要的時間和精力。 NGINX Plus 等商業支援軟體具有快速、輕鬆防範安全威脅的優勢，但卻經常被大家忽視。
在此文中，我們探討了開源軟體的防護挑戰，並闡述了 NGINX Plus 如何説明更快速、輕鬆地緩解 CVE 及其他安全威脅。
處理開源軟體中的漏洞
儘管所有開發人員都認為自己編寫的代碼完美無暇，但任何軟體都會存在漏洞。 開發人員希望大多數漏洞都能通過嚴格的品質合規流程在開發過程中檢測出來，只留少數漏洞在應用生命週期內的正常使用中慢慢發現。 然而，最糟糕的情況是，漏洞常常是被惡意使用者首先發現。
當您通過多個開源工具、程式設計語言和平臺構建應用棧時，漏洞的危害會大大加劇。 您需要分別查看每個元件，以確保它們不包含漏洞。 當在開源軟體中發現漏洞時，明確的漏洞驗證、測試和修復（如果可能）策略很重要。
您的開源軟體策略至少需要包括三個流程：
- 定期審查和測試
- 跟蹤漏洞並在內部報告
- 及時修復漏洞
報告漏洞
當發現安全漏洞時，需要有一個標準的事件流程對其進行披露。 第一步是向軟體作者或廠商提交一份詳細的報告。 報告者和作者共同決定如何以及何時披露漏洞，通常以記錄在通用漏洞披露 （CVE） 資料庫的形式進行披露。 按照慣例，作者在漏洞披露之前有90天的緩衝期，並且還可以協商更長時間。
NGINX 和 CVE
作為開源軟體供應商和商業軟體廠商，NGINX 積极參與 CVE 及和其他漏洞的報告和修復工作，以免影響 NGINX 開源版和 NGINX Plus 及其他商業產品（在撰寫本文時包括 NGINX 控制器、NGINX App Protect 和 NGINX Ingress 控制器），以及免費的開源產品，其中包括 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 助力增強應用防護
NGINX App Protect 是一款凝聚 F5 20 年安全經驗的企業級應用防火牆 （WAF），，作為動態模組部署在 NGINX Plus 中。 它通過應用特定防護來增強 NGINX Plus 第 7 層安全性，能夠抵禦後端應用伺服器中的更多 CVE 漏洞。 NGINX 和 F5 會負責提供與特定攻擊活動相關的簽名。 借助NGINX App Protect，NGINX Plus 使用者無需再親自建立簽名和處理多個誤報。
●NGINX Plus 支援基於 JWT 和 OpenID Connect 的認證
即使沒有需要修復的特定漏洞，複雜的身份驗證協議也有助於防止攻擊者訪問您的應用和基礎架構。除了 NGINX 開源版提供的方法之外，NGINX Plus 還可為 Web 以及 API 用戶端提供基於 JSON Web 令牌 （JWT） 和 OpenID Connect 的身份驗證。
● NGINX Plus 使用者可立即獲得補丁
如「報告漏洞」部分所述，當漏洞影響 NGINX 軟體時，我們通常會在其作為 CVE 被公開之前得到通知。 這種預先警告讓我們能夠在漏洞公開披露之前準備修復程式，我們通常會在披露當天（有時會在幾天內）發佈補丁。 修復程式以修復二進位檔的形式提供給 NGINX Plus 客戶;以更正源碼和受支援操作系統修復二進位檔的形式提供給 NGINX 開源版使用者，但如上所述，我們無法在修復程式發佈直接通知他們。
利用或嵌入 NGINX 開源版的第三方技術在漏洞披露前可能不會知道該漏洞。 即使他們知道，根據我們的經驗，他們的補丁發佈時間也可能會比 NGINX 晚幾個月。 這種情況可以理解，特別是對於通常由志願者維護的開源軟體，但這會導致您的基礎架構存在安全風險，並且在漏洞公開披露後可能遭到駭客攻擊。
例如，2018 年秋季發現了兩個關於 HTTP/2 漏洞的 CVE（CVE-2018-16843 和 CVE-2018-16844）。 作為回應，我們對 NGINX Plus R16 和 NGINX 開源版 1.15.6 進行了修復，而熱門軟體OpenResty （基於 NGINX 開源版提供 NGINX Plus 中的某些功能）到 2019 年 3 月 3 日才發佈了一個包含這些補丁的候選版本，與 NGINX 的補丁發佈時間相差了整整 4 個月。 基於 OpenResty 構建的解決方案通常還需要更長時間來修復其代碼庫。
有時，我們並不清楚漏洞的狀態，或者軟體供應商認為無需修復，即使漏洞構成了潛在的攻擊向量。2020 年，應用最廣泛的開源 WAF軟體 ModSecurity 就曾發生過這種情況。 OWASP ModSecurity Core Rule Set （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 Plus 訂閱減輕了應用團隊的負擔，使其能夠專注於主要任務，即更快地交付代碼，同時讓組織遠離安全漏洞之擾。
作者 | Laurent Pétroque of F5
职位 | Dir, Solutions Engineering – NGINX APCJ