圖1：過去6小時內發生的WAF事件。
2查看此通信觸發的前10個規則ID。 規則ID是進一步過濾流量和觀察各種WAF事件有效負載的好方法。 也就是說，開始按這些規則ID逐一過濾流量，以便進行進一步分析。
圖2：WAF事件觸發的前10個規則。
3．接下來，通過查看匹配值欄位，查看觸發此規則的有效載荷值。
圖3：匹配值列下的有效載荷值。
4分析有效負載值以確定它們是否惡意。 不確定它們是什麼樣子的？ 以下是您可能會在有效負載中找到的幾個潛在惡意值。
- 路徑遍歷：http://some_site.com.br/../../../../some目錄/部分file¹ http://testsite.com/get.asp?f=/etc/passwd²
- LFI漏洞：攻擊者試圖訪問伺服器上的敏感文件，如.ini。預設情況下，Edgecast WAF阻止此文件系統擴展和許多其他關鍵文件系統擴展。³
- 跨站點腳本編寫：http://testsite.test/<腳本>alert(“測試”);</script>⁴ <img src=”http://url.to.file.which/not.exist”onerror=alert(document.cookie);>⁵
- SQL注入：從項目中選擇*，其中‘a’=’a’；⁶選擇1；⁷
- 遠程‘代碼執行：Eval(“\$user =⁸$regdate”);
- 基於時間的攻擊：選擇1和睡眠(2)；⁹選擇基準(2000000，MD5 (‘A’)；¹⁰
5。如果您仍然不確定有效負載是否惡意，則最好的方法是查看使用相應有效負載發起請求的客戶端IP列表。 如果客戶端IP分布(也就是說，變化)，則很有可能該有效載荷被誤報。 但是，如果所有客戶端IP具有相同的值，則表明存在潛在的容量攻擊，從而將其歸類為惡意負載。 爲了證明這一點，讓我們參考步驟3並選擇此匹配值–{“IATA”:[“TGZ”，“MEX”]}並將其用作示例。 要查找發送此負載的客戶端IP列表，請將匹配的值添加為篩選器，如下所示：
圖5：發送有效載荷值的客戶端IP：{“IATA”:[“TGZ”，“MEX”]}。
在本例中，鑑於發出此請求的IP地址多種多樣，這些請求很有可能來自真實用戶，因此很可能會出現誤報。
6。識別出誤報後，您可以在”受管理的規則”部分中為其創建例外，但在執行此操作之前，您需要了解找到此負載的位置，查詢字元串，請求標頭，URL或其他位置。 通過查看步驟5中同一頁上的匹配項列，可以輕鬆完成此操作。 在本使用案例中，有效載荷位於“data”查詢參數中，如下所示：
圖6：有效載荷值的位置：{“IATA”:[“TGZ”，“MEX”]}。
7。一條很好的經驗法則是篩選那些包含誤報有效負載的特定匹配欄位，然後驗證是否沒有任何其他請求與此匹配的參數匹配，該參數帶有實際的惡意負載。 換句話說，特定匹配項欄位中的有效載荷絕不是惡意的。 這是通過在有問題的欄位上添加匹配的過濾器來實現的。 查看我們的使用案例，我們可以確認此查詢參數中沒有任何惡意負載：
圖7：查詢參數中發送的所有有效載荷值：數據。
8。創建異常之前的最後一步是查找由匹配時間欄位觸發的規則ID。 我們正在嘗試記錄此誤報觸發的所有規則(規則ID)。 根據我們的使用案例，此資訊可在步驟5的同一頁面上找到。
圖8：有效載荷值觸發的規則列表：{“IATA”：[“TGZ”，“MEX”]}。
9：是時候創建例外了。 轉到Managed Rules (受管規則)部分，然後單擊要添加這些例外的受管規則。
圖9：為WAF配置創建的現有託管規則。
10轉至例外選項卡，然後單擊添加新條件。 選擇欄位上匹配的類型，如找到有效載荷的args，request_cookies或URL。 然後輸入參數的名稱，如查詢或cookie。 最後，輸入觸發有效載荷的所有規則ID的列表。
