DAST 黑盒漏洞掃描器 第四篇：掃描效能

0X01 前言

大多數安全產品的大致框架

提高效能的目的是消費跟得上生產，不至於堆積，留有餘力應對突增的流量，可以從以下幾個方面考慮

• 流量：減少無效流量
• 規則：減少規則冗餘請求
• 生產者：減少無效掃描任務
• 引擎：靈活擴縮容的分散式引擎節點

0X02 減少無效流量

2.1 URL

2.1.1 去重——去除重複流量

第三篇2.1.2 、2.1.3 說到去重、流量清洗服務，這裡簡單說一下去重：
同一個邏輯只有一條流量對於掃描器來說是有意義的，長得不同的流量掃描多了是浪費效能。
場景：有如第三篇 2.1.2 所說

去重步驟

(1) 預處理

過濾 CSS/JS/zip等靜態資原始檔，能過濾掉80%以上流量

(2) 歸一化去重

歸一化，即用正則或其他方式，比如列表匹配，判斷某一段路徑或者域名是否在列表中，這種在 {city}.meituan.com中運用；
把URL中相似的部分替換成相同的字串，最後根據歸一化後的值是否相同來判斷是否重複：
把 https://tieba.baidu.com/p/1000000001 替換為 https://tieba.baidu.com/p/1
把 https://bj.meituan.com/meishi/ 替換為 https://{city}.meituan.com/meishi/

再計算逐條規則替換後的url的hash，查詢之前是否有過，沒有該hash才輸出

經過這一步，基本上 日均流量 百億量級-> 百萬量級。具體的設計實現方式不多贅述，挑戰在於百億級別的流量+幾十上百的去重規則下的效能、上百萬key的快取互動。
還有其他細碎的優化，比如不同域名設定不同的規則，動態引數名怎麼判斷保留多少個，同一個引數名下保留多少個引數值，單個快取key的有效時間等。

各類實現思路可以參考關鍵字「URL normalization」的論文，url去重其實已經學術界工業界已經研究了十幾年，比較成熟了。

(3) 相似度去重

在百萬量級的基礎上，進行二次去重，基於頁面相似度 simhash改進的演演算法，再將流量量級降到十萬上下

SimHash演演算法是Google在2007年發表的論文《Detecting Near-Duplicates for Web Crawling》中提到的一種指紋生成演演算法，被應用在Google搜尋引擎網頁去重的工作之中。
也有很多其他優秀且效能更好的頁面相似度演演算法

其實去重說起來也有些類似於搜尋引擎的去重，而目前搜尋引擎的去重演演算法都已經比較成熟了，可以搜尋各種論文，找找這些去重演演算法。
這裡需要注意json格式的響應雖然可能相似，但介面可能各不相同，可以結合URL相似度來做。

2.1.2 去除無效流量

