大伙应该知道我之前做了一个扫描平台，目前是“强烈推荐但是不给你用”星选集里我最喜欢用的工具；这个工具我一直在用，改了好几轮了，之前的文章大伙没看过感兴趣可以看看
ARLite扫描平台分布式架构实现 – zgbsm's note
大伙可以发现，这个平台在我不断的抽象操作导致它“能用”之后，一直在改进扫描速度；相比原版ARL而言，在同样的资源数量下，我的平台会稍微快一些
但是这是不够的，因为上周去打了个攻防，一共15万个目标，一共10天，只扫完了9000多个；其实正常应该不止9000个，当时是我不想花钱买代理，直接在测绘节点上开了一个，然后打猛了被防守方封了，然后业主群一同步，几乎所有防守方都把我封了，这种情况下会导致端口扫描速度降低，所以10天-9000个ip不是我这个扫描平台的正常水平
打攻防谁管你什么水平？攻防场景下扫描节点被封是很正常的，不能因为被封了就速度降低。但是nmap一旦被封，它的速度就会很慢，这要怎么办呢？
其实arl源码里面是有针对nmap的调教的，但是这套参数我已经试过了，一台机器开8线程扫描的情况下，这套参数应该会导致nmap扫描的准确性大大降低，大概是网络拥塞造成的；而且nmap在设计上就是那种快不起来的，它的设计目标是准确和服务识别，就算开SYN选项去扫描，速度也是很慢
到这里我必须提出今天这个改进的主要目标：快，才能避免焦虑
大伙可以注意到我们的主要目标是避免焦虑，因为大伙打攻防的时候通常都很急，一旦扫描器卡住了就会坐立不安；这时只要扫描器有东西出来，我们的急就会缓解
既然只要随时能出东西就行，那就要找个快的端口扫描工具
但是我们经常说龙生龙，凤生凤，老鼠的儿子会打洞；没有人会承认自己是老鼠，所以不能因为最求快，而丧失了准确性（我这个平台的准确性一直都不行，但我不是老鼠，我是哥布林）
如何保证又快又准呢？经过我一番调研，发现又快又准是不存在的，但是我们可以退而求其次——先快再准
具体操作是这样的，先用快的端口扫描器扫一遍，测绘和漏扫全部做完，因为在余额充足的情况下，测绘和漏扫节点通常是分开的，那这样先漏扫不会导致测绘节点被防守方封禁，保证了资产和漏洞发现的及时性；等到第一轮扫完后，再将所有ip聚合去重复，扔给nmap扫一顿细的，nmap的结果跟之前的进行比对，然后将新发现的端口再拿去跑一遍测绘和漏扫
这个操作听起来很完美，但是有三个问题：
一、没钱怎么办？在余额不足的情况下，测绘和漏扫节点会挤在一起，这样后续再调用nmap就没有意义了，IP已经被封了。或许可以将漏扫推迟到nmap之后，但是这也太后了，到时候人家防守方都把有洞的服务关了，没有意义
二、流程有点复杂。这套流程存在一个回锅的操作，作为哥布林厨师，我坚信“回锅肉一定要回锅”，我这个平台的流程控制逻辑是从原版ARL抄过来的，如果落地这种奇妙的流程，我没有信心写出没有bug的代码，虽然不算复杂，但是改动太大，懒得动。而且手上还有一堆代码等着我审计，再不多挖点洞我就要成淘宝接单的自由开发工程师了
三、会看吗？这里资产扫出来，新鲜的大家都爱看，但是回锅扫出来的，还会有人看吗？大概都不知道有回锅这回事吧；这样就需要把回锅扫的资产单独列出来，UI上面又要大动刀子，懒得动
所以最后产生了一个成熟可靠的方案：加一个扫描引擎，下发任务的时候可以选；这样只需要把扫描工具的wrapper写好，然后小改UI即可。这个方案最终落地了
跑个edusrc测试一下，到目前为止过去了1个小时20分钟，跑完了差不多300个域名，推算到1天差不多能跑4800个域名，速度估计是原来的4.8倍
那大伙可能要问了：准确度怎么样？
在15万资产的攻防场景下，我觉得扫描一定要能扫完
扫的完吗？目前这个测出来的速度是4线程的速度，如果跟攻防一样扩容的话，速度能再翻3倍，差不多能跑完
大伙可能要问了，为什么这么快？这不正常
因为这里用到了我独家的缓存技术（没什么技术含量），直接减少了70%的扫描量
当然，像上次攻防那个场景，扫描缓存的命中率几乎为0，这个命中率还是要看目标的，一般拿某个单位做目标，缓存命中率就高；直接扫IP，缓存命中率就低
那大伙可能最后还想问：准确度怎么样？
这次用的端口扫描工具是naabu，SYN模式，之前跟原版ARL调参的nmap比较过，应该不准
不管，先扫了再说
Comments | NOTHING