摘要：通過可視化操作，將安全任務(wù)靈活編排成掃描流程。失效轉(zhuǎn)移失效轉(zhuǎn)移又稱故障切換，指系統(tǒng)中其中一項設(shè)備或服務(wù)失效而無法運作時，另一項設(shè)備或服務(wù)即可自動接手原失效系統(tǒng)所執(zhí)行的工作，在須彌用于保障任務(wù)執(zhí)行過程中的執(zhí)行狀態(tài)。

1.分布式安全服務(wù)編排概念

2.須彌(Sumeru)關(guān)鍵實現(xiàn)思路

3.應(yīng)用場景

在筆者理解，安全防御的本質(zhì)之一是增加攻擊者的攻擊成本，尤其是時間成本，那么從防御的角度來說，如何盡早和及時地發(fā)現(xiàn)潛在的安全風(fēng)險變得尤為重要，因此安全掃描對時效性要求很高。在進行自身檢測的同時，數(shù)以萬計攻擊者也在時刻探測著你的安全風(fēng)險，樂觀者可能不以為然，但事實上做安全就是木桶原理，短板是攻擊者的首選。如果加上驗證程序開發(fā)和落地的時間開銷，可能又會造成一定的發(fā)現(xiàn)時延。有時候出了問題，就要與時間賽跑，及時避損或止損。

另外，分布式技術(shù)一直以來被用于解決單機性能瓶頸，而且像漏洞掃描器這類安全產(chǎn)品開發(fā)者對分布式這個概念也一直有著很深的執(zhí)念，因為在漏報率和誤報率達到某種瓶頸之后，掃描速度成為了另外一個突破口。

安全掃描周期較長也是我們在之前實際工作中遇到的痛點，加上安全防御是整個面而不是單個點，所以想要形成面，需求真的是不要太多，所以掃描工具研發(fā)和運維成本較高的問題也同樣令人頭禿，借此，本文為大家介紹宜信安全團隊?wèi)?yīng)用分布式安全服務(wù)編排的實踐經(jīng)驗，雖說依然存在許多不足之處，但也達成了不少預(yù)期效果，總之，希望大家能有所收獲或參考。

舉例：端口掃描周期較長，目標(biāo)：10000+個IP ，全端口+服務(wù)指紋掃描，從7小時優(yōu)化到30分鐘內(nèi)。Masscan 做端口掃描要保持穩(wěn)定的速率（根據(jù)實際不同的網(wǎng)絡(luò)環(huán)境而定），否則會造成大量的漏報，所以單機多進程方案并不可靠。

充分發(fā)揮服務(wù)器I/O和計算資源

提供應(yīng)用開發(fā)機制，支持一鍵導(dǎo)入導(dǎo)出和版本管理。

通過可視化操作，將安全任務(wù)靈活編排成掃描流程。

滿足日常需求快速上線和迭代 ，如情報收集，目標(biāo)監(jiān)控，特定掃描等等

提供SDK和Restful API ，方便其他平臺進行調(diào)用

有的同學(xué)可能對安全服務(wù)編排比較陌生，先來簡單解釋下：服務(wù)編排是微服務(wù)體系里的概念，編排（Choreography）指通過消息的交互序列來控制各個部分資源的交互。而參與交互的資源都是對等的，沒有集中的控制。

安全服務(wù)編排我們可以理解為 通過一系列獨立安全服務(wù)相互調(diào)用構(gòu)成的工作流，如下圖所示，每一個方框都代表著一個獨立的安全服務(wù)，通過互相調(diào)用，形成了一個完整工作流。

通常，安全風(fēng)險檢測就是一個完整工作流，而不是單一的功能模塊，如上圖所示，我們做端口掃描的目的除了用于檢測高危暴露端口之外，還會用于作為弱口令掃描，PoC掃描等等的掃描目標(biāo)，掃描完之后可能還需要繼續(xù)進行過誤報處理或通知告警等行為?，F(xiàn)實中開源和商業(yè)的安全產(chǎn)品(工具)數(shù)量都很多，功能也比較參差不齊，我們大多需求都是希望能將他們部分功能進行組合，所以我們的做法是將安全產(chǎn)品(工具)抽象成應(yīng)用形式的安全服務(wù)，舉例來說，業(yè)界比較出色的兩款端口掃描工具都具備各自的優(yōu)勢：

Masscan，高速無狀態(tài)端口掃描

Nmap，具備豐富服務(wù)指紋掃描

