0X01 前言
轉載請標明來源：https://www.cnblogs.com/huim/
本身需要對外有良好的服務能力，對內流程透明，有日志、問題排查簡便，
這里的服務能力指的是系統層面的服務，將掃描器封裝成提供給業務的業務服務能力不在該篇講述范圍內
0X02 簡單的掃描
高端的漏洞往往用最樸實的掃描方法
最簡單的掃描需求，只需要從資料庫中讀取資料，定期跑一遍所有規則就好了，
一個腳本更新資產，一個腳本定時讀取資料、結合規則進行掃描、并把結果打到資料庫里，一個腳本定時讀取結果發郵件，這樣就已經滿足SRC自動化挖漏洞的需求了，而且效果還不錯，
0X03 分布式掃描
隨著掃描的資產變多，單個機器的龜速掃描令人著急，所以運行規則這一步加上分布式，即任務打到佇列(redis/MQ/kafka等)，再由多個節點運行掃描規則、輸出漏洞結果
0X04 幾個資料源掃描
這樣很方便的可以掃描主機漏洞
再往后，不想只單單的掃描主機漏洞了，也想掃描注入/XSS/SSRF/XXE等基于url的漏洞，有了url型別資料，
甚至發現有的漏洞應該是針對域名的(單純的IP+埠請求到達不了負載均衡)，又有了domain型別的資料，
0X05 多任務掃描
這時候生產模塊還能應付得過來，即讀取各型別資料、系結各型別插件，
但是有時候新增了規則，想單純的掃描對著所有資料掃描這條規則，需要另外起腳本加一個臨時的生產者，
有時候新增了一批資產，想單獨對著這批資產掃描所有的規則，又需要臨時寫個生產者腳本，
由此代碼變得冗雜，操作變得繁瑣，于是有了任務的概念，
任務用于系結資料與規則，一個任務就是一個生產掃描子任務的單位，
這樣增量規則掃描全量資料，新增一個任務系結這個規則和對應的資料；增量資產掃描全量規則，新增一個任務系結這批資產和對應的規則，
而從資料庫上操作任務與規則變得不太方便，于是加上了可視化平臺，可在web端發布掃描任務、新增修改規則，
0X06 多資料源掃描
而在甲方內部，隨著接入的資料源越來越多，url資料有鏡像流量、爬蟲流量、代理流量、nginx流量等等，host資料有hids agent流量、黑盒資產探測流量、cmdb/IT等流量，domain有域名爆破流量、內部運維系統獲取的流量等，
每多一個資料源，都得加一段代碼邏輯 : "當資料源是a的時候，從哪哪哪獲取流量資料"，
當資料源數量超過十種，任務模塊的資料源獲取代碼變得很冗雜，且并硬編碼橫行(從哪哪哪獲取資料)、邏輯寫死不通用(a的資料要從介面分頁遍歷、b的資料需要從redis讀、c的資料是kafka、d的資料從資料庫獲取)，
某些資料不走中間的某段過濾匹配邏輯，于是又要加一個欄位 is_xxx 標識 ，再在引擎里 if is_xxx=True，代碼通用性低、高度耦合，遇到bug時排查成本極高，比如遇到這個流量怎么會有這樣的輸出結果、怎么會報錯這類問題時，往往花半天一天追蹤流量，
故而需要對資料源進行改造，統一資料源輸入格式，資料源分幾種型別，url/host/domain，每種型別都有固定的格式，由外部按照這種格式進行輸入，
在資料源過多時，外部的輸入代碼太多了，可額外抽象出來形成資料輸入模塊，
比如定義redis型別資料從哪里獲取、介面怎么分頁獲取資料、資料庫怎么迭代讀取等，再一一配置資料格式轉換方式，這樣再遇到需要新增的流量型別，需要新增的代碼就是可復用的某類資料獲取方式，
0X07 系統間服務能力
但是又遇到一個問題，遇到跨部門或者跨專案需要呼叫掃描能力時，很不方便，輸入上需要自己配置資料來源，還需要掃描開發人員添加這類資料，掃描結果還需要去資料庫獲取，有的沒結果不知道到底是沒掃描還是沒漏洞，
對于業務方，需求增改、服務呼叫不方便，
所以需要提高服務提供的能力，對于呼叫方來說，掃描是一個黑箱子，只管傳入資料、啟動任務、獲取結果，提供給呼叫方的是掃描服務能力，
對于掃描引擎開發方，對外進行引擎能力封裝，服務與上下游拆分開，也實作低耦合、高可維護、可擴展易擴展，不會因需求增改而頻繁改動引擎代碼、從而導致代碼冗余、開發維護成本上升，
實作方式：
資料接入時，呼叫方在管理平臺注冊資料標簽，并在傳入資料時標明資料標簽(抽象資料配置步驟)；
結果輸出時，呼叫方注冊回呼介面(資料打往回呼介面)，掃描結果分有漏洞/無漏洞/沒掃描這一類，回呼介面選擇接收的結果型別；或注冊處置結果標簽，掃描結果打給訊息總線，
回呼方式不知道對方介面設定的狀態，可能介面報錯了訊息沒有正確打過去，可能介面回傳200的 status: false但無法判斷是失敗了，簡單來講就是無法保證資料一致性，掃描結果里有但介面因為報錯沒有這個結果，所以還是盡量使用訊息總線的方式，由消費方對消費失敗的資料進行記錄、排查并作再消費，保證接收結果的介面不會丟資料，
再由注冊方操作任務，系結待掃描的流量的標簽，需要掃描的規則，處置的方式即結果是打給某個回呼或者是打上某個結果標簽，
實作效果：
這樣將引擎封裝起來，基本可以保證引擎中不會因為過多的資料源，而東一塊西一塊，有很多的針對不同資料源讀取的代碼，
引擎本身只保證資料讀取、按照規定的任務選擇掃描規則、將掃描的結果打到結果佇列或者打回給呼叫方，
0X08 全流程日志
但還有另外一個問題，排查問題成本比較大，
掃描器引擎邏輯相比部分產品會比較復雜，主要涉及到其中的存活檢測、集群判斷、白名單限制、QPS控制、任務調度等功能，有時候丟流量或者因為某個欄位不對導致漏報、在插件運行前請求的內容有問題導致判斷為不存活的流量從而漏報，
這些情況在以redis為佇列的引擎中，排查起來比較麻煩，
所以需要全流程的日志：最好能知道幾個關鍵步驟的中間結果是什么樣的，遇到問題時排查方便，掃描器在去重后掃描中間程序資料量不如IDS大 (日百億處理結果)，大概也就上千萬，可以全部記錄下來，資源緊張可以只記錄一段時間，
關于日志種類：我們溯源排查時一般需要的中間結果有資料源、掃描子任務、掃描結果，
關于日志實作：redis pop后資料就沒了，引擎讀后做雙寫比較麻煩，
所以選擇可訂閱的訊息佇列，比如kafka，引擎使用一個group進行訊息消費，再起一個服務用另外的group對這批topic的資料進行存盤，熟悉的ELK結構，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/498792.html
標籤：訊息安全