分散式Web漏洞掃描服務建設實踐系列——掃描架構演進及要點問題解決實踐
提示：文章主要介紹掃描形態演變及大概設計，掃描服務最突出的問題點解決實踐思考，大概閱讀完所需時間10分鐘左右。
Part 1 引言
在大型互聯網公司中，面對5萬+域名、7千萬+的url，同時線上服務各種開源軟體隨意使用，各團隊研發實力及各服務承壓能力參差不齊，在人力極其有限的情況下，漏洞檢測想做好其實壓力和挑戰非常大。你經常需要反省為啥漏洞發現時間滯後於外界白帽子，為啥漏洞未被掃描發現；如何保證掃描的超高準確率，如何保證線上掃描不影響服務正常運行；掃描存在異常時如何監控報警並自動恢復，外界爆出0day時如何做到不影響正在運行的掃描任務而通過調度使應急任務得到快速響應執行，掃描框架或POC更新時如何熱備自動上線，如此等等；這裡面的任何一點想做好挑戰和困難都挺大，我們經過幾年的實踐，在這些方面有了一些自己的感悟，這裡分享給大家。
Part 2掃描服務形態演變
做Web漏洞檢測這塊好幾年，漏洞檢測的形態也經過了幾次演變，由最開始的單機形態到集群，更多的是解決公司URL量太大導致可接受時間範圍內無法掃描完成的窘境。
通過集群的確可以減少掃描的時間，但隨之而來的是機器的非飽和使用導致資源的極度浪費，慢慢集群形態向分散式形式轉換：
一台物理機根據其CPU核數及內存情況被虛擬成多台容器，以"單Poc+單Url"為基本單元，調度程序以基本單元為維度分配到存活的每台空閑虛擬容器中執行，降低了資源的浪費；同時分散式形態也能更好的滿足應急掃描、容災恢復等場景，具體後續再細說。掃描形態的轉換過程中，獨立的掃描腳本向集中的掃描框架方式轉變也隨之發生。
Part 3掃描體系構建
基於分散式的集群形態，最終的掃描體系結構圖如下：
掃描場景及產品
整個掃描體系是基於雲的分散式掃描平台，根據使用場景拆分為三個子平台，覆蓋項目上線前及線上運行；其中上線前安全測試針對項目上線前進行漏洞提前發現，避免將安全漏洞帶入到線上；線上例行是安全團隊對線上所有業務進行完全自動化的每日例行漏洞巡檢；產品自測則是提供給業務方針對線上業務一種安全自查方式，三者互補提升漏洞檢測整體覆蓋面。
掃描架構及突出問題點
集群中每台物理機虛擬化成多個docker容器，每個docker容器中部署多掃描引擎鏡像，引擎根據調度程序分配的基本單元，再去載入具體掃描能力poc運行特定的url；其中每個部分功能點簡單介紹如下：
掃描集群支持優先順序掃描、熱備上線、url粒度監控及跟蹤、掃描狀態實時展示、容器粒度調度及伸縮；
掃描框架支持poc及fuzz模式、poc粒度掃描狀態跟蹤及靈活調度、集成通用邏輯簡化poc開發實現；
Poc除了傳統掃描思路外，加入互動式探測思路，同時考慮邏輯繞過+利用驗證機制，並結合回顯平台、poc自動識別平台等來做到掃描能力的足夠全的覆蓋面和持續自我完善能力。
整個掃描架構涉及內容太多，就不一一細說了，主要拿之前的一個版本升級解決的幾個case舉例來說吧。做漏洞掃描服務的同學經常會對幾個問題比較困惑或者無奈：
（1）掃描漏報排查
掃描POC明顯覆蓋但就是沒有掃出，而且還被SRC報告，對負責掃描的同學來說不可接受（其實特別打臉，偷笑）；此時進行漏報排查必須要去複查掃描當時的場景（有可能剛好掃描後業務有變化導致引入的漏洞，或者剛好掃描時那個節點有異常等，其實各種情況都可能引起漏報）；當時掃描的信息就至關重要了：當時URL庫中是否存在該url？是否在掃描集群中掃描過？曾經一共掃描了多少次？分別在什麼時候掃描的？是在掃描集群的哪個節點上掃描的？當時掃描時該掃描節點是否存在異常？掃描poc是否存在異常？掃描集群是否存在異常？當時掃描時掃描結果是？工單是否推送正常？甚至於當時的響應是？這些我們統統需要知道。
為了解決這個問題，我們記錄了一個URL從數據中心取出，到掃描集群、掃描框架、掃描節點、結果入庫、工單推送等各個階段所發生的一切關鍵行為，一旦有漏報發生排查就會比之前容易很多，以前基本就是無可奈何（沒有當時場景，我能怎麼辦？怪我咯）。
（2）異常監控及診斷恢復
之前掃描存在異常時我們無法及時感知，往往都是外界報告了一個case，我們去排查才發現，這種其實就比較滯後和被動了；需要一種手段去感知異常，存在異常時能夠自動報警，甚至在特定的場景下能夠自動恢復續掃或者重掃。
為了漏掃排查我們記錄了很多關鍵信息，在此基礎上，我們慢慢發現異常監控也好做了，比如其實可以提前大概計算或者統計每種poc大概的平均掃描耗時，當poc真實在掃描節點上掃描時一旦明顯偏離這個基準耗時，就可以認為這裡存在一個異常點並進行記錄，可以簡單調度掃描框架重新掃描這個單元（"單poc+單url"）；比如當類似的異常點突然在某一時間點報出的特別多，此時就可以進行報警了，很有可能我們的掃描集群此時不健康需要人為干預排查。還比如一個掃描任務下發後，發現一個基本單元超時未返回結果，一樣可以自動診斷並處理；還比如可以監控一段時間庫中URL的入庫量是否有異常、每天及每周的漏洞產出是否有異常（總漏洞產出量，單個poc漏洞產出量與基準值的對比衡量）、總的掃描時間是否有異常等，及對應的自動診斷恢復機制，最終判斷是否需要人為干預。
（3）掃描優先順序
由於掃描平台需要為測試環境，線上環境等進行測試服務，並且業務量本身就很大，導致掃描集群一直都是滿負荷在運行，但是平時實際過程中，經常會有應急響應需求，需要進行應急掃描，此時如何保證緊急的任務能夠第一時間執行呢？
以前只能等待掃描任務完成（可能需要等待很長時間，這是所不能接受的），才能執行本次緊急任務；為了不耽誤緊急任務的執行，甚至平時只能搭建一個空閑集群，專門用於緊急任務執行，但是資源嚴重浪費；那是否可以考慮通過單一集群即可解決優先順序的問題呢？
當然可以，通過優先順序機制即可解決，優先任務優先分配、優先調度、優先掃描，通過三級優先隊列來解決緊急掃描問題；同時在任務分配時候，以「單poc+單url」作為最小粒度，考慮poc發包量基礎上，按照可用掃描節點進行平等拆分，這樣即使集群沒有空閑節點，一旦有緊急任務需要掃描，那麼任務所需等待的時間最理想情況下將只需要等待「單個poc+單個url」所需要的掃描時間（資源足夠情況下，這種理想情況其實很大概率會發生），這種不用浪費資源即可滿足優先掃描難題。
（4）熱備上線
安全掃描poc在方案調研及實現過程中，由於調研的不全面或者考慮的不嚴謹，肯定會出現誤報或者漏報問題，這時候就需要通過更新poc予以解決，現在的難點是：掃描集群時刻都有任務在運行，為了更新任務只能熱備上線，不然只能將未跑完的任務全部kill掉，這樣既浪費掃描資源，又嚴重影響掃描及時度；通過內置升級更新模塊，做到不干擾當前運行任務情況下，更新節點掃描鏡像，做到熱備上線。
數據中心建設
接下來簡單說下數據中心這部分，數據中心主要負責純凈url的收集入庫，解析程序每天解析T級別的日誌，如果不去重的話將得到億級別的url，為了保證掃描的及時度，需要對url進行去重去臟，主要通過hash機制進行：
https://www.baidu.com/test.php?a=1&b=2&c=3
https://www.baidu.com/test.php?c=10&a=20&b=30
針對每條URL，去掉參數值並根據key進行排序，計算hash =md5("https://www.baidu.com/test.php?a&b&c")，相同的認為兩條URL是相似的，只保留一條URL即可（ps：當然這裡存在後端代碼邏輯覆蓋不全的問題，因為有些後端邏輯是根據參數值進行判斷的，覆蓋這部分邏輯會導致待掃描的URL量急劇增加，被迫做了取捨，無奈的表情）。同時計算hash的時候還需要考慮幾種特殊case：
除了這些具有明顯特徵的case外，其實還存在很多無規則的case；本質我們其實是需要一種方法去判別path中偽靜態的部分（path中根據"/"進行分割），針對偽靜態的部分用相同長度的字元U進行替換即可；考慮用機器學習方法以分割部分的字元數量作為feature去判別，大部分的case其實都可以很好的識別出來，但不能很好區分純小寫字元的case，比如/api/yehdhee這種，最終通過引入Markov Chain來進行區分，基本可以解決。
除了去重去臟外，還需要定期對庫中已存在的url進行存活判斷、404判斷等，針對這部分url需要定期進行刪除處理；不過url存活判斷務必放在掃描臟數據凈化之後（特指帶有掃描攻擊payloads的url），不然你可能會不幸成為攻擊者攻擊自身業務的幫手（偷笑）
Part 4總結
掃描服務累計在線上運行好幾年了，到目前為止已經非常成熟，基本做到了無需人為干預（存在重大bug時其實還是需要人為干預，偷笑），存在異常時自動監測報警並自動排查恢復，POC更新時自動熱備更新、高優任務第一時間優先執行而不影響之前正常運行的掃描任務，掃描出來的漏洞準確率達到98%以上基本可以做到無需人工check，輸入源URL存在的情況下漏報率更是控制在0.5%以下，每天例行的任務控制在2小時內結束，漏洞發現及時度大幅提升，高危漏洞滯後於外界白帽子的case少之又少（輸入源url不缺失情況下），基本實現了我們之前的預期及目標。同時也深深領悟了一句話"掃描技術雖已成熟，但只有精心耕耘方能知曉其精髓，而剛觸及其精髓才知挑戰依舊"，分享給大家。
本文只是簡單概述了整個掃描體系，如果對掃描集群、掃描框架、掃描POC、掃描策略等詳細做法感興趣的小夥伴可以繼續關注後續"分散式Web漏洞掃描服務建設實踐"系列技術文章。
TAG:百度安全應急響應中心 |