WAF中記錄和阻止之間的平衡

Informatec Digital »資源» WAF 中的日誌記錄與阻止平衡

在Web應用防火牆（WAF）中，如何平衡日誌記錄和攔截已成為安全和維運團隊最頭痛的問題之一。 Web應用防火牆可以阻止非常嚴重的攻擊，但如果配置過於激進，則可能會攔截合法的購買、存取或API呼叫。如果配置過於寬鬆，則幾乎淪為擺設。關鍵在於謹慎調整日誌記錄的時機、統計流量的時機、允許的時機和攔截的時機。

本文將深入探討如何利用現代 Web 應用防火牆 (WAF) 的功能（例如允許清單、基於頻率的規則、學習模式、SIEM 整合、機器學習等）來實現這種平衡，並提供來自AWS WAF、ModSecurity、雲端 WAF 和本地部署解決方案的具體範例。您將了解如何在不降低防護等級的前提下減少誤報，如何按應用程式組織策略，以及如何將日誌記錄作為助力而非持續不斷的、難以管理的噪音源。

什麼是WAF？為什麼註冊如此重要？

Web應用防火牆可作為使用者和伺服器之間的智慧層，即時分析HTTP/HTTPS流量。與監控連接埠和IP位址的傳統網路防火牆不同，WAF的監控範圍更廣：它會分析URL、參數、請求體、請求頭、Cookie、HTTP方法等等。

它的任務是偵測並阻止典型的第七層攻擊：SQL注入、跨站腳本攻擊 (XSS)、本機檔案包含/遠端檔案包含 (LFI/RFI)、存取控制攻擊、API濫用、惡意爬蟲、暴力破解，甚至某些應用層DDoS攻擊模式。為此，它依賴於不斷更新的規則集、簽章和安全性原則。

日誌記錄是硬幣的另一面。 WAF 的每一個決策——允許、阻止或僅計數——都可以在日誌中記錄詳細的事件資訊。這些日誌可以用於：

• 調查事件：重構事件經過以及利用漏洞的嘗試過程。
• 調整規則：透過查看 WAF 阻止了哪些合法請求來偵測誤報。
• 遵守規章制度證明有有效的控制措施（PCI DSS、GDPR、內部稽核等）。
• 向安全資訊和事件管理 (SIEM) 系統提供數據將應用程式攻擊與網路、系統、身分等事件關聯起來。

問題在於，配置不當的WAF會將日誌充斥著成千上萬條無關事件，導致無法找到真正重要的訊息，而且還會不合理地拒絕合法流量。這就需要我們巧妙地運用日誌記錄、計數和封鎖模式。

WAF 中的安全模型：封鎖清單、允許清單和混合方法

大多數現代Web應用防火牆（WAF）都結合了多種過濾方法，這直接影響請求的日誌記錄和攔截方式。總的來說，我們可以辨識出兩種經典理念，以及一種非常常見的混合模型。

基於黑名單的Web應用防火牆（WAF）遵循負面安全模型。其核心原則是：「除了已知惡意行為之外，我允許一切行為通過。」它的工作原理是利用已知攻擊（例如SQL注入、XSS、殭屍網路模式等）的特徵碼以及定義可疑行為的規則。這種模型部署起來比較容易，但完全依賴它可能會導致新的攻擊路徑或變種繞過偵測。

具有允許清單的Web 應用防火牆 (WAF) 的工作原理恰恰相反：「阻止除明確允許的流量之外的所有流量」。它基於積極的安全模型。只有符合已定義合法行為（路由、方法、參數、格式、大小等）的流量才會被接受。這種方式安全性更高，但需要大量的微調，如果準備不當，最初可能會產生誤報。

由於每種方法各有優缺點，結合允許列表和阻止列表的混合模型正變得越來越普遍。在這種方案中，會定義預期流量特徵（例如，正常的登入或付款請求），並同時套用簽章和啟發式方法來偵測典型的惡意模式。就日誌記錄而言，這種混合方法允許：

