以前在乙方干活的时候，对于黑盒扫描的内容研究的比较多也早。此前做了一些内部项目，但没有走涉密。本来还想出来做做开源，不过后来看着不挣钱，加上代码水准有限，也就作罢了。
时过境迁，相关内容也不太敏感了，项目被人接手以后，应该已经做了不少迭代。
这里主要想跟大家分享下，原来在建设扫描平台中遇到的思路，文中会拿以前的项目进行脱敏式分析。
平台综述通过图中的内容可以看到，我们的平台是通过两种方式调度的：
基于命令行。基于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。
后来，考虑的是一键安装脚本，将容易出问题的库尽量用常规库替代，保证能一键启动关闭，然后任务在丢失后有重试和完整重放机制等等，即在容错兜底上加强了不少。
后话