当我自己扫描时,我会经常看到随机打开的端口:
nmap -sT -T normal -p 1-65535 localhost
例如.
43194/tcp open unknown
58167/tcp open unknown
有时没什么,有时像这样的一对.
然而,我看到之前这是一个误报,但它现在已经很老了:
还有一些其他用户最近也报告了这一点:
但似乎并没有那么多人注意到它.我也觉得奇怪的是,这仍然是内核的“bug”/问题.这个问题真的长期存在吗?
任何人都可以确认这是正常的行为(测试必须执行几次才能确定,如果这确实是内核/ nmap问题,可能会因系统而异)?我现在在几台物理机器上测试了这个,结果是一样的.包括一台最近安装了操作系统并且从未运行过面向服务的网络的机器,因此妥协似乎不太可能.
我的ip_local_port_range是32768 61000
测试的内核:3.16.3-smp,3.17.8-gentoo-r1
Nmap版本:6.4,6.47
如果我扫描我的IP,但是来自同一台物理机,也会发生这种情况.如果我从另一台机器扫描机器,即使-T疯了,我也从未看到这些端口打开.
解决方法:
是的,这是Linux的一个已知问题:在关闭的ephemeral port上与localhost的连接与使用4-way or “split” handshake连接自身的机会很小(通常约为28,000).Nmap受此影响最大,因为它连接到所以许多不同的端口同时在localhost -sT(TCP Connect)扫描中至少发生一次几乎确定的几率.
Nmap有这个bug的悠久历史.在1999年,Fyodor reported it to the LKML,但它被认为是RFC中的边缘情况,而不是Linux内核中的错误. 2000年采取了一种解决方法,但it was removed in February 2013是清理工作的一部分,因为它有竞争条件.下一个版本是Nmap 6.40,你说它显示了无效的结果.
去年夏天,我在introduced a change检查并重新测试这些虚假结果. Nmap的下一个版本不会出现同样的问题.
编辑:错误影响版本6.40 – 6.47.它被修复于6.49BETA1(2015-06-03).
标签:nmap,linux,port,kernel
来源: https://codeday.me/bug/20191007/1867037.html