HTTP2 快速重置攻擊: Cloudflare 發(fā)現(xiàn)并緩解史上最大規(guī)模的新型網(wǎng)絡(luò)威脅

如果您正在遭受類似攻擊或想尋求增強安全防護支持               

檢測和緩解情況概述

這是一種規(guī)?？涨暗男滦凸羰侄危珻loudflare 現(xiàn)有的保護措施在很大程度上能夠抵御這種攻擊的沖擊。 雖然最初我們看到了對客戶流量的一些影響（在第一波攻擊期間影響了大約 1% 的請求），但今天我們已經(jīng)能夠改進我們的緩解方法，以阻止任何 針對Cloudflare 客戶的攻擊，也不影響我們自身的系統(tǒng)正常運行。

我們注意到這些攻擊的同時，另外兩個主要行業(yè)參與者——谷歌和 AWS——也看到了同樣的情況。 我們致力于強化 Cloudflare 的系統(tǒng)，以確保今天我們的所有客戶都能免受這種新的 DDoS 攻擊方法的影響，而不會對客戶造成任何影響。 我們還與 Google 和 AWS 合作，向受影響的供應(yīng)商和關(guān)鍵基礎(chǔ)設(shè)施提供商協(xié)調(diào)披露此次攻擊。

這種攻擊是通過濫用 HTTP/2 協(xié)議的某些功能和服務(wù)器實現(xiàn)細節(jié)而實現(xiàn)的。 由于該攻擊利用了 HTTP/2 協(xié)議中的潛在弱點，因此我們相信任何實施了 HTTP/2 的供應(yīng)商都將受到攻擊。 這包括所有現(xiàn)代網(wǎng)絡(luò)服務(wù)器。 我們與 Google 和 AWS 一起向 Web 服務(wù)器供應(yīng)商披露了攻擊方法，我們預(yù)計他們將實施補丁。 與此同時，最好的防御措施是在任何 Web 或 API 服務(wù)器前面使用 Cloudflare 等 DDoS 緩解服務(wù)。

這篇文章深入探討了 HTTP/2 協(xié)議的詳細信息、攻擊者用來生成這些大規(guī)模攻擊的方法，以及我們?yōu)榇_保所有客戶受到保護而采取的緩解策略。 我們希望通過發(fā)布這些詳細信息，其他受影響的網(wǎng)絡(luò)服務(wù)器和服務(wù)將獲得實施緩解策略所需的信息。 此外，HTTP/2 協(xié)議標準團隊以及致力于未來 Web 標準的團隊可以更好地設(shè)計它們以防止此類攻擊。

RST攻擊細節(jié)

HTTP 是為 Web 提供支持的應(yīng)用程序協(xié)議。 HTTP 語義對于所有版本的 HTTP 都是通用的 — 整體架構(gòu)、術(shù)語和協(xié)議方面，例如請求和響應(yīng)消息、方法、狀態(tài)代碼、標頭和尾部字段、消息內(nèi)容等等。 每個單獨的 HTTP 版本都定義了如何將語義轉(zhuǎn)換為“有線格式”以通過 Internet 進行交換。 例如，客戶端必須將請求消息序列化為二進制數(shù)據(jù)并發(fā)送，然后服務(wù)器將其解析回它可以處理的消息。

HTTP/1.1 使用文本形式的序列化。 請求和響應(yīng)消息作為 ASCII 字符流進行交換，通過可靠的傳輸層（如 TCP）發(fā)送，使用以下格式（其中 CRLF 表示回車和換行）：

網(wǎng)頁需要比這些示例更復(fù)雜的 HTTP 交互。 訪問 Cloudflare 博客時，您的瀏覽器將加載多個腳本、樣式和媒體資產(chǎn)。 如果您使用 HTTP/1.1 訪問首頁并決定快速導(dǎo)航到第 2 頁，您的瀏覽器可以從兩個選項中進行選擇。 在第 2 頁甚至可以啟動之前，等待您不再需要的頁面的所有排隊響應(yīng)，或者通過關(guān)閉 TCP 連接并打開新連接來取消正在進行的請求。 這些都不太實用。 瀏覽器傾向于通過管理 TCP 連接池（每個主機最多 6 個）并在池上實現(xiàn)復(fù)雜的請求分派邏輯來解決這些限制。