我們?nèi)绾螌⑦@兩種工具的特性結(jié)合為我們所用？ 現(xiàn)有常見的做法一般是通過像Python這種膠水語言把他們粗暴地整合在一起，而這樣一來，出現(xiàn)了整合成本較大的問題，具體來說主要有兩方面：

難以靈活組合以及復(fù)用

掃描規(guī)模受限

而另外一種情況，具備自研能力的甲方團隊，由于研發(fā)成本的考慮，大多都采用了開源工具進行二次開發(fā)，所以將工具們通過編碼的方式深度集成，帶來的開發(fā)代價是無疑是巨大的，那么有沒有稍微優(yōu)雅一些的解決方案呢？下面我們來看看編排的特點：

編排的關(guān)鍵在于流程+適配,

流程是將各個任務(wù)串成一個工作流

適配是把任務(wù)之間的數(shù)據(jù)打通

看起來編排似乎能解決我們的一部分問題，為了更為方便地實現(xiàn)和驗證上述概念，我們使用Python開發(fā)了須彌Sumeru分布式任務(wù)調(diào)度框架，須彌脫胎于宜信的分布式掃描器摘星，將底層分布式任務(wù)執(zhí)行邏輯進行抽離。

須彌Sumeru實現(xiàn)了可視化拖拽的編排概念，無論是在設(shè)計階段還是結(jié)果展示階段我們都可以通過一個樹形結(jié)構(gòu)來觀察我們的任務(wù)執(zhí)行情況，下圖為須彌任務(wù)編排的編輯界面截圖，可以將不同的應(yīng)用通過拖拽的方式進行任意編排，下圖就是一個日常的綜合掃描計劃任務(wù)，將IP解析，Masscan端口掃描，Nmap服務(wù)指紋掃描，敏感目錄掃描，PoC掃描整合成了一個完成的工作流：

同時提供了樹形結(jié)果展示界面，會實時刷新任務(wù)執(zhí)行狀態(tài)，為用戶提供一個直觀的任務(wù)執(zhí)行概況，不同的任務(wù)狀態(tài)會體現(xiàn)在點的顏色上:

根據(jù)Imperva對GitHub代碼庫的調(diào)查數(shù)據(jù)表明，目前的GitHub代碼庫中，有超過20%的網(wǎng)絡(luò)攻擊工具或PoC代碼都是采用Python編寫的，Python變成了黑客開發(fā)網(wǎng)絡(luò)攻擊工具時的首選語言。須彌承載了一些已有工作的優(yōu)化期待和對之后工作的愿景，同時也參考了很多已有的分布式任務(wù)調(diào)度框架如Python實現(xiàn)的Celery,Java實現(xiàn)的XXL-job 和 Elastic-job等，發(fā)現(xiàn)并沒有能很好滿足我們的需求。同時，很大部分常用的開源安全工具都是由Python實現(xiàn)或有Python實現(xiàn)的調(diào)用類庫，所以基于Python實現(xiàn)的分布式任務(wù)調(diào)度框架成為了須彌的目標(biāo)定位，下面為大家介紹比較關(guān)鍵的幾個功能點，同時貼出功能架構(gòu)圖供大家參考。

重新創(chuàng)造一個已有的或是已被其他人優(yōu)化的基本方法，在業(yè)界大家都稱之為造輪子，所以復(fù)用的意義即如何避免重復(fù)造輪子，也就是將重復(fù)性的工作更通用地抽象出來，我們的需求很簡單，就是將功能各異的工具變成可復(fù)用的輪子,這與微服務(wù)的思想如出一轍，但又有稍許不同，光有輪子還不行，我們需要讓輪子轉(zhuǎn)起來，先說說我們?nèi)绾螌⑤喿愚D(zhuǎn)起來, 關(guān)鍵的步驟主要有兩點：

轉(zhuǎn)化，即應(yīng)用開發(fā)— 將第三方工具的交互接口抽象成應(yīng)用。

組裝，即編排設(shè)計— 設(shè)計應(yīng)用之間的調(diào)用關(guān)系。

應(yīng)用開發(fā)是落地實施的第一步，所以須彌設(shè)計了應(yīng)用中心的功能，方便對應(yīng)用進行版本管理和分發(fā)，同時提供應(yīng)用一鍵導(dǎo)入導(dǎo)出。如應(yīng)用中心截圖所示：

應(yīng)用的概念讓安全服務(wù)或工具具有獨立性，更適合進行維護和開發(fā)迭代。

這里提到了傳統(tǒng)分布式任務(wù)調(diào)度框架實現(xiàn)過程中很關(guān)鍵的兩個概念:任務(wù)分片和失效轉(zhuǎn)移，前者為了提升性能，后者為了提高可用性。

