云化分布式自动化渗透测试平台 - 架构笔记

0x01. 简介

在 2020 年 12 月，我写了公众号的第一篇文章 — “自动化安全工具平台 - 架构笔记”，文章介绍了前几年我在写个人自动化安全工具平台的过程中，关于架构方面的一些尝试和总结。也因这篇文章，在 2021 年 5 月，我有幸加入了长亭，负责红队自动化渗透测试平台项目。这篇笔记是近半年多来，我和团队师父们在平台架构方面的一些思考、尝试和总结，主要内容包括：

如何理解云化分布式自动化渗透测试平台？
平台架构介绍
未来的一些想法和计划
岗位招聘
内容总结

0x02. 平台介绍

关于平台，这里结合文章标题中包含的关键词来进行介绍。

关键词一：渗透测试平台

渗透测试平台相比于之前个人开发使用的安全工具平台，它主要的不同点在于：

渗透测试平台定位于为实际的安服项目、攻防演练提供支撑，需覆盖的场景更多，而后者主要满足个人平时的安全测试和挖洞
用户量更多，且为一线安全人员，平台功能更加丰富和贴近实战。随之复杂度也会增加，对平台的架构设计要求更高
有专人对接用户需求、协调试用和收集反馈，有更加充足的研发资源，实现更快的优化迭代速度，而后者需要个人拥有“全栈”技能

关键词二：分布式

为了具备良好的扩展性，平台采用了分布式架构，利用消息队列解耦任务的发送和执行，通过增加消费者的数量，实现更高的扫描速度和并发支持。

关键词三：自动化

主要指渗透过程自动化，即如何减少渗透过程中的重复劳动，提高效率，让安全人员更专注于挖洞本身。广义上说，也包含研发、运维自动化，后续会在平台架构部分进行介绍。

关键词四：云化

即平台所有服务全部运行在云上。在上一篇架构笔记中，为了追求高可用，我曾自己搭建过 RabbitMQ 和 Postgresql 集群，机器成本相对于直接使用云厂商服务确实更低，但如服务升级、扩容、稳定性都需要自己来操作和保障，后期的运维成本更高。而全面上云后，大部分运维工作只需在页面上进行操作即可。通过借助云厂商更专业的服务，能够在提供高可用保障的同时，大幅减少运维成本。

0x03. 平台架构

目前平台架构如下图：

平台同样采用前后端分离，开发语言和框架为：

前端：Vue + Element UI，语言方面为了代码更易维护，采用强类型的 TypeScript。
后端：包含业务层和安全引擎两部分。业务侧追求开发速度，使用 Python 3.8 + Django REST framework。引擎侧关注效率使用 Golang，之间通过 gRPC 进行调用

平台使用到的服务和组件信息如下：

序号

服务

说明

Gitlab

代码托管，CI/CD 自动化构建

Image Registry

Docker 镜像仓库

Postgresql

关系型数据库，存储平台数据

Redis

缓存服务

ELK Stack

存储/查询 Http 请求响应数据、业务日志

Object Storage

存储用户上传、导出数据、页面截图等

Sentry

代码错误监控和追踪

Frontend

Nginx 反向代理、静态资源访问

Backend

后端 API Server，使用 DRF 框架

Prometheus

指标统计监控、告警

RabbitMQ

分布式消息代理

Dramatiq

Python 异步任务框架

Kubernates

容器化部署管理

从列表信息看，核心组件与个人版基本相同，此外还增加了多个新服务来完善平台的各项能力，如自动化构建、错误追踪、监控告警等。

从架构图右侧，可以明显看到前一章节提到的 “云化” 特点。对于基础服务，如 Postgresql、Redis、ELK、对象存储等，都直接使用了云厂商提供的高可用集群版本，来保障平台的稳定性。

另一个改进点是，平台使用了 kubernates 来进行服务的容器化部署和管理，相比于个人版基于 docker、docker-compose 的方案，k8s 的功能更加强大。简单理解，你只需要通过 YAML 定义来声明需要的资源，如服务实例数量、机器资源、环境变量、启动命令等配置，k8s 会负责服务的启动、健康检查、故障迁移等剩余的工作。在 k8s 中，Pod 是最基础的运行单元，此外还提供了多种内置的应用类型（workload）来满足常用的业务场景，以下为平台中的一些应用例子：

业务服务（python）依赖引擎服务（golang），二者需要同时运行。类似 docker-compose，在 k8s 的 Pod 内可以运行两个 container，容器实例之间通过 localhost 进行相互访问
对于如前端和后端 API server 服务，服务的实例之间没有本质区别，使用 Deployments 来部署
对于如 RabbitMQ Cluster 服务，节点区分 master 和 slave，使用 StatefulSets 来运行

