STATE LISTEN 或 ESTABLISHED 是否意味着我在使用 nmap 时应该看到一个开放端口?

STATE LISTEN 或 ESTABLISHED 是否意味着我在使用 nmap 时应该看到一个开放端口?

处于 LISTENING、ESTABLISHED 或未识别状态的端口是否应在 nmap 中显示为开放端口?

在谷歌上进行一些搜索我发现了这个:

任何“ESTABLISHED”套接字都意味着当前已建立连接。任何“LISTEN”都意味着套接字正在等待连接。两个端口均已打开,但其中一个正在等待建立连接,而另一个端口已建立连接。

netstat在 Windows powershell 上使用过来显示进程状态:

netstat -nboa
Proto  Local Address          Foreign Address        State           PID
[svchost.exe]
TCP    0.0.0.0:445            0.0.0.0:0              LISTENING       4
[svchost.exe]
TCP    0.0.0.0:7680           0.0.0.0:0              LISTENING       21240
[svchost.exe]
TCP    192.168.0.106:60478    155.133.255.100:27035  ESTABLISHED     21016
[msedge.exe]
UDP    0.0.0.0:60288          104.71.216.88:443                      10736
[steam.exe]
TCP    192.168.0.106:64644    52.2.219.0:443         ESTABLISHED     4456

然后使用 vmbox guest Kali Linux 测试nmap -v -p 445 192.168.0.106这些本地地址端口。我也尝试过使用-f,-T0-T1,但它们都返回状态关闭或过滤。

我还测试了我的来宾操作系统 IP 地址

ss -tnp
tcp  ESTAB 0 0 192.168.0.111:47658 34.117.65.55:443 users:(("firefox-esr",pid=1648,fd=106))

然后使用nmap -v -p 47658 192.168.0.111,导致 STATE 关闭。

难道我做错了什么?我应该将这些端口视为开放吗?

答案1

处于 LISTENING、ESTABLISHED 或未识别状态的端口是否应在 nmap 中显示为开放端口?

听,是的。已成立,没有。 “已建立”套接字表示已经存在的连接,并且无论如何都不是“开放端口”。

请注意输出实际上并没有告诉您哪一边最初在建立连接时正在侦听 – 它不一定是到您的计算机的传入连接;事实上,输出中的所有三个连接似乎都是传出的,其中偏僻的建立这些连接时,系统正在侦听端口 443 或 27035。这些套接字的本地端口根本没有监听套接字。

列表中的那个“未识别”套接字甚至不是 TCP,而是 UDP。 (UDP 没有任何连接状态。)Nmap 可以扫描 UDP 端口,但您需要明确告诉它这样做。然而,从端口号来看,它是一个出站流——远程系统正在侦听 UDP 端口 443,而本地端口只是临时分配给该单个流。

相关内容