HTTP/2 解決了 HTTP/1.1 的許多問題。 每個 HTTP 消息都被序列化為一組 HTTP/2 幀，這些幀具有類型、長度、標志、流標識符 （ID） 和有效負載。 流 ID 清楚地表明線路上的哪些字節(jié)適用于哪個消息，從而允許安全的多路復(fù)用和并發(fā)。 流是雙向的。 客戶端發(fā)送幀，服務(wù)器使用相同的 ID 回復(fù)幀。

在 HTTP/2 中，我們對 https://blog.cloudflare.com 的 GET 請求將通過流 ID 1 進行交換，客戶端發(fā)送一個 HEADERS 幀，服務(wù)器使用一個 HEADERS 幀進行響應(yīng)，后跟一個或多個 DATA 幀。 客戶端請求始終使用奇數(shù)流 ID，因此后續(xù)請求將使用流 ID 3、5 等。 可以以任何順序提供響應(yīng)，并且來自不同流的幀可以交織。

流復(fù)用和并發(fā)是 HTTP/2 的強大功能。 它們可以更有效地使用單個 TCP 連接。 HTTP/2 優(yōu)化了資源獲取，尤其是與優(yōu)先級結(jié)合使用時。 另一方面，與 HTTP/1.1 相比，使客戶端能夠輕松啟動大量并行工作可能會增加對服務(wù)器資源的峰值需求。 這是一個明顯的拒絕服務(wù)向量。

為了提供一些防護，HTTP/2 提供了最大活動并發(fā)流的概念。 SETTINGS_MAX_CONCURRENT_STREAMS 參數(shù)允許服務(wù)器通告其并發(fā)限制。 例如，如果服務(wù)器規(guī)定限制為 100，則任何時候只能有 100 個請求處于活動狀態(tài)。 如果客戶端嘗試打開超過此限制的流，則服務(wù)器必須使用 RST_STREAM 幀拒絕它。 流拒絕不會影響連接上的其他正在進行的流。

真實的故事有點復(fù)雜。 流有生命周期。 下圖是 HTTP/2 流狀態(tài)機的示意圖。 客戶端和服務(wù)器管理自己的流狀態(tài)視圖。 HEADERS、DATA 和 RST_STREAM 幀在發(fā)送或接收時會觸發(fā)轉(zhuǎn)換。 雖然流狀態(tài)的視圖是獨立的，但它們是同步的。

HEADERS 和 DATA 幀包含 END_STREAM 標志，當設(shè)置為值 1（真）時，可以觸發(fā)狀態(tài)轉(zhuǎn)換。

讓我們通過一個沒有消息內(nèi)容的 GET 請求示例來解決這個問題。 客戶端以 HEADERS 幀的形式發(fā)送請求，并將 END_STREAM 標志設(shè)置為 1?？蛻舳耸紫葘⒘鲝目臻e狀態(tài)轉(zhuǎn)換為打開狀態(tài)，然后立即轉(zhuǎn)換為半關(guān)閉狀態(tài)。 客戶端半關(guān)閉狀態(tài)意味著它不能再發(fā)送HEADERS或DATA，只能發(fā)送 WINDOW_UPDATE、PRIORITY或RST_STREAM幀。 然而它可以接收任何幀。

一旦服務(wù)器接收并解析了 HEADERS 幀，它就會將流狀態(tài)從空閑轉(zhuǎn)變?yōu)榇蜷_，然后半關(guān)閉，因此它與客戶端匹配。 服務(wù)器半關(guān)閉狀態(tài)意味著它可以發(fā)送任何幀，但只能接收 WINDOW_UPDATE、PRIORITY 或 RST_STREAM 幀。

對 GET 的響應(yīng)包含消息內(nèi)容，因此服務(wù)器發(fā)送 END_STREAM 標志設(shè)置為 0 的 HEADERS，然后發(fā)送 END_STREAM 標志設(shè)置為 1 的 DATA。DATA 幀觸發(fā)服務(wù)器上流從半關(guān)閉到關(guān)閉的轉(zhuǎn)換。 當客戶端收到它時，它也會轉(zhuǎn)換為關(guān)閉狀態(tài)。 一旦流關(guān)閉，就無法發(fā)送或接收任何幀。

將此生命周期應(yīng)用回并發(fā)上下文中，HTTP/2 指出：

