关于Network Discovery的一些思考

栏目: IT技术 · 发布时间: 3年前

内容简介:关于以上问题本文提出了恰当的解决方案,全文充满了作者独到的见解,不可不看呀;

少侠,请留步!

在下这有一份你要搞的那个内网的主机端口明细表。

少侠你在接下来进行的全内网端口探测的过程中,可能会遇到以下棘手的情况:

①需要对巨量的ip进行全端口探测;(nmap耗时太长,等的让你怀疑人生的那种)

② 高速度与低误报二者不可兼得;(鱼与熊掌不可兼得)

③有些服务器有着严格的防火墙策略;(tcp头改啥标志位怕也是不好混进去)

关于以上问题本文提出了恰当的解决方案,全文充满了作者独到的见解,不可不看呀;

关于Network Discovery的一些思考

资产统计中你拿到巨多的ip,需要为每个ip统计详细到每个端口的信息时,你有没有经历过漫长的等待,看着nmap缓慢的百分比进度,简直想卸载了nmap。

nmap的优势不在于进行如此大范围的资产探测;

而是对于少量ip进行细致的探测。

masscan和zmap则是此类擅长者。

关于nmap、zmap、masscan对比,此处不做赘述,请看下面这位老哥的文章;

https://www.freebuf.com/sectool/119340.html

简言之,zmap与masscan皆采用异步传输;

而且,在对任意地址端口的组合的探测时,masscan表现的更加灵活和出色;

但是,masscan和zmap都有一个无法忍受的误报率。

影响masscan误报率的因素有很多,主要有这么三个方面:发包速度、网络性能、tcp/ip堆栈冲突;

不同网络环境中网络的性能不同,且网络性能涉及到的因素很多,丢包率、抖动率、时延、包转发率等等,且网络性能这项是我们无法改变的,所以我们先把网络性能作为一个常量;

但是发包速度和tcp/ip堆栈冲突是我们能改变的。

理论上:

 a、解决了堆栈冲突误报率会变低;
 b、发包速度越慢误报率越低;

但是发包速度和误报率之间并不是严格的正比关系,并且发包速度太低masscan就没有了使用意义。

所以,需要先来探究一下,怎样的网络性能下配置多少的发包速度可以兼顾速度与准确率。

我在本地网络做了一个关于masscan的小实验:

1、先测试一下本地网络最大能支持的包转发率,如下图所示

关于Network Discovery的一些思考

结果:表示包转发率的rate值一直在170-kpps~210kpps之间波动

2、测试一下rate为210kpps的情况下扫描内网中24个ip的全端口,探测到的存活端口数量是多少。如下图所示

关于Network Discovery的一些思考 关于Network Discovery的一些思考 结果:探测的开放端口数量为38个

3、测试一下rate为170kpps的情况下扫描内网中24个ip的全端口,探测到的存活端口数量是多少。如下图所示

关于Network Discovery的一些思考 关于Network Discovery的一些思考 结果:探测到开放端口数量为48个

4、测试一下rate为110kpps的情况下扫描内网中24个ip的全端口,探测到的存活端口数量是多少。如下图所示

关于Network Discovery的一些思考 关于Network Discovery的一些思考 结果:探测到开放端口数量为52个

5、测试一下rate为100kpps的情况下扫描内网中24个ip的全端口,探测到的存活端口数量是多少。如下图所示

关于Network Discovery的一些思考 关于Network Discovery的一些思考

结果:探测到开放端口数量为52个

6、测试一下rate为80kpps的情况下扫描内网中24个ip的全端口,探测到的存活端口数量是多少。如下图所示

关于Network Discovery的一些思考

关于Network Discovery的一些思考 结果:探测到开放端口数量为53

7、测试一下rate为50kpps的情况下扫描内网中24个ip的全端口,探测到的存活端口数量是多少。如下图所示

关于Network Discovery的一些思考 关于Network Discovery的一些思考 结果:探测到开放端口数量为53个

