須彌SUMERU：宜信分佈式安全服務編排實踐

摘要：安全防護的本質之一是增長攻擊者的攻擊成本，尤爲是時間成本。而如何儘早和及時地發現潛在的安全風險變得尤其重要，所以安全掃描對時效性要求很高。本文爲你們介紹宜信安全團隊應用分佈式安全服務編排的實踐經驗。

1、概要

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

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

3.應用場景

2、前言

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

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

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

3、需求簡述

3.1 縮短安全掃描週期

• 舉例：端口掃描週期較長，目標：10000+個IP ，全端口+服務指紋掃描，從7小時優化到30分鐘內。Masscan 作端口掃描要保持穩定的速率（根據實際不一樣的網絡環境而定），不然會形成大量的漏報，因此單機多進程方案並不可靠。

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

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

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

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

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

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

4、安全服務編排

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

安全服務編排咱們能夠理解爲 經過一系列獨立安全服務相互調用構成的工做流，以下圖所示，每個方框都表明着一個獨立的安全服務，經過互相調用，造成了一個完整工做流。

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

• Masscan，高速無狀態端口掃描
• Nmap，具有豐富服務指紋掃描

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

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

而另一種狀況，具有自研能力的甲方團隊，因爲研發成本的考慮，大多都採用了開源工具進行二次開發，因此將工具們經過編碼的方式深度集成，帶來的開發代價是無疑是巨大的，那麼有沒有稍微優雅一些的解決方案呢？下面咱們來看看編排的特色：

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

• 流程是將各個任務串成一個工做流
• 適配是把任務之間的數據打通

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

須彌Sumeru實現了可視化拖拽的編排概念，不管是在設計階段仍是結果展現階段咱們均可以經過一個樹形結構來觀察咱們的任務執行狀況，下圖爲須彌任務編排的編輯界面截圖，能夠將不一樣的應用經過拖拽的方式進行任意編排，下圖就是一個平常的綜合掃描計劃任務，將IP解析，Masscan端口掃描，Nmap服務指紋掃描，敏感目錄掃描，PoC掃描整合成了一個完成的工做流：

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

5、須彌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、應用場景舉例

須彌在設計之初就是爲了解決一些場景下的問題，因此也將這些應用場景簡單作下介紹。

6.1 端口掃描爲任務分片提高掃描性能

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

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

掃描過程當中遇到某個節點網絡不通或網絡不穩定的狀況，會轉移到同分組內其餘節點繼續執行，直到全部任務能夠正常運行,以下圖所示。

![圖]（college.creditease.cn/resources/u…

6.3 需求快速上線

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

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

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

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

7、總結

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

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

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

做者：安全開發 李方洲

來源：來源：宜信技術學院