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

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

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

平台综述

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

• 基于命令行。
• 基于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，只会尝试提取生成的数据库结果。

适用匹配

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

兼容性

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

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

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

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

便携性

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

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

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

后话

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