前言
原本打算发篇文章介绍下我的扫描器的，一直鸽到了年底，后来想写个总结，结果又鸽到了年后，所以就有了这篇关于扫描器方面的迟到的年终小结。
虽然一直鸽到现在，但在这段时间也收获了两个值得高兴的事情。
扫描器收获了2023年的第一个严重漏洞；
平台在春节假期无维护稳定运行整个假期。
去年除了日常的工作外，基本就在搞我这个扫描器了，所以这个小结也就围绕这个扫描器来展开啦，同时给自己提个醒，下篇文章不能再鸽下去了。
这个扫描器从很早就开始做了，但经常大改，整体框架都被我推翻了好几次，但今年年初开始基本稳定下来了，虽然还在不停的修修改改，但核心已基本不变。各节点除了更新外基本能保持稳定运行，同时扫描节点也陆续产出漏洞，且我自己写的代理扫描工具也产出了多个高危漏洞，逐步摆脱对xray的重度依赖，基本算得上一个成熟的扫描器了。
目前的扫描器页面之前也发过一次首页的样子，这次也再简单贴几张图，详细内容等下次的文章中再介绍。
虽然有很多内容，但其真正的核心依然是信息收集和漏洞扫描两块内容，其他功能基本是为这两个功能来服务的。
本篇也主要是通过这两个方面来对一年内做的内容来做个总结。
总结
整体方面
前端界面更换了新的前端模板，新的模板无论是视觉还是功能上都比原来舒服了许多。 后端虽然核心没改，但是原接口用的flask-restful，后来遇到个大坑一直没解决掉（想不起来是什么了...），改回最普通的方式，基本代码还是复制粘贴了一遍... 代理扫描工具从最开始的一个壳逐步迭代为了一个较为成熟的扫描器。 对各节点进行了统一梳理，并增加了监控及守护进程。 由于原服务器到期，主服务端整体进行了一次迁移了。 对dnslog及反链平台进行了一次修改，兼容更多协议。 在资产识别精度方面做了大量的修改，但还有很多的提高空间。 增加了目录扫描节点。
信息收集方面
这块主要做的修改在子域名收集，网站信息收集和服务识别三个方面。
「子域名收集」
依然使用的是oneforall，虽然之前已经修改过一次，但对其应对泛解析效果并不满意，对oneforall进行了进一步改造，而且甚至在服务端增加了一些规则。到现在虽说有提高，但还不是完美的，有些想法在oneforall现有框架上改动量太多，不亚于重写了，但是目前又没有那么多精力来搞这个，短时间内只能这样用了。
初版介绍见:Oneforall工具分析与改造
「网站信息收集」
增加信息收集的维度，提高识别有效资产的能力，为服务端识别有效资产、无效资产和重复资产等方面提供更多的数据支持，提高平台的整体识别精度。
「服务识别」
原本为nmap，但由于其存在一些坑，后来自学了go，自己写了一个专门用于服务识别的工具xnmap，现在已完全替换为xnmap来识别。
初版介绍见:xnmap:一个比nmap更专注于服务识别的工具
漏洞扫描方面
「nuclei」
之前是无差别扫描，但是服务器跑了太多东西，没多少性能分给它用，经常是用用停停。现在由原来的无差别扫描调整为根据指纹及配置规则下发扫描任务。
「pocsuite」
增加用于服务类型资产的扫描，这个节点也上报了一些漏洞，但报告大多是测试环境或无太大价值的目标。
「crawlergo-proxyscan-xray」
之前是这样链式配置的,后来做了拆分。
crawlergo后来的测试中感觉效果还是有点差了，后来研究了一下代码，修改了其中一些内容，但是核心设计主要是chrome协议监听及处理，一直没分出来精力去研究，最后还是没敢动。
proxyscan这块在今年也是一块大的内容，最开始只是个能完成基础被动扫描的小工具，想让其作为xray的一个辅助工具，强化xray没有的一些能力。但随着不断的优化，已经是一个相对完善的工具了，且在某些方面也在渐渐取代xray，所以年末也彻底将其从这套链式扫描中独立了出来。
xray仍是持续监听模式，但随着xray官方的不断更新，其本身也不再是一个纯被动扫描的工具了，后续也会将其改为普通模式，让其配合我的扫描工具进行一些辅助扫描，真正实现各节点的完全独立。
成果
信息收集方面
「整体资产」
子域名:397w 网站:78w 主机:15w 端口:24w
为了便于节点的维护及调试，平台未增加对过期资产清除的功能，以上包含了部分过期资产。
「更新资产」
子域名和网站信息基本稳定维持在7天左右更新
更新10w左右的往期网站 新增1000左右的新网站 扫描400左右的子域名 下发1000左右的扫描任务
以下为部分扫描平台每天上报的统计结果截图。
「风险报告」
目前总计报告风险90214条。
其中手动处理漏洞26259条，自动忽略报告63955条(这里主要是误报、重复、低危及部分不在范围内的漏洞)。 从上报节点类型来看，xray发现漏洞69891条，proxyscan发现漏洞19528条，其他发现漏洞795条。
其中xray相关漏洞分析之前有发过一篇文章:对xray的5.6w+结果的简单分析。
起初的风险报告结果并没有做详细的分类，在平台增加分类后的报告统计如下：
提交报告46条 有利用价值但不在收取范围内的漏洞303条 低危漏洞783条（ps:这里主要是手动标记的，不包括被规则自动忽略的低危漏洞）
吐槽
不止一次因为扫描器报了一堆误报和垃圾漏洞，然后懒得看了，过几天回过头来看，结果里面还夹了一个高危漏洞，再验证的时候已经修了...
各家src注册规则五花八门的，由于监控的src太多，扫描周期过长，扫描器再次扫到这家的时候发现忘记我的账号是啥了.....
虽说自动化挖漏成本很低，睡一觉起来可能就好几个，但是写报告是真的烦，可以说每家的要求都不一样，有的平台还贼难用，很多低危漏洞还得按着要求来填报告，最后给的奖励还不够写报告的，搞得现在基本不看低危漏洞，交也亏不交也亏。
src审核及赏金方面差距过大，同一个类型的漏洞，不同的src结果及奖励可能差出来很多倍，还有的src都几年更新过感觉都没人维护了。
很多小的src收取的范围更严格，就算是重要服务器的严重漏洞，不在范围内就是不收。
计划
进一步提高资产准确度，减少打偏了或者重复扫描的情况。 删除一部分src，主要是多年没运营的，收取漏洞限制太多的，奖励标准太低的，节省服务器资源。 丰富扫描插件功能，不但要能识别出来漏洞，还要能输出更详细的验证结果，降低后续的人工验证，做到看报告就能评估出来漏洞最大危害。 对外开放平台的部分功能。
除上述外，还有一些想实现的，不过很多还只是一个想法，不清楚最终能达到什么样的效果，再加上精力有限，也只能慢慢来了。
对外开放接口其实也开始做了，但放开的接口除了核心功能外还要考虑多用户逻辑及服务器性能，工作量有点大，所以目前打算的是一点一点的功能逐步放开，近期可能放出来第一版，感兴趣的师傅们点点关注吧。
师傅师傅，点个关注吧🙏
往期文章
如有侵权请联系:admin#unsafe.sh