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

渗透技巧 2年前 (2022) admin
972 0 0
0x01. 简介

在 2020 年 12 月,我写了公众号的第一篇文章 — “自动化安全工具平台 – 架构笔记”,文章介绍了前几年我在写个人自动化安全工具平台的过程中,关于架构方面的一些尝试和总结。也因这篇文章,在 2021 年 5 月,我有幸加入了长亭,负责红队自动化渗透测试平台项目。这篇笔记是近半年多来,我和团队师父们在平台架构方面的一些思考、尝试和总结,主要内容包括:
  • 如何理解云化分布式自动化渗透测试平台?
  • 平台架构介绍
  • 未来的一些想法和计划
  • 岗位招聘
  • 内容总结

0x02. 平台介绍


关于平台,这里结合文章标题中包含的关键词来进行介绍。
关键词一:渗透测试平台
渗透测试平台相比于之前个人开发使用的安全工具平台,它主要的不同点在于:
  • 渗透测试平台定位于为实际的安服项目、攻防演练提供支撑,需覆盖的场景更多,而后者主要满足个人平时的安全测试和挖洞
  • 用户量更多,且为一线安全人员,平台功能更加丰富和贴近实战。随之复杂度也会增加,对平台的架构设计要求更高
  • 有专人对接用户需求、协调试用和收集反馈,有更加充足的研发资源,实现更快的优化迭代速度,而后者需要个人拥有“全栈”技能

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

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

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

0x03. 平台架构


目前平台架构如下图:

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


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

平台使用到的服务和组件信息如下:
序号   
服务                    
说明
1
Gitlab
代码托管,CI/CD 自动化构建
2
Image Registry
Docker 镜像仓库
3
Postgresql
关系型数据库,存储平台数据 
4
Redis
缓存服务
5
ELK Stack
存储/查询 Http 请求响应数据、业务日志
6
Object Storage
存储用户上传、导出数据页面截图等
7
Sentry
代码错误监控和追踪
8
Frontend
Nginx 反向代理、静态资源访问
9
Backend
后端 API Server,使用 DRF 框架
10
Prometheus
指标统计监控、告警
11
RabbitMQ
分布式消息代理
12
Dramatiq
Python 异步任务框架
13
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 等任意一门开发语言,追求良好的代码风格
  • 具备较强的逻辑思维分析能力和解决问题能力,对解决具有挑战性问题充满激情
  • 具有良好的沟通和团队协作能力、热爱技术、责任心强


如果你偏好攻防实战,可以选择 红队攻防 岗位,工作地点:北京/上海/深圳/广州/成都
加入我们,你可以:
  • 与全国顶尖攻击队师傅一起参与护网/攻防等高端攻击项目,相互学习进步
  • 探索研究前沿的攻防技术,并在实战中进行实践验证
  • 参与攻击队自动化平台的能力建设,探索和打造顶尖攻击团队
同时,我们希望你:
  • 具有丰富的实战经验,有大型目标渗透/攻防经验更佳
  • 在外网打点/内网横向/域渗透/远控免杀/社工钓鱼/隐蔽持久化/代码审计等一个或多个领域有深入的理解,掌握相关的攻防技术
  • 对安全有浓厚的兴趣和较强的独立钻研能力,有良好的团队精神


简历投递
  • 邮箱投递:发送至 [email protected]
  • 微信投递:添加微信 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/





































原文始发于微信公众号(b1ngz的笔记本):云化分布式自动化渗透测试平台 – 架构笔记

版权声明:admin 发表于 2022年1月5日 上午10:14。
转载请注明:云化分布式自动化渗透测试平台 – 架构笔记 | CTF导航

相关文章

暂无评论

您必须登录才能参与评论!
立即登录
暂无评论...