• 標記為 高風險事件 違反允許物品清單的物品。
• 視為 中/低​​優先級警報 通用黑名單模式。
• 使用「計數」模式查看哪些操作會違反規則，然後再啟動封鎖功能。

網路、主機和雲端中的WAF：對日誌記錄和鎖定的影響

WAF部署模型極大地影響流量日誌記錄和攔截的處理方式。在網路設備上記錄請求與在伺服器內部代理或託管雲端服務上記錄請求是截然不同的。

網路為基礎的Web應用防火牆（WAF）通常以實體或虛擬設備的形式部署在基礎架構中，位於網際網路和應用程式之間。這是F5等廠商採用的經典方法。它具有高效能和精細控制的優勢，但配置和管理可能較為複雜。日誌通常會傳送到syslog或中央安全資訊和事件管理（SIEM）系統，因此必須仔細過濾已儲存的日誌內容，以避免儲存和分析工具過載，並有助於診斷IP和DNS網路中的問題。

基於主機的Web應用防火牆（WAF）運行在應用程式所在的相同伺服器（或容器）上，通常以模組或代理的形式存在（例如，整合到Nginx或Apache中的ModSecurity；將其與使用SELinux的Linux加固相結合可以提升安全性）。這種模型允許更豐富的應用程式上下文信息，並為每個服務設定高度具體的規則，但代價是會消耗本地資源，並且需要更分散的日誌管理。日誌可以儲存在本機文件中並轉發，也可以與集中式日誌服務整合。

基於雲端的Web 應用防火牆(WAF) （例如 Cloudflare、Akamai、Imperva Cloud、AWS WAF 等）可與負載平衡器、內容分發網路 (CDN) 或虛擬網路整合。服務提供者通常提供控制面板，並支援將日誌匯出到 S3、BigQuery、遠端系統日誌或安全資訊和事件管理 (SIEM) 系統。雖然它們的設定通常更簡便，但您必須根據服務提供者的模型調整日誌記錄策略，例如事件類型、保留期限、嚴重性篩選器等。

選擇哪種模型不僅僅是一個技術決定，還取決於您希望如何平衡日誌記錄和鎖定：雲端管理服務簡化了許多方面，但由於合規性或保密性策略，您可能希望對日誌的儲存位置擁有絕對控制權，這會促使您選擇本地部署或混合模型。

條款、規則和 Web ACL：WAF 如何決定是阻止、允許還是僅註冊

無論製造商是誰，所有現代 Web 應用防火牆 (WAF) 都基於存取條件、規則和策略的概念。理解這一點是成功在生產環境中使用計數、日誌記錄和鎖定模式的關鍵。

這些條件描述了要檢查請求的哪些部分：來源 IP、特定 HTTP 標頭（Host、User-Agent、Accept、Content-Type 等）、查詢參數、請求正文、Cookie、HTTP 方法、來源國家/地區等。例如，在 AWS WAF Classic 中，您可以定義一個包含最多 10.000 個位址或範圍的 IP 條件，或定義一個 URL 部分字串符合條件。

規則結合一個或多個條件，並賦予其一個意圖：允許、阻止或計數。當規則包含多個條件時，通常會使用邏輯「與」來判斷：所有條件都必須滿足，規則才會觸發。實際上，沒有條件的普通規則無法匹配任何內容，其操作也永遠不會被觸發。

許多Web應用防火牆（WAF），包括AWS WAF，都具備基於速率的規則。這些規則會統計在特定時間內（例如五分鐘）來自特定IP位址（或符合特定條件的一組IP位址）的請求數量。如果超過閾值（例如五分鐘內超過1.000個請求），則規則生效：要么阻止請求，要么僅進行計數。這對於以下情況非常有用：

• 控制 對登入表單進行暴力破解.
• 限制惡意抓取或無禮的機器人。
• 在應用層緩解某些類型的DDoS攻擊。