在平台开发的过程中，也遇到过某些复杂功能，如实现为某个任务分配独享计算资源，需要能够自行控制节点（Pod）的创建过程，但内置的应用类型（workload）无法满足需求。此时，可通过 k8s 强大的扩展能力 Custom Resources 和 Operator pattern，来定义自己的资源类型，编写 controller 来进行管理。此外，k8s 还有如使用 Persistent Volumes 实现多个服务挂载和访问同一个存储磁盘、通过 kubectl scale 命令实现资源快速伸缩等功能，能极大的提升平台部署效率和扩展能力。

下一个不同点是，个人版在后端开发时主要使用 Python 语言，利用协程 gevent、asyncio 来缓解 GIL 带来的并发性能问题。而在新平台，我们对后端功能进行了拆分，使用 Golang 来进行安全引擎的开发，而业务层仍使用 Python，这样做的考虑主要有：

Python 为解释型语言，动态类型开发速度快、灵活，但易出错。Golang 为编译型语言，静态类型让代码更易维护
Golang 拥有 goroutine 和 context，对并发的支持和控制更好，运行速度和效率要比 Python 更高
公司已有安全能力开发语言为 Golang，能进行复用和相互输出

对于异步任务框架 Dramatiq，之前在个人版中遇到了一些问题：

一个节点会运行多个 Dramatiq worker processes，即有多个任务同时在执行和打印日志，想要从日志文件中查看某个特定任务的日志会非常困难。此时可以通过 CurrentMessage middleware 获取到当前任务的 message_id，然后结合自定义的 logging Formatter ，在打印的日志添加 message_id 前缀，这样能方便的通过 grep 等命令找到特定任务的所有日志
Dramatiq worker 在 gevent 启动模式下，无法通过 raise exception 来中止执行，因此依赖此的 middleware 如 TimeLimit, Abort 等都无法使用。不过这个问题在 21 年 9 月，有一位大佬提了 PR 解决了这个问题，感兴趣的可以看看 https://github.com/Flared/dramatiq-abort/issues/11

聊完开发语言和 Dramatiq，接下来再介绍一下其他研发流程相关的改进。在个人版的容器镜像主要依靠手工构建，在新平台则基于 Gitlab CI/CD，能够在每次代码变更和合并时自动进行构建打包，并推送至容器镜像仓库。为了方便功能测试和验证，平台拥有两套配置相同的环境 stg 和 prod，功能需在测试环境上验证通过后才会部署到线上环境。

此外，在功能上线后，不可避免的会遇到 bug，那么如何知道服务出现了问题？这里需要考虑两种场景：

代码直接出现报错，如未正确处理异常等。此时可以通过图中的错误监控和追踪服务 Sentry，将错误调用栈等相关信息上报至平台，并发送通知给研发人员进行处理
服务质量，如某功能依赖第三方接口，网络错误、服务不稳定都会导致运行失败。如果每次都打印错误日志，会导致 Sentry 告警太多，无法查看。对于这类问题，有一个共性，即少量的失败是可接受的，只有超过特定比例才会被认为是问题。因此我们需要收集一些指标数据，来监控服务的状态。这部分由图中打点和统计服务 — Prometheus 来完成

关于平台架构部分，在探索过程中还遇到过其他很多问题，因篇幅关系，此次就先介绍到这里。

0x04. 想法和计划

要想设计出一个好的平台架构，需要不断的尝试和改进，以及大量的时间去打磨优化细节。经过半年多的努力，虽然平台当前架构已经基本成型，但仍然还有很多的不足和优化之处，例如：

数据库需增加只读实例，以缓解主库压力
所有服务共用一个数据库集群，部分非核心服务请求量较大，需要剥离成独立库
部分服务的监控缺失或阈值的不合理，需要进一步梳理和调整
部分业务日志没有持久化存储，缺少统一查询入口，复杂问题排查较困难
随着任务量和存储数据逐步增加，如何更合理的规划未来服务所需资源
...

对于一个自动化渗透测试平台，良好的架构设计是基础，安全能力则是核心竞争力。在过去的半年多，平台的功能基本保持在每周更新上线，目前已经完成近两个大版本的开发，并投入使用。对于安全能力，在 2022 年，也将持续投入更多的精力进一步优化和提升效果。

不论是提升安全能力还是架构优化，都需要更多的人力投入。因此，下一章节是团队岗位招聘环节，感兴趣的师父可以看看

0x05. 岗位招聘

团队介绍