處于“打開”狀態(tài)或任一“半關(guān)閉”狀態(tài)的流計入允許端點打開的最大流數(shù)。 處于這三種狀態(tài)中任何一種狀態(tài)的流都會計入 SETTINGS_MAX_CONCURRENT_STREAMS 設(shè)置中公布的限制。

理論上，并發(fā)限制是有用的。 然而，有一些實際因素阻礙了其有效性——我們將在本文后續(xù)介紹。

HTTP/2 請求取消

早些時候，我們討論了客戶取消傳遞中請求的情況。 HTTP/2 以比 HTTP/1.1 更有效的方式支持這一點。 客戶端可以為單個流發(fā)送 RST_STREAM 幀，而不需要拆除整個連接。 這指示服務(wù)器停止處理請求并中止響應(yīng)，從而釋放服務(wù)器資源并避免浪費帶寬。

讓我們考慮一下之前的 3 個請求的示例。 這次，在發(fā)送所有標頭后，客戶端取消了流 1 上的請求。 服務(wù)器在準備好提供響應(yīng)之前解析此 RST_STREAM 幀，并且僅響應(yīng)流 3 和 5：

請求取消是一個有用的功能。 例如，當滾動包含多個圖像的網(wǎng)頁時，網(wǎng)絡(luò)瀏覽器可以取消落在視口之外的圖像，這意味著進入視口的圖像可以更快地加載。 與 HTTP/1.1 相比，HTTP/2 使這種行為更加高效。

被取消的請求流會快速過渡整個流生命周期。 END_STREAM 標志設(shè)置為 1 的客戶端 HEADERS 狀態(tài)從空閑狀態(tài)轉(zhuǎn)換為打開狀態(tài)再到半關(guān)閉狀態(tài)，然后 RST_STREAM 立即導(dǎo)致從半關(guān)閉狀態(tài)轉(zhuǎn)換為關(guān)閉狀態(tài)。

回想一下，只有處于打開或半關(guān)閉狀態(tài)的流才會影響流并發(fā)限制。 當客戶端取消流時，它立即能夠在其位置打開另一個流，并可以立即發(fā)送另一個請求。 這是 CVE-2023-44487 發(fā)揮作用的關(guān)鍵。

快速重置導(dǎo)致拒絕服務(wù)

HTTP/2 請求取消可能被濫用來快速重置無限數(shù)量的流。 當 HTTP/2 服務(wù)器能夠足夠快地處理客戶端發(fā)送的 RST_STREAM 幀并拆除狀態(tài)時，這種快速重置不會導(dǎo)致問題。 當整理工作出現(xiàn)任何延誤或滯后時，問題就會開始出現(xiàn)。 客戶端可能會處理大量請求，從而導(dǎo)致工作積壓，從而導(dǎo)致服務(wù)器上資源的過度消耗。

常見的 HTTP 部署架構(gòu)是在其他組件之前運行 HTTP/2 代理或負載均衡器。 當客戶端請求到達時，它會被快速分派，并且實際工作在其他地方作為異步活動完成。 這使得代理能夠非常有效地處理客戶端流量。 然而，這種關(guān)注點分離可能會使代理很難整理正在進行的作業(yè)。 因此，這些部署更有可能遇到快速重置帶來的問題。

當 Cloudflare 的反向代理處理傳入的 HTTP/2 客戶端流量時，它們會將數(shù)據(jù)從連接的套接字復(fù)制到緩沖區(qū)中，并按順序處理緩沖的數(shù)據(jù)。 當讀取每個請求（標頭和數(shù)據(jù)幀）時，它被分派到上游服務(wù)。 當讀取 RST_STREAM 幀時，請求的本地狀態(tài)將被拆除，并通知上游請求已被取消。 沖洗并重復(fù)，直到耗盡整個緩沖區(qū)。 然而，這種邏輯可能會被濫用：當惡意客戶端開始發(fā)送大量請求鏈并在連接開始時重置時，我們的服務(wù)器會急切地讀取所有請求，并對上游服務(wù)器造成壓力，導(dǎo)致無法處理任何新傳入的請求。

需要強調(diào)的重要一點是，流并發(fā)本身無法緩解快速重置。 無論服務(wù)器選擇的 SETTINGS_MAX_CONCURRENT_STREAMS 值如何，客戶端都可以攪動請求以創(chuàng)建高請求率。

