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；硬超時直接中斷任務，但沒有日志，就相當于流量丟了，溯源/召回起來很不方便
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/498790.html
標籤：訊息安全