任務(wù)分片就是將一個較大規(guī)模的任務(wù)進行更細力度的數(shù)據(jù)并行，來提升整個系統(tǒng)的吞吐量，對分布式性能的提升起到了至關(guān)重要的作用。那么到底什么是任務(wù)分片呢？ 我們下面舉個例子來說明一下：

假設(shè)我們有2個掃描目標(biāo)
IP：192.168.1.1 , 192.168.1.2 ，

2個用戶名：admin,guest，

2個密碼：123456,111111，
如下所示：

target 192.168.1.1 , 192.168.1.2

username admin,guest

password 123456,111111

如果設(shè)置了切片選項，Sumeru會使用笛卡兒積計算來支持任務(wù)分片，分片后：
2 2 2 = 8 共8個分片

192.168.1.1，admin ，123456
192.168.1.1，admin ，111111
192.168.1.1，guest ，123456
192.168.1.1，guest ，111111
192.168.1.2，admin ，123456
192.168.1.2，admin ，111111
192.168.1.2，guest ，123456
192.168.1.2，guest ，111111

如果沒有分片，這8個任務(wù)只能作為一個整體，無法分配到各個執(zhí)行節(jié)點上分布式執(zhí)行，而且無法更細粒度地進行失效轉(zhuǎn)移 ，任務(wù)分片后，須彌會根據(jù)編排和分片結(jié)果生成一個用于保存任務(wù)狀態(tài)的任務(wù)樹，并根據(jù)基于負載均衡等多種調(diào)度算法來進行任務(wù)分配執(zhí)行節(jié)點。

失效轉(zhuǎn)移(Failover) 又稱故障切換，指系統(tǒng)中其中一項設(shè)備或服務(wù)失效而無法運作時，另一項設(shè)備或服務(wù)即可自動接手原失效系統(tǒng)所執(zhí)行的工作，在須彌用于保障任務(wù)執(zhí)行過程中的執(zhí)行狀態(tài)。

我們設(shè)計以下兩種情況會觸發(fā)失效轉(zhuǎn)移，如下圖所示（紅色代表異常狀態(tài)）:

任務(wù)出現(xiàn)異常， 包括任務(wù)管理器捕獲的異常和用戶主動拋出的異常。

執(zhí)行節(jié)點出現(xiàn)異常。

我們這里有一個實際應(yīng)用場景，實現(xiàn)了自適應(yīng)內(nèi)外網(wǎng)域名端口掃描，后文會有介紹。

Sumeru還支持設(shè)置超時，如果超出指定時限會被視為任務(wù)出現(xiàn)異常，防止任務(wù)由于未知原因?qū)е碌膾炱稹?/p> 守護模式

守護任務(wù)模式，適用于對外提供服務(wù)的場景，如風(fēng)控規(guī)則引擎這類，是基于數(shù)據(jù)并行的數(shù)據(jù)處理類應(yīng)用，分布式節(jié)點會明顯提高其性能。

具體來說就是守護進程（線程）模式，用戶可以根據(jù)實際場景來選擇線程或進程模式，所以我們統(tǒng)稱為守護模式。

常規(guī)任務(wù)一般是一次執(zhí)行完畢或周期性計劃任務(wù)執(zhí)行 ，而在一些場景下，我們卻希望任務(wù)一直保持運行狀態(tài)，對外提供服務(wù)類應(yīng)用（如被動掃描的代理應(yīng)用，提供HTTP服務(wù)應(yīng)用），像實時數(shù)據(jù)處理類應(yīng)用（如風(fēng)控規(guī)則引擎），與常規(guī)任務(wù)不同的是，我們要能盡可能地保證這些任務(wù)的存活狀態(tài)，如果任務(wù)勾選了守護模式，調(diào)度中心會保證該任務(wù)在分組內(nèi)有且只有一個任務(wù)實例運行，如果節(jié)點出現(xiàn)異常，將會進行失效轉(zhuǎn)移到其他節(jié)點。

須彌提供了分發(fā)選項，如果勾選，將會在節(jié)點分組內(nèi)每個節(jié)點上保證有且只有一個任務(wù)實例。

其他特性也簡單做一下列舉：

基于ETCD實現(xiàn)的Scheduler - HA，為保證整個調(diào)度中心的高可用，我們基于分布式K-V系統(tǒng)ETCD進行了高可用實現(xiàn)

并發(fā)支持:提供線程和進程不同粒度任務(wù)執(zhí)行

秒級計劃任務(wù),支持自定義計劃任務(wù)擴展(如@hourly,@weekly)

