一、概要

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

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

3.應用場景

二、前言

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

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

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

三、需求簡述

3.1 縮短安全掃描週期

舉例：埠掃描週期較長，目標：10000+個IP ，全埠+服務指紋掃描，從7小時最佳化到30分鐘內。Masscan 做埠掃描要保持穩定的速率（根據實際不同的網路環境而定），否則會造成大量的漏報，所以單機多程式方案並不可靠。
充分發揮伺服器I/O和計算資源

3.2 降低掃描工具研發和運維成本

提供應用開發機制，支援一鍵匯入匯出和版本管理。
透過視覺化操作，將安全任務靈活編排成掃描流程。
滿足日常需求快速上線和迭代，如情報收集，目標監控，特定掃描等等
提供SDK和Restful API ，方便其他平臺進行呼叫

四、安全服務編排

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

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

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

Masscan，高速無狀態埠掃描
Nmap，具備豐富服務指紋掃描

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

難以靈活組合以及複用
掃描規模受限

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

編排的關鍵在於流程+適配。

流程是將各個任務串成一個工作流
適配是把任務之間的資料打通

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

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

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

五、須彌Sumeru分散式任務框架實現思路

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

5.1 應用-安全即服務（Security as a Service）

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

轉化，即 應用開發— 將第三方工具的互動介面抽象成應用。
組裝，即 編排設計— 設計應用之間的呼叫關係。

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

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

5.2 核心實現：任務分片和失效轉移（Failover）

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

5.2.1 任務分片

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

假設我們有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個任務只能作為一個整體，無法分配到各個執行節點上分散式執行，而且無法更細粒度地進行失效轉移，任務分片後，須彌會根據編排和分片結果生成一個用於儲存任務狀態的任務樹，並根據基於負載均衡等多種排程演算法來進行任務分配執行節點。

5.2.2 失效轉移

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

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

任務出現異常，包括工作管理員捕獲的異常和使用者主動丟擲的異常。
執行節點出現異常。

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

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

5.3 守護模式

守護任務模式，適用於對外提供服務的場景，如風控規則引擎這類，是基於資料並行的資料處理類應用，分散式節點會明顯提高其效能。

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

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

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

5.4 其他特性

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

基於ETCD實現的Scheduler - HA，為保證整個排程中心的高可用，我們基於分散式K-V系統ETCD進行了高可用實現
併發支援:提供執行緒和程式不同粒度任務執行
秒級計劃任務,支援自定義計劃任務擴充套件(如@hourly,@weekly)
提供應用開發套件：基類，除錯，部署，版本管理
提供SDK和RestfulAPI 以及完整的授權機制
支援郵件通知，資料備份，日誌ElasticSearch接入等
非同步實現
Python2/3相容
支援Web控制檯形式檢視執行日誌檢視，如下圖所示：

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

六、應用場景舉例

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

6.1 埠掃描為任務分片提升掃描效能

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

6.2 失效轉移自適應網路環境

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

![圖]（http://college.creditease.cn/resources/upload/image/20190226/1551165711541066481.png）

6.3 需求快速上線

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

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

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

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

七、總結

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

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

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

作者：安全開發李方洲

來源：來源：

【須彌SUMERU】宜信分散式安全服務編排實踐