我们是长亭安全服务中心的协同创新团队，团队职责为将一线安全攻防经验，以平台和工具等形式赋能公司各业务，并通过安服业务的实践，快速获取反馈，不断改进和提升安全能力，构筑公司核心竞争力。

团队成员包含专业的产品经理、前后端研发、安全开发、攻防专家、运维。技术氛围好，不卷，老板重视。

目前团队负责项目包括但不限于：

自动化渗透测试平台：为一线安服师父打造的持续完善的自动化挖洞”神器“，为安服项目、攻防演练提供支撑
攻防知识库平台：集前沿漏洞信息收集、分析、检测、防御的一体化知识库平台，赋能公司全产品线
安全实训平台：全方位、一体化的网络安全人才培训平台，在实战中提升企业安全人员的安全素质和技术能力
...

关于岗位

目前招聘的岗位包括：安全研发、后端研发、红队攻防

如果你偏好安全，并具备一定的研发能力，可选择 安全研发 岗位，工作地点：北京

加入我们，你可以：

参与扫描引擎的开发和优化，包括但不限于服务探测、爬虫、漏洞检测
跟进行业新爆发安全漏洞，分析原理，并编写检测 POC
学到一线安服和攻击队师父们的渗透思路和经验，并转换为自动化工具
...

同时，我们希望你：

具有扎实的网络基础，掌握任意一门开发语言，具备一定的编程经验
熟悉常见安全漏洞原理和检测，了解攻防场景
参与过如扫描、爬虫、检测等相关安全产品的研发
具有良好的沟通和团队协作能力，热爱技术、责任心强

如果你偏好研发，可选择 后端研发 岗位，工作地点：北京

加入我们，你可以：

参与分布式、高并发扫描平台的架构设计和优化，学习全栈技术
负责模块功能的设计、开发和测试，为公司数百位安全人员提供工具和平台支撑
解决全面上云和容器化后所带来的技术挑战，保障平台服务高效稳定运行
...

同时，我们希望你：

具有扎实的编程基础和网络基础
熟练掌握 python、golang 等任意一门开发语言，追求良好的代码风格
具备较强的逻辑思维分析能力和解决问题能力，对解决具有挑战性问题充满激情
具有良好的沟通和团队协作能力、热爱技术、责任心强

如果你偏好攻防实战，可以选择 红队攻防 岗位，工作地点：北京/上海/深圳/广州/成都

加入我们，你可以：

与全国顶尖攻击队师傅一起参与护网/攻防等高端攻击项目，相互学习进步
探索研究前沿的攻防技术，并在实战中进行实践验证
参与攻击队自动化平台的能力建设，探索和打造顶尖攻击团队
...

同时，我们希望你：

具有丰富的实战经验，有大型目标渗透/攻防经验更佳
在外网打点/内网横向/域渗透/远控免杀/社工钓鱼/隐蔽持久化/代码审计等一个或多个领域有深入的理解，掌握相关的攻防技术
对安全有浓厚的兴趣和较强的独立钻研能力，有良好的团队精神

简历投递

邮箱投递：发送至 binlin.yan@chaitin.com
微信投递：添加微信 xiaobing1024 私聊发送

有岗位问题咨询、技术交流，也可以通过以上方式联系

0x06. 总结

在这篇笔记完成时，2021 年已经过去了，在看完远在异国我佳和朋友圈各位师父的年终总结后，觉得自己也该做一个“总结”，因此就有了这篇笔记。文中介绍了我和团队在过去半年多在架构方面的尝试和总结。同第一篇笔记，文字较多，再次感谢大家耐心看完。希望能够为大家提供一些帮助，也希望能够借此机会帮助团队招到更多优秀的小伙伴。

最后，因个人能力和水平有限，文中可能会有描述错误或理解不到位的地方，欢迎各位指出和交流。

最最后，如果各位觉得文章对你有帮助，欢迎关注、点赞收藏和转发。

0x07. 参考

自动化安全工具平台 - 架构笔记 https://mp.weixin.qq.com/s/OMhS9yFlcpI9KOQduSxq9g
TypeScript https://www.typescriptlang.org/
gRPC https://grpc.io/
Workloads | Kubernetes https://kubernetes.io/docs/concepts/workloads/
Operator pattern | Kubernetes https://kubernetes.io/docs/concepts/extend-kubernetes/operator/
The Go Programming Language https://go.dev/
Dramatiq Cookbook https://dramatiq.io/cookbook.html
Gitlab CI/CD https://docs.gitlab.com/ee/ci/
Sentry https://sentry.io/
Prometheus https://prometheus.io/

长亭百川云 - 文章详情

长亭百川云

云化分布式自动化渗透测试平台 - 架构笔记