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

1.分布式安全服務編排概念

2.須彌(Sumeru)關鍵實現思路

3.應用場景

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

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

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

舉例：端口掃描周期較長，目標：10000+個IP ，全端口+服務指紋掃描，從7小時優化到30分鐘內。Masscan 做端口掃描要保持穩定的速率（根據實際不同的網絡環境而定），否則會造成大量的漏報，所以單機多進程方案并不可靠。

充分發揮服務器I/O和計算資源

提供應用開發機制，支持一鍵導入導出和版本管理。

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

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

提供SDK和Restful API ，方便其他平臺進行調用

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

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

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

Masscan，高速無狀態端口掃描

Nmap，具備豐富服務指紋掃描

我們如何將這兩種工具的特性結合為我們所用？ 現有常見的做法一般是通過像Python這種膠水語言把他們粗暴地整合在一起，而這樣一來，出現了整合成本較大的問題，具體來說主要有兩方面：

難以靈活組合以及復用

掃描規模受限

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

編排的關鍵在于流程+適配,

流程是將各個任務串成一個工作流

適配是把任務之間的數據打通

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

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

同時提供了樹形結果展示界面，會實時刷新任務執行狀態，為用戶提供一個直觀的任務執行概況，不同的任務狀態會體現在點的顏色上:

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

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

轉化，即應用開發— 將第三方工具的交互接口抽象成應用。

組裝，即編排設計— 設計應用之間的調用關系。

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

應用的概念讓安全服務或工具具有獨立性，更適合進行維護和開發迭代。

這里提到了傳統分布式任務調度框架實現過程中很關鍵的兩個概念:任務分片和失效轉移，前者為了提升性能，后者為了提高可用性。

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

假設我們有2個掃描目標
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

如果設置了切片選項，Sumeru會使用笛卡兒積計算來支持任務分片，分片后：
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個任務只能作為一個整體，無法分配到各個執行節點上分布式執行，而且無法更細粒度地進行失效轉移 ，任務分片后，須彌會根據編排和分片結果生成一個用于保存任務狀態的任務樹，并根據基于負載均衡等多種調度算法來進行任務分配執行節點。

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

我們設計以下兩種情況會觸發失效轉移，如下圖所示（紅色代表異常狀態）:

任務出現異常， 包括任務管理器捕獲的異常和用戶主動拋出的異常。

執行節點出現異常。

我們這里有一個實際應用場景，實現了自適應內外網域名端口掃描，后文會有介紹。

Sumeru還支持設置超時，如果超出指定時限會被視為任務出現異常，防止任務由于未知原因導致的掛起。

守護任務模式，適用于對外提供服務的場景，如風控規則引擎這類，是基于數據并行的數據處理類應用，分布式節點會明顯提高其性能。

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

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

須彌提供了分發選項，如果勾選，將會在節點分組內每個節點上保證有且只有一個任務實例。

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

基于ETCD實現的Scheduler - HA，為保證整個調度中心的高可用，我們基于分布式K-V系統ETCD進行了高可用實現

并發支持:提供線程和進程不同粒度任務執行

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

提供應用開發套件：基類，調試，部署，版本管理

提供SDK和RestfulAPI 以及完整的授權機制

支持郵件通知，數據備份，日志ElasticSearch接入等

異步實現

Python2/3兼容

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

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

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

1、端口掃描為任務分片提升掃描性能

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

2、失效轉移自適應網絡環境

掃描過程中遇到某個節點網絡不通或網絡不穩定的情況，會轉移到同分組內其他節點繼續執行，直到所有任務可以正常運行,如下圖所示。

3、需求快速上線

須彌提供了一套完整的應用快速開發和上線流程。

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

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

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

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

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

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

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

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

宜信技術學院