提供應(yīng)用開發(fā)套件：基類，調(diào)試，部署，版本管理

提供SDK和RestfulAPI 以及完整的授權(quán)機制

支持郵件通知，數(shù)據(jù)備份，日志ElasticSearch接入等

異步實現(xiàn)

Python2/3兼容

支持Web控制臺形式查看執(zhí)行日志查看，如下圖所示：

其他特性包括任務(wù)生命周期的管理，應(yīng)用可用性檢測，安全通信等，限于篇幅不此詳述。

須彌在設(shè)計之初就是為了解決一些場景下的問題，所以也將這些應(yīng)用場景簡單做下介紹。

1、端口掃描為任務(wù)分片提升掃描性能

性能提升 : Python的性能確實比較低，但大多是計算密集型的場景會產(chǎn)生瓶頸，像安全掃描這種IO密集型的還是不會產(chǎn)生太大的影響，在前文已經(jīng)介紹過分片的原理，這里我們拿具體數(shù)據(jù)來測試一下，切片+分布式的性能提升狀況。我們拿端口掃描為例，10000+個IP ，進行全端口+服務(wù)指紋掃描，如圖所示，節(jié)點{1,3,6,9}分別耗時{25220.28, 5386.728 , 3076.681 ,1624.101} (秒), 優(yōu)化到之前時間消耗的6.4%。

2、失效轉(zhuǎn)移自適應(yīng)網(wǎng)絡(luò)環(huán)境

掃描過程中遇到某個節(jié)點網(wǎng)絡(luò)不通或網(wǎng)絡(luò)不穩(wěn)定的情況，會轉(zhuǎn)移到同分組內(nèi)其他節(jié)點繼續(xù)執(zhí)行，直到所有任務(wù)可以正常運行,如下圖所示。

3、需求快速上線

須彌提供了一套完整的應(yīng)用快速開發(fā)和上線流程。

現(xiàn)有大多數(shù)甲方的安全平臺實際需求都是綜合性比較強的平臺，所以常常被做成一個大而全的工具集合，大多包括掃描工具（Web掃描，被動掃描，主機掃描，端口掃描，Git泄漏掃描），威脅情報，知識庫等等。
大而全的同時，也帶來的維護成本的增加，比如突然新來一個需求：監(jiān)控暗網(wǎng)交易情報，乍一看屬于威脅情報，但又與原來的威脅情報格式，使用和部署方式都完全不一樣。
開發(fā)小哥可能只能無奈地在威脅情報的子菜單里新增一個功能，埋頭去開發(fā)了。 這樣的需求不在少數(shù)，最后整個平臺越來越臃腫難以維護。

如果使用應(yīng)用開發(fā)方式，我們可以將功能抽象成一個應(yīng)用，只需進行應(yīng)用編寫，上線分發(fā)，遠程調(diào)用即可，把服務(wù)和平臺二者分離出來，同時也更加方便團隊協(xié)同的維護。

須彌提供的Restful API使得應(yīng)用作為服務(wù)集成在CI/CD(持續(xù)集成/持續(xù)部署)的過程中更加容易，使用Python來實現(xiàn)，對Python生態(tài)支持也比較友好。如果有同學(xué)遇到比較合適的場景的話，歡迎與我們一起多多交流。

能避免重復(fù)造輪子，能將一部分精力集中在業(yè)務(wù)專業(yè)能力的提升上是我們的初衷，須彌將分布式安全服務(wù)編排的思想基本上都實現(xiàn)了，性能和穩(wěn)定性上的還有不小的提升空間，期待它能發(fā)揮更多的價值。

感謝一起付出努力的小伙伴們！本文之后會有同事繼續(xù)分享相關(guān)內(nèi)容，敬請期待。

作者微信號: lfzark (添加請注明來意)，歡迎大家一起交流，共同進步。

一個想法的落地需要一系列的技術(shù)和資源的去支撐，在甲方公司的安全部門沉下心來打磨安全產(chǎn)品實為不易，感謝那些甚至做出媲美乙方產(chǎn)品的大神們，為我們提供學(xué)習(xí)的榜樣。

宜信安全應(yīng)急響應(yīng)中心（CESRC）網(wǎng)址為：https://security.creditease.cn，該平臺旨在集合安全領(lǐng)域的專家、社會團體及個人共同發(fā)現(xiàn)潛在的漏洞信息，為宜信全線產(chǎn)品和業(yè)務(wù)安全保駕護航，促進白帽子、安全團隊和安全愛好者們與宜信的直接交流與合作，減少、降低可能存在的各類安全隱患。

宜信技術(shù)學(xué)院