引擎上進行流量格式化前後判斷
(1 是不是40x/50x頁面等不可存取頁面，或者是集團內返回碼200的404頁面(自行收集)

往往有很多無效存取，因為導向返回碼200的40x/50x頁面，導致這一部分的流量漏去重。如果頁面相似度去重已經上了，這一步也可以略過，用作召回去重程式的case。

(2) 排除找不到業務的流量: 映象流量有時候會有奇怪的流量，比如對著nginx構造host等情況，需要排除掉找不到業務的流量。這部分流量即使有漏洞，漏洞找人也比較麻煩，後續無法實現全流程自動化。所以nginx無法解析的、domain沒有記錄的，過濾掉。再將這一部分流量定期彙總，做召回，看是否是nginx問題、或者是domain記錄缺失。
(3) 排除掉惡意流量：流量映象上收集到的流量，有很多是外部掃描器的，目錄爆破/注入檢測/CmsPoc/xss等等，這些沒有意義，且一有就是大量的出現，即浪費了掃描效能、又佔用了大量QPS，可以結合IDS/WAF過濾掉這一部分流量

2.2 HOST

掃描前對IP和埠做一次連線，再探測一遍埠連通性，以避免資料時間過長、埠早已關閉，但又浪費了一些資源去掃描。

IP埠往往無法及時更新，一小時掃一次全內網IP和埠已經是比較迅速了，但仍會有失效的埠，像JDWP這種，業務偵錯時開放、下班了關掉。
如果可以實時監控埠開放與關閉狀態，開放了再進行指紋掃描，不必定時全量掃描，埠存活檢測可只作為召回召回。但埠狀態監控比較麻煩，比如http連線時使用者端開放的埠，請求完就關閉，這種訊息是無效的，拿去作埠指紋識別，海量的資料會浪費很多不必要的效能。

0X03 減少規則冗餘請求

記錄每個掃描規則的7*24平均請求量和執行時間，並設定閾值
請求量過大或者超過一定的執行時間，進行標記或給出告警，再對規則進行優化。
規則本身的效能優化：
比如通過側通道方式檢測注入，比單純的sqlmap純黑盒方式檢測更準、更快，這是甲方優勢（並不是說直接調sqlmap檢測不準確，只是為了檢測更全，risk和level得拉滿，但是請求太多、時長太久）；通過側通道檢測命令執行，大大略過了判斷頁面響應的步驟等等，更準更快。

0X04 減少無效掃描任務

埠指紋匹配，精準化掃描，不生產一些明顯不會有結果的掃描任務，比如對著MySQL埠檢測redis未授權。

在實踐過程中，遇到的情況是埠指紋不明確，所以運營人員也不敢隨便選二級指紋，很多情況都是規則沒有選擇具體框架/服務指紋，也就不管埠有沒有指紋都掃描了，因為規則無具體指紋產出的漏洞佔比較大，直接一刀切、產出驟降。所以只有遇到規則有指紋、埠也有指紋的時候，才進行匹配過濾。
規則指紋匹配，往往難點在於埠指紋打標的準確性。
埠打標流程有了之後，打標的召回、持續運營還是漫漫長路。

有很長一段時間，web的無效任務集中在qps超限後的操作，也就是第三篇 2.1.4的內容。qps控制不能單單的控制到任務、或者是域名層面，而是為了滿足大流量情況，儘可能控制到介面層面，儘可能用可以用的、業務用剩下的qps，這就需要控制的單位往掃描引擎流程後移，儘可能的控制力度更細。
qps的控制最小單位在請求上，而不在任務排程上，這就導致qps控制程式需要應對同一個介面，在同一時間 有多個掃描子任務、多個規則、多個請求的情況。超過了限制，要麼這個掃描子任務丟回佇列等待下次重試，要麼sleep等待可用。
sleep的方式會hang住節點，而重試浪費了大量的效能，甚至有的任務在某個介面超低的業務正常qps情況下是無法完成的。
出現過75%的掃描任務都是在重試和拋棄的路上。所以有了記錄請求hash、從上次重試位置開始再次掃描的斷點重掃功能。在減少無效掃描任務上效果極好。

0X05 分散式節點

分散式實現起來並沒有太多難點，無非是生產者的子任務打到佇列，用多個消費者先入先出式地讀取待掃描的子任務並消費。
引擎節點應只做消費，消費上游生產的掃描任務(規則+流量)，把結果打給下游處置佇列。

節點分散式，可考慮redis/mq+celery的實現方式，也比較成熟。

但是用了那麼久的celery，總覺得celery比較重，監控上雖然有flower，但是流量丟失、記憶體上漲、超時中斷等問題總是排查成本較大。
所以改成上游生產者佇列、下游處置佇列都是kafka的形式。
如此分散式節點只需考慮消費kafka時不導致傾斜的問題即可，擴充套件起來方便，監控上對另外服務記錄kafka紀錄檔，也跳過了celery本身記憶體的頭疼問題，超時中斷可自行實現。

celery的超時中斷有軟超時和硬超時兩種；軟超時即是超時的時候，在當前執行程式碼報錯，但在規則執行時報錯可能會被catch；硬超時直接中斷任務，但沒有紀錄檔，就相當於流量丟了，溯源/召回起來很不方便