下一層是Web 存取控制清單 (ACL)。在這裡，規則被分組，並定義了評估順序和預設操作（允許或阻止）。請求會依序逐條規則進行評估；如果符合某條規則，則執行相應的操作，並停止對其餘規則的評估。如果請求不符合任何規則，則執行 ACL 中定義的預設操作。

在平衡日誌記錄和阻止流量方面，ACL 用於決定係統預設是寬鬆的（僅允許特定規則阻止流量）還是嚴格的（除特殊情況外全部阻止）。此外，許多解決方案可讓您在 ACL 中設定「計數」模式的規則，這樣它們會記錄匹配項但不會阻止流量——這非常適合調優階段。

日誌中的白名單和降噪

允許清單是減少日誌中誤報和雜訊的基本工具。其原理很簡單：在特定情況下，您可以指示 WAF 不要將指令或規則集應用於您已歸類為可信任流量或您知道雖然合法但超出常規範圍的特定流量。

例如，在 AWS WAF 中，您可以建立允許清單規則，以便如果請求來自特定的 IP 位址或位址範圍，或符合已知的 URL 模式和 HTTP 方法，則不會套用某些簽章檢查。這有助於：

• 防止內部 API 使用「奇怪」的模式 產生持續的誤報.
• 減少對您已認為可信賴的流量進行深度檢測所帶來的延遲。
• 減少WAF日誌中不必要的記錄數量。

在 ModSecurity 等平台上，建議的做法不是修改標準規則（例如 OWASP 核心規則集），而是根據規則 ID為特定參數、路徑或使用者建立特定的排除項。這樣既能保持整體防護，又不會因為禁用整個站點的規則而造成巨大的安全漏洞。

關鍵在於對允許清單進行精準設置，而不是一刀切。與其全域停用規則 X，不如排除特定的組合（例如 URL Z 中的規則 X + 參數 Y）。這樣既能確保日誌記錄的有效性，又能避免造成不必要的盲點。

協議規則和限制：何時阻止，何時發出警告

許多Web應用防火牆（WAF）都整合了一套HTTP協定清理規則，作為格式錯誤或可疑流量的第一道過濾。這些規則會檢查必需的標頭、方法、參數大小等，如果理解不當，它們既能提供有效的保護，也容易導致誤報。

一些非常常見的例子：

• 缺少 Accept 標頭 （缺少 Accept 標頭）：這嚴格來說並不違反 RFC 規範，但許多缺少此標頭的請求都來自自動化工具或編寫不佳的腳本。這可能會影響自訂 API 或不傳送此標頭的用戶端。在許多情況下，記錄日誌並進行計數比直接阻止請求更可取。
• 缺少主機頭根據 HTTP/1.1 標準，Host 標頭是必要的。 WAF 也需要它來決定應用哪種策略。通常情況下，阻止此類請求是合理的，但在測試期間或由於內部流量配置錯誤，可能會產生誤報；建議在啟用嚴格阻止之前監控日誌。
• 缺少 User-Agent 標頭這條規則旨在遏制基礎機器人和未識別流量。問題在於，許多合法的 API 可能不會發送 User-Agent。最明智的做法通常是記錄日誌，如果檢測到持續且合法的 API， 將其 IP 位址或模式新增至允許清單中.
• GET/HEAD 驗證與主體雖然 RFC 並未嚴格禁止在 GET 或 HEAD 請求中傳送請求體，但這並非常見做法，並且可能表示存在規避行為。在許多情況下，第一步是記錄所有這些請求，如果發現可疑異常，則應將其封鎖。
• 缺少包含 body 的 Content-Type如果請求體存在但沒有 Content-Type 訊息，則明顯表示協議使用不當或試圖逃避分析。在這種情況下，採取更嚴格的攔截措施通常是合理的，尤其是在面向網路的環境中。

除了這些協定規則之外，參數限制通常也用於防止應用層洪水攻擊和拒絕服務攻擊。例如：

• 每個請求的最大參數數（在某些 WAF 中預設值為 255）。
• 單一參數的最大長度（例如，400 個字元）。
• 所有參數的總大小（例如，64.000 位元組）。