快速重置剖析

以下是使用概念驗證客戶端嘗試發(fā)出總共 1000 個請求的快速重置示例。 我使用了現(xiàn)成的服務(wù)器，沒有任何緩解措施； 在測試環(huán)境中偵聽端口 443。 為了清楚起見，使用 Wireshark 剖析流量并進行過濾以僅顯示 HTTP/2 流量。 下載 pcap 以進行后續(xù)操作。

有點難看，因為有很多幀。 我們可以通過Wireshark的Statistics > HTTP2工具得到一個快速的總結(jié)：

此跟蹤中的第一幀（數(shù)據(jù)包 14 中）是服務(wù)器的 SETTINGS 幀，它通告最大流并發(fā)數(shù)為 100。在數(shù)據(jù)包 15 中，客戶端發(fā)送一些控制幀，然后開始發(fā)出快速重置的請求。 第一個 HEADERS 幀長 26 個字節(jié)，所有后續(xù)的 HEADERS 只有 9 個字節(jié)。 這種大小差異是由于稱為 HPACK 的壓縮技術(shù)造成的。 數(shù)據(jù)包 15 總共包含 525 個請求，直至流 1051。

有趣的是，流 1051 的 RST_STREAM 不適合數(shù)據(jù)包 15，因此在數(shù)據(jù)包 16 中我們看到服務(wù)器以 404 響應(yīng)進行響應(yīng)。 然后，在數(shù)據(jù)包 17 中，客戶端發(fā)送 RST_STREAM，然后繼續(xù)發(fā)送剩余的 475 個請求。

請注意，雖然服務(wù)器通告了 100 個并發(fā)流，但客戶端發(fā)送的兩個數(shù)據(jù)包發(fā)送的 HEADERS 幀比這多得多。 客戶端不必等待服務(wù)器的任何返回流量，它僅受其可以發(fā)送的數(shù)據(jù)包大小的限制。 在此跟蹤中沒有看到服務(wù)器 RST_STREAM 幀，這表明服務(wù)器沒有觀察到并發(fā)流違規(guī)。

對客戶的影響

如上所述，當請求被取消時，上游服務(wù)會收到通知，并可以在浪費太多資源之前中止請求。 這次攻擊就是這種情況，大多數(shù)惡意請求從未轉(zhuǎn)發(fā)到源服務(wù)器。 然而，這些攻擊的規(guī)模確實造成了一些影響。

首先，隨著傳入請求的速率達到前所未有的峰值，我們收到了客戶發(fā)現(xiàn)的 502 錯誤數(shù)量增加的報告。 這種情況發(fā)生在我們受影響最嚴重的數(shù)據(jù)中心，因為它們正在努力處理所有請求。讓我們更深入地了解細節(jié)，重點關(guān)注傳入請求到達我們的數(shù)據(jù)中心之一時如何處理：

我們可以看到我們的基礎(chǔ)設(shè)施由一系列具有不同職責(zé)的不同代理服務(wù)器組成。 特別是，當客戶端連接到 Cloudflare 發(fā)送 HTTPS 流量時，它首先會命中我們的 TLS 解密代理：它解密 TLS 流量，處理 HTTP 1、2 或 3 流量，然后將其轉(zhuǎn)發(fā)到我們的“業(yè)務(wù)邏輯”代理。 它負責(zé)加載每個客戶的所有設(shè)置，然后將請求正確路由到其他上游服務(wù) - 更重要的是，在我們的例子中，它還負責(zé)安全功能。 這是處理 L7 攻擊緩解的地方。

這種攻擊媒介的問題在于它能夠在每個連接中非?？焖俚匕l(fā)送大量請求。 在我們有機會阻止它們之前，它們中的每一個都必須轉(zhuǎn)發(fā)到業(yè)務(wù)邏輯代理。 隨著請求吞吐量變得高于我們的代理容量，連接這兩個服務(wù)的管道在我們的一些服務(wù)器中達到了飽和水平。

