分布式资产扫描平台实践

以前在乙方干活的时候,对于黑盒扫描的内容研究的比较多也早。此前做了一些内部项目,但没有走涉密。本来还想出来做做开源,不过后来看着不挣钱,加上代码水准有限,也就作罢了。

时过境迁,相关内容也不太敏感了,项目被人接手以后,应该已经做了不少迭代。

这里主要想跟大家分享下,原来在建设扫描平台中遇到的思路,文中会拿以前的项目进行脱敏式分析。

分布式资产采集平台基础架构

平台综述

通过图中的内容可以看到,我们的平台是通过两种方式调度的:

  • 基于命令行。
  • 基于flower(web api)。

我们通过在主控服务器,调度celery借助中间件redis,将任务下发到各个agent节点。

此后,各个节点会根据规则,随机抽取proxy代理池里的ip,以期达到隐匿自身的作用。

然后,节点会通过对基础模块的复杂调用,向目标发送探测请求包,实现对信息探测结果的落库。

最后,我们在反馈数据回主控服务器数据库时,会采用加密方式,以免被中间人侦听。

我们的主要模块有:

  • 信息探测:实现对目标开放的ip或者域名,进行端口、端口banner、服务类型和版本等基础信息探测。
  • cms识别:主要对探测到web类型的目标,进行cms识别。
  • 社工引擎:对多个搜索引擎进行爬取,并辅以github之类的第三方接口进行补充。
  • 端口服务扫描:调用nmap和masscan接口,并辅以fofa、shodan之类的接口进行补充。
  • 路径爆破:对爬取到域名去重探活后,如不存在waf进行暴力扫描,如存在进行智能低频探测。

那么,我们在以上的模块进行交叉调用后,又能得到什么结果呢:

基础信息:

  • 目标base结果:包含ip、端口、端口banner、服务类型和版本。
  • cms结果:包含cms类型、版本,如果没有会优先展示webserver。
  • 端口扫描结果:分析出真实开放的端口,筛选出其服务类型和版本。
  • 路径爆破结果:分析状态码和返回的网页内容,去重找出真实的接口和路径集合。
  • dns资产:ip域名的基础映射集合。
  • email资产:对于某个实体(或者根域名)的所有email资产组合。
  • 敏感词资产:对于某个实体(或者根域名)的所有敏感信息组合。

整合信息(包含基础信息):

  • 主机资产:针对单台主机的所有基础信息探测合集。
  • 子域名资产:针对特定域名的所有子域名的基础信息合集。
  • 子网检测结果:针对特定实体下单IP段的主机资产的基础信息合集。

对接服务

我们讲到了我们获取的资产合集,那么我们可以对接的服务又有哪些呢?

前面的《规模渗透架构部署设想》里,我们提到了一些规划,目前已经研发落地的有:

  • 漏洞POC验证系统:针对采集到的资产数据,针对CMS类型进行验证,如果不能识别会使用通用的脚本进行fuzz。
  • 渗透方案查询:类似于私有化的wiki平台,这个在前司曾经维护了一段时间,但后来改成了云笔记协作。
  • 漏洞分储系统:当时爬取了seebug等几个国内外知名漏洞库,并单独提取poc,后来由于各大接口经常改动,精力不足暂停维护。
  • 被动漏扫系统:这个落地项目在前规划里没有提到,依赖离线web流量会多一些,主要规则涵盖owasp top10,以及主流api漏洞检测,目前暂时没有主动接入本平台api,只会尝试提取生成的数据库结果。

适用匹配

在当初设计平台时,碰到两个比较重要的问题。

兼容性

由于本身设计的属于外网资产扫描的平台,在内网渗透时会比较尴尬,很多特性都不太匹配。

在进行内网渗透时,兼容性都会比单机版要差很多。

这点在以前跟前大boss讨论时,没少被喷被教育。当然他以价值输出为导向,后来觉得讲的还是很有道理的。

所以后面再考虑是单开分支,还是单写逻辑在这个项目进行内网模块处理。

便携性

系统本身是分布式的,单机版本也可以,但是启动运行效率不高。

当初考虑做时候,考虑过打包docker镜像,但是前大boss不太认,觉得在出去搞环境比较复杂,镜像不一定能找机会pull。

后来,考虑的是一键安装脚本,将容易出问题的库尽量用常规库替代,保证能一键启动关闭,然后任务在丢失后有重试和完整重放机制等等,即在容错兜底上加强了不少。

后话

本文大概介绍了对于平台架构、资产收集结果的方案设计要略,后面会单独分析几个对接服务的细节,以及一些新的想法。