8、测试一下rate为10kpps的情况下扫描内网中24个ip的全端口,探测到的存活端口数量是多少。如下图所示

关于Network Discovery的一些思考 关于Network Discovery的一些思考

结果:探测到开放端口数量为53个

9、测试一下rate为1kpps的情况下扫描内网中24个ip的全端口,探测到的存活端口数量是多少。如下图所示

关于Network Discovery的一些思考 关于Network Discovery的一些思考 结果:探测到开放端口数量为53个

测试速度低于1kpps,就太慢了,就算结果更准确却没有意义了,所以低于1kpps的就不做测试了。

统计一下以上测试的结果:

转发率(kpps) 210 170 110 100 80 50 10 1
探测到的开放端口个数 38 48 52 53 53 53 53 53

我们可以发现在我当前的网络环境中,转发率为100kpps时是最合适的速度大小,可能在不同网络中会有一些差异。

以上是测试结果,我们每一次使用masscan总不可能都这么测吧,确实如此。

我分享一下我的经验:最合适的速度一般是在网络最大转发率的50%左右。

看完了速度与误报率的关系后,我们来看一下masscan的tcp/ip堆栈冲突。

其实呀,masscan是拥有独立的TCP/IP堆栈的;

在平时使用中,我发现当为masscan配置单独的ip时;

它的性能才能被充分发挥!!!误报率显著降低。

我们来看一下,当配置独立ip,转发率为100kpps时,其他情况完全不变,masscan的扫描结果如何?如下图所示

关于Network Discovery的一些思考

关于Network Discovery的一些思考

结果:探测到开放的的端口数量为157个

这与刚才的100kpps时发现的53个相比,几乎三倍!!!

在这种情况下我估算了一下它的速度:10分钟扫描1000个ip的全端口。

这是nmap速度的一千多倍,而且在准确度上几乎没有差别。

在获得ip的全端口探测结果之后,你并不能确定端口对应的服务是什么?

这时候就可以使用nmap了,nmap有着丰富的指纹库,可以为我们确定端口对应的服务版本。

先调用masscan库扫描,再调用nmap库扫描,如果ip端口数量过多,可以配合多线程;后面会完善一下代码再放在github上,这里先放出简略版。

以上代码实现如下: 关于Network Discovery的一些思考

还有开篇提到的最后一个问题,有些服务器有着严格的防火墙策略怎么办?

有防火墙,需要对其进行各种骚姿势的绕过时,masscan就显得很无力了。

这时还是nmap更为适合,配合 python 的多线程,速度也过的去。

过防火墙姿势有很多,感兴趣的可以去看《nmap渗透测试》这本书,这里只讲我平时常用的两种。

1、数据包分片

有些防火墙为了减少数据包压力,不会对数据包进行组合之后再检查,而是对单个数据包直接检查。

如下图所示

关于Network Discovery的一些思考

2、指定源端口

防火墙的存在往往会影响一些业务的工作,管理员很有可能会放行来自特定端口的数据包,比如说源端口53的dns服务。

如下图所示

关于Network Discovery的一些思考


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

The Pragmatic Programmer

The Pragmatic Programmer

Andrew Hunt、David Thomas / Addison-Wesley Professional / 1999-10-30 / USD 49.99

本书直击编程陈地,穿过了软件开发中日益增长的规范和技术藩篱,对核心过程进行了审视――即根据需求,创建用户乐于接受的、可工作和易维护的代码。本书包含的内容从个人责任到职业发展,直至保持代码灵活和易于改编重用的架构技术。从本书中将学到防止软件变质、消除复制知识的陷阱、编写灵活、动态和易适应的代码、避免出现相同的设计、用契约、断言和异常对代码进行防护等内容。一起来看看 《The Pragmatic Programmer》 这本书的介绍吧!

RGB转16进制工具
RGB转16进制工具

RGB HEX 互转工具

RGB HSV 转换
RGB HSV 转换

RGB HSV 互转工具

HEX HSV 转换工具
HEX HSV 转换工具

HEX HSV 互换工具