须弥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 失效转移自适应网络环境

扫描过程当中遇到某个节点网络不通或网络不稳定的状况，会转移到同分组内其余节点继续执行，直到全部任务能够正常运行,以下图所示。

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

6.3 需求快速上线

须弥提供了一套完整的应用快速开发和上线流程。

现有大多数甲方的安全平台实际需求都是综合性比较强的平台，因此经常被作成一个大而全的工具集合，大多包括扫描工具（Web扫描，被动扫描，主机扫描，端口扫描，Git泄漏扫描），威胁情报，知识库等等。 大而全的同时，也带来的维护成本的增长，好比忽然新来一个需求：监控暗网交易情报，乍一看属于威胁情报，但又与原来的威胁情报格式，使用和部署方式都彻底不同。 开发小哥可能只能无奈地在威胁情报的子菜单里新增一个功能，埋头去开发了。 这样的需求不在少数，最后整个平台愈来愈臃肿难以维护。

若是使用应用开发方式，咱们能够将功能抽象成一个应用，只需进行应用编写，上线分发，远程调用便可，把服务和平台两者分离出来，同时也更加方便团队协同的维护。

须弥提供的Restful API使得应用做为服务集成在CI/CD(持续集成/持续部署)的过程当中更加容易，使用Python来实现，对Python生态支持也比较友好。若是有同窗遇到比较合适的场景的话，欢迎与咱们一块儿多多交流。

7、总结

能避免重复造轮子，能将一部分精力集中在业务专业能力的提高上是咱们的初衷，须弥将分布式安全服务编排的思想基本上都实现了，性能和稳定性上的还有不小的提高空间，期待它能发挥更多的价值。

一个想法的落地须要一系列的技术和资源的去支撑，在甲方公司的安所有门沉下心来打磨安全产品实为不易，感谢那些甚至作出媲美乙方产品的大神们，为咱们提供学习的榜样。

宜信安全应急响应中心（CESRC）网址：https://security.creditease.cn

该平台旨在集合安全领域的专家、社会团体及我的共同发现潜在的漏洞信息，为宜信全线产品和业务安全保驾护航，促进白帽子、安全团队和安全爱好者们与宜信的直接交流与合做，减小、下降可能存在的各种安全隐患。

做者：安全开发 李方洲

来源：来源：宜信技术学院