發(fā)生這種情況時，TLS 代理無法再連接到其上游代理，這就是為什么某些客戶端在最嚴重的攻擊期間看到“502 Bad Gateway”錯誤的原因。 值得注意的是，截至今天，用于創(chuàng)建 HTTP 分析的日志也由我們的業(yè)務(wù)邏輯代理發(fā)出。 其結(jié)果是這些錯誤在 Cloudflare 儀表板中不可見。 我們的內(nèi)部儀表板顯示，大約 1% 的請求在第一波攻擊期間（在我們實施緩解措施之前）受到影響，在 8 月 29 日最嚴重的攻擊期間，峰值在 12% 左右，持續(xù)了幾秒鐘。 下圖顯示了發(fā)生這種情況時兩個小時內(nèi)這些錯誤的比率：

我們在接下來的幾天里努力大幅減少這個數(shù)字，本文稍后將詳細介紹。 由于我們堆棧的變化以及我們的緩解措施大大減少了這些攻擊的規(guī)模，今天這個數(shù)字實際上為零：

499錯誤和HTTP/2流并發(fā)的挑戰(zhàn)

一些客戶報告的另一個癥狀是 499 錯誤增加。 其原因有點不同，與本文前面詳細介紹的 HTTP/2 連接中的最大流并發(fā)有關(guān)。

HTTP/2 設(shè)置在連接開始時使用 SETTINGS 幀進行交換。 如果沒有接收顯式參數(shù)，則應(yīng)用默認值。 一旦客戶端建立了 HTTP/2 連接，它就可以等待服務(wù)器的設(shè)置（慢），也可以采用默認值并開始發(fā)出請求（快）。 對于 SETTINGS_MAX_CONCURRENT_STREAMS，默認值實際上是無限制的（流 ID 使用 31 位數(shù)字空間，請求使用奇數(shù)，因此實際限制為 1073741824）。 規(guī)范建議服務(wù)器提供不少于 100 個流。 客戶端通常偏向于速度，因此不要等待服務(wù)器設(shè)置，這會產(chǎn)生一些競爭條件。 客戶端正在對服務(wù)器可能選擇的限制進行賭博； 如果他們選擇錯誤，請求將被拒絕并必須重試。 在 1073741824 流上賭博有點愚蠢。 相反，許多客戶端決定限制自己發(fā)出 100 個并發(fā)流，希望服務(wù)器遵循規(guī)范建議。 當服務(wù)器選擇低于 100 的值時，客戶端賭博就會失敗并且流會被重置。

服務(wù)器重置流超出并發(fā)限制的原因有很多。 HTTP/2 是嚴格的，要求在出現(xiàn)解析或邏輯錯誤時關(guān)閉流。 2019 年，Cloudflare 開發(fā)了多種緩解措施來應(yīng)對 HTTP/2 DoS 漏洞。 其中幾個漏洞是由客戶端行為不當引起的，導(dǎo)致服務(wù)器重置流。 遏制此類客戶端的一個非常有效的策略是計算連接期間服務(wù)器重置的次數(shù)，當超過某個閾值時，使用 GOAWAY 幀關(guān)閉連接。 合法客戶可能會在連接中犯一兩個錯誤，這是可以接受的。 犯太多錯誤的客戶端可能已損壞或惡意，關(guān)閉連接可以解決這兩種情況。

在響應(yīng) CVE-2023-44487 啟用的 DoS 攻擊時，Cloudflare 將最大流并發(fā)數(shù)降低到 64。在進行此更改之前，我們沒有意識到客戶端不會等待 SETTINGS，而是假設(shè)并發(fā)數(shù)為 100。某些網(wǎng)頁，例如 作為一個圖片庫，確實會導(dǎo)致瀏覽器在連接開始時立即發(fā)送 100 個請求。 不幸的是，超出限制的 36 個流都需要重置，這觸發(fā)了我們的計數(shù)緩解措施。 這意味著我們關(guān)閉了合法客戶端上的連接，導(dǎo)致頁面加載完全失敗。 當我們意識到這個互操作性問題后，我們將最大流并發(fā)數(shù)更改為 100。

Cloudflare措施和建議

2019 年，發(fā)現(xiàn)了多個與 HTTP/2 實現(xiàn)相關(guān)的 DoS 漏洞。 Cloudflare 開發(fā)并部署了一系列檢測和緩解措施作為響應(yīng)。 CVE-2023-44487是HTTP/2漏洞的另一種表現(xiàn)形式。 然而，為了緩解這一問題，我們能夠擴展現(xiàn)有的保護措施來監(jiān)視客戶端發(fā)送的 RST_STREAM 幀，并在它們被濫用時關(guān)閉連接。 RST_STREAM 的合法客戶端使用不受影響。