這些值對於許多應用場景來說都是合理的，但在某些情況下——例如複雜的表單上傳、進階篩選、大型 JSON 載入——可能會出現誤報。在這些情況下，最謹慎的做法是先記錄並統計造訪次數，檢查哪些端點超出了限制，然後僅針對這些路由進行調整，而不是解除整個網站的所有限制。

假陽性：如何檢測它們而不至於白費力氣

誤報是指WAF將合法請求識別為惡意請求並進行攔截或標記為攻擊。誤報難以避免，尤其是在啟用OWASP CRS等全面規則集的情況下，但可以透過專業管理避免成為日常煩惱。

檢測誤報首先要仔細審查日誌。這包括檢查哪些請求被封鎖、觸發這些請求的規則以及請求發生的上下文（URL、參數、使用者、來源等）。視覺化工具和儀表板可以幫助識別 403 錯誤激增或異常模式。

雲端服務供應商和 ModSecurity 社群都強烈建議使用模擬模式或計數模式。在這種模式下，您要測試的規則會記錄每次匹配，但不會進行任何封鎖。例如，這樣您就可以在正式啟用新的 SQL 注入規則之前，請查看它會阻止多少合法的請求。

在接收真實或模擬流量的測試環境或預生產環境中測試規則也是一個好主意。 OWASP ZAP 等工具或流量重播腳本可以幫助您模擬合法模式和已知攻擊，從而測試 WAF 的行為。

此外，必須重視誤報對營運和聲譽的影響：支付中斷、用戶註冊失敗、關鍵 API 呼叫無故失敗——所有這些都可能直接導致收入和品牌形象受損。過多的誤報也會讓安全團隊疲於應對大量無價值的警報，難以辨識真正的安全事件。

調整規則和智慧利用註冊表的策略

管理誤報並非是關閉規則直到“一切正常”，而是要像外科手術一樣精準地微調 Web 應用框架 (WAF)。以下這些良好實踐正是在此發揮作用：

首先，避免全域禁用規則。最好建立非常具體的例外：僅針對特定路由、特定參數或內部流量排除規則 ID。這樣，既能確保應用程式其他部分的安全，又能保留有用的日誌。

其次，在實施阻止之前，利用計數模式。最初僅在日誌模式下啟動新規則，可以讓你衡量有多少合法請求會受到影響。你可以結合 SIEM 中的警報功能，快速偵測規則是否產生了異常數量的匹配項。

第三，將WAF與SIEM或集中式日誌平台整合。這樣可以更輕鬆地將WAF事件與其他指標關聯起來，例如異常系統活動、大規模身份驗證失敗、可疑的配置變更等。此外，它還有助於根據事件的嚴重性和頻率確定優先調整哪些規則。

第四，務必記錄每一次變更：調整了哪一條規則，針對哪個端點，依據什麼理由，以及提供了哪些證據。查閱伺服器手冊會很有幫助。這份文件不僅有助於維護內部控制，而且在安全審計和審查中也至關重要，因為它可以證明控制措施並非輕易停用。

WAF 中的自動化、機器學習和自適應規則

隨著應用程式的成長和流量的日益複雜，手動管理WAF變得越來越不切實際。這時，自動化、進階日誌分析以及在某些情況下機器學習就派上了用場。

首先，與 SIEM 的整合可讓您建立關聯規則和自動回應：例如，如果一組 IP 重複觸發注入或 XSS 規則，您可以產生自動操作，將這些 IP 新增至臨時黑名單或加強檢查等級。

其次，一些WAF整合了機器學習模式，用於在設定的時間內觀察合法流量。基於這些數據，它們會提出或調整正常行為的閾值、模式和特徵。這有助於在規則切換到阻止模式時減少誤報，並檢測後續的流量偏差。

在研究和實驗室環境中，監督學習技術已被用於訓練區分合法流量和惡意流量的模型，從而改進策略，這些策略隨後會被應用於生產環境中。雖然這種方法並非萬能，但它可以幫助發現傳統基於特徵碼的規則難以檢測到的細微模式。

最後，持續自動化測試（使用 OWASP ZAP 等工具、自訂腳本或 CI/CD 管線）可以驗證 WAF 的變更不會破壞關鍵功能或留下明顯的漏洞。將這些測試整合到部署週期中，使安全性成為開發流程的自然組成部分，而不是臨時修補。

每個應用程式的策略設計和每個服務的黑名單

在複雜的環境中－例如託管服務供應商或網際網路服務供應商－單一的Web應用防火牆（WAF）策略是不夠的，尤其是在涉及影子IT的情況下。通常情況下，同一個負載平衡器後面會運行多個域或應用程序，而每個域或應用程式都有不同的安全性需求和流量特徵。因此，設計針對特定服務的策略和清單至關重要。

一個典型的例子是，HTTP/S 負載平衡器充當反向代理，為多個網站（例如 www.company1.com 和 www.company2.com）提供流量，這些網站都位於同一個虛擬 IP 位址之後。在這種情況下，WAF 可以配置為在請求到達時立即評估 Host 標頭和來源 IP 位址，甚至在請求到達負載平衡模組之前就進行評估。

其邏輯大致如下：WAF 檢查SERVER_NAME（主機名稱）和客戶端 IP的組合是否與特定站點的黑名單相符。如果該 IP 在 www.company2.com 的黑名單中被屏蔽，但在 www.company1.com 的黑名單中未被屏蔽，則僅在前者的情況下發送 403 Forbidden 回應。然後，該「正常」流量會傳遞給負載平衡模組，由哪個後端伺服器處理請求。

這樣一來，就可以維護例如特定網域的黑名單，而不是為整個存取點使用單一的全域黑名單。在日誌級別，每次拒絕都會記錄在系統日誌中，其中包含規則 ID、匹配條件、URL、主機和客戶端 IP 位址等詳細信息，從而便於後續分析以及擴展或調試這些黑名單。

這個故事告訴我們，策略劃分得越細（按應用程式、環境、使用者類型），就越能更好地在日誌記錄和阻止之間取得平衡：例如，你可以對管理入口網站非常嚴格，而對資訊網站則稍微靈活一些，但始終要在日誌中記錄每個決定的原因。

超越傳統WAF：WAAP和API保護

威脅情勢瞬息萬變。如今，許多應用程式都是雲端原生應用，採用微服務架構，並暴露公有和私有 API，這使得它們成為攻擊者的主要目標。傳統的 Web 應用防火牆 (WAF) 已演變為更廣泛的平台，稱為 Web 應用和 API 保護 (WAAP) 或 Web 應用和 API 安全 (WAAS)。

這些解決方案不僅可以自動發現 Web 應用程序，還可以識別 API 端點，接受 OpenAPI 或 Swagger 等規範，並使用該定義來檢查請求的合規性：預期資料類型、允許的參數、大小限制等。根據端點的不同（例如，處理高度敏感資料的端點），可以應用更高層級的審查和阻止措施。

在日誌級別，WAAP 傾向於產生包含豐富上下文的事件：具體是哪個 API 端點受到了攻擊，使用了哪個操作（GET、POST、PUT 等），涉及了哪個用戶或令牌，違反了規範的哪一部分等等。這使得我們可以做出更精確的阻止決策，而不是只依賴通用的有效載荷模式。

此外，許多WAAP工具都包含針對特定應用程式和API的DoS防護、地理位置過濾、IP信譽管理、機器人和爬蟲偵測，以及針對每個服務自訂警報等級的選項。再次強調，關鍵在於能夠靈活地決定哪些方面需要更強大的防護措施，哪些方面需要優先考慮流暢運行，同時又不犧牲可靠的日誌資料庫以用於事件調查。

綜合來看，一個經過良好調校的 WAF（無論是傳統的、基於 WAAP 的，還是整合到雲端生態系統中的）都成為了現代應用程式和 API 防禦的重要組成部分，能夠結合詳細的日誌記錄、智慧阻止和對不斷變化的威脅情勢的持續適應。