除了直接修復(fù)之外，我們還對服務(wù)器的 HTTP/2 幀處理和請求分派代碼進行了多項改進。 此外，業(yè)務(wù)邏輯服務(wù)器還對排隊和調(diào)度進行了改進，減少了不必要的工作并提高了取消響應(yīng)能力。 這些共同減少了各種潛在濫用模式的影響，并為服務(wù)器在飽和之前提供了更多空間來處理請求。

盡早緩解攻擊

Cloudflare 已經(jīng)擁有適當?shù)南到y(tǒng)，可以通過更便宜的方法有效地緩解非常大的攻擊。 其中之一被命名為“IP Jail”。 對于超容量攻擊，該系統(tǒng)會收集參與攻擊的客戶端 IP，并阻止它們連接到受攻擊的財產(chǎn)（無論是在 IP 級別還是在我們的 TLS 代理中）。 然而，該系統(tǒng)需要幾秒鐘才能完全生效； 在這寶貴的幾秒鐘內(nèi)，源頭已經(jīng)受到保護，但我們的基礎(chǔ)設(shè)施仍然需要吸收所有 HTTP 請求。 由于這種新的僵尸網(wǎng)絡(luò)實際上沒有啟動期，因此我們需要能夠在攻擊成為問題之前將其消滅。

為了實現(xiàn)這一目標，我們擴展了 IP Jail 系統(tǒng)來保護我們的整個基礎(chǔ)設(shè)施：一旦 IP 被“監(jiān)禁”，不僅會阻止它連接到受攻擊的財產(chǎn)，我們還會禁止相應(yīng)的 IP 使用 HTTP/2 訪問任何其他域 在 Cloudflare 上使用了一段時間。 由于使用 HTTP/1.x 不可能進行此類協(xié)議濫用，因此這限制了攻擊者運行大型攻擊的能力，而共享同一 IP 的任何合法客戶端在此期間只會看到非常小的性能下降。 基于 IP 的緩解措施是一種非常生硬的工具——這就是為什么我們在大規(guī)模使用它們時必須非常小心，并盡可能避免誤報。 此外，僵尸網(wǎng)絡(luò)中給定 IP 的生命周期通常很短，因此任何長期緩解措施都可能弊大于利。 下圖顯示了我們目睹的攻擊中 IP 的流失情況：

正如我們所看到的，在某一天發(fā)現(xiàn)的許多新 IP 隨后很快就消失了。

由于所有這些操作都發(fā)生在 HTTPS 管道開始處的 TLS 代理中，因此與常規(guī) L7 緩解系統(tǒng)相比，這可以節(jié)省大量資源。 這使我們能夠更順利地抵御這些攻擊，現(xiàn)在由這些僵尸網(wǎng)絡(luò)引起的隨機 502 錯誤數(shù)量已降至零。

攻擊可觀測性改進

我們正在做出改變的另一個方面是可觀察性。 在客戶分析中不可見的情況下向客戶返回錯誤是不令人滿意的。 幸運的是，早在最近的攻擊發(fā)生之前，一個對這些系統(tǒng)進行徹底檢修的項目就已經(jīng)開始進行。 最終，它將允許我們基礎(chǔ)設(shè)施中的每個服務(wù)記錄自己的數(shù)據(jù)，而不是依賴我們的業(yè)務(wù)邏輯代理來合并和發(fā)出日志數(shù)據(jù)。 這次事件凸顯了這項工作的重要性，我們正在加倍努力。

我們還致力于更好的連接級日志記錄，使我們能夠更快地發(fā)現(xiàn)此類協(xié)議濫用，從而提高我們的 DDoS 緩解能力。

結(jié)論

雖然這是最新的破紀錄攻擊，但我們知道這不會是最后一次。 隨著攻擊變得越來越復(fù)雜，Cloudflare 不斷努力主動識別新威脅 - 為我們的全球網(wǎng)絡(luò)部署對策，以便我們數(shù)百萬的客戶立即得到自動保護。

自 2017 年以來，Cloudflare 一直為我們的所有客戶提供免費、不計量且無限制的 DDoS 保護。此外，我們還提供一系列附加安全功能，以滿足各種規(guī)模組織的需求。 如果您不確定自己是否受到保護或想了解如何受到保護。