Nmap进行主机探测出现网段IP全部存活情况分析

最新推荐文章于 2024-04-29 11:17:05 发布

红帽小生

最新推荐文章于 2024-04-29 11:17:05 发布

阅读量1.2w

点赞数 19

分类专栏：计算机网络网络安全文章标签：计算机网络运维

本文链接：https://blog.csdn.net/abraham76/article/details/125217628

版权

网络安全同时被 2 个专栏收录

21 篇文章 11 订阅

订阅专栏

计算机网络

8 篇文章 0 订阅

订阅专栏

nmap主机嗅探

这个是我在用Vmware虚拟机内安装的kali Linux内置nmap工具进行主机探测时发现的一个问题。使用常规的nmap命令

nmap -sP 192.168.1.0/24

对该网段的主机进行探测，但发现该网段的全部主机都是活跃的。

Nmap done : 256 IP address (256 hosts up) scanned in 28.35 seconds

环境是：Vmware虚拟机安装的kali Linux，网络连接模式是NAT模式。nmap扫描网段，探测结果256个IP全部在线，实际情况是仅有3个是存活的，使用ping命令，其余的IP是ping不通的。

也就是说，使用nmap扫描结果是256个IP都存在，但用ping命令测试发现仅有3个IP是存在的，其余都ping不通。

推测

Nmap作为扫描神器，历经多次更新，不应该会出现这种误报情况。根据Nmap的官方文档，Nmap使用-sn参数指定只做主机存活发现（以前的一些版本中使用-sP，新版本中-sn和-sP都可以使用，为同一参数），不做端口扫描。Nmap认为主机存活，只需要满足以下四种方式其中一个就判断为主机存活：

ICMP echo request

TCP SYN to port 443

TCP ACK to port 80

ICMP timestamp request

Linux下默认Ping命令使用的ICMP echo请求，现在Ping不通，那第一种请求是没有主机存活特征的，问题可能在后面的三种请求。

使用nmap的kali主机IP为：192.168.17.10，选择目标网段中一个不存在的IP 192.168.1.10。通过抓包分析，ICMP echo请求和ICMP timestamp请求都没有响应，但奇怪的是，到80端口的ACK请求，有一个RST标志的响应，窗口大小是32767。正常情况下，数据包发送到一个不存在的IP，不会收到任何响应。

TCP连接端口未监听、请求超时、异常关闭等几种情况会发送RST标志的响应。IP存在，但端口关闭，收到ACK标志的包时，会返回一个RST标志的包，内容为Seq=1，Win=0，Len=0。

这里返回了一个RST标志的包，而且窗口大小不为0，Nmap认为该端口开放（参考Nmap的TCP Windows Scan），也就是这个包导致了Nmap对主机存活的误判断。这个包是哪来的呢？网络结构很简单，除了VMware的NAT外，没有其它网络设备，说明这个包是NAT返回的。

小结

通过分析发现，Nmap误报的原因是NAT模式的锅，在使用NAT模式的情况下，我们可以指定nmap只使用ICMP echo请求探测（-PE）主机，即添加-PE参数，这样nmap就只发送一个ICMP echo请求，就不会引起误判了：

nmap -sn -PE -n 192.168.1.0/24

使用-n参数是禁用域名解析，避免浪费时间在域名解析上。

选择其中一个存活的IP：192.168.1.5来测试，Nmap发送一次IMCP echo请求，收到102的ICMP响应后，判断主机存活，不在发送其它数据包。
在这里插入图片描述

选择一个不存活的IP：192.168.1.16，nmap会发送两次ICMP echo请求，第二次仍未收到106的ICMP响应时，则判断为主机不存活。不过这种方式存在一个问题，Nmap最多发送两次ICMP echo请求，在主机禁Ping的情况下或者丢包情况下会造成漏报。

其实最简单的方法就是把VMware的网络连接方式改为桥接模式。既然问题是VMware的NAT引起的，那就索性不用NAT了，改成桥接，这也是VMware官方的建议。
在这里插入图片描述
其实，VMware网络连接使用桥接模式，好处不只是解决了Nmap对主机存活的误判，也避免了无法traceroute和操作系统判断不准确（我们通常会使用TTL来判断操作系统，而经过VMware NAT返回的数据包，TTL永远是128，即使对方操作系统是Linux。）的问题，可以直接创建反弹shell监听端口，网络性能上也优于NAT。

在使用-O参数猜测目标的操作系统时，桥接模式会好于NAT模式。所以渗透测试首选桥接模式。

不过NAT模式也不是没有好处，在NAT模式下，主机会被局域网隔开，相当于多了一层保护。其次就是可以和主机共享一个IP地址。因为对于苦苦的学生来说，桥接模式要用不同的账号认证校园网。也就是说，在有Portal认证的WiFi下，物理机连接后，虚拟机无法使用桥接模式。一般web认证页域名如下：

https://portal.xxx.cn

原因在于，使用桥接模式会单独分配局域网内一个IP，但是每个IP需要上网，必须经过校园网的认证，没有经过认证的IP是无法上网的，这就导致物理主机在连校园网的情况下，虚拟机是不能使用桥接模式的。具体可以看我这篇：传送门

在Portal的身份验证解决方案中，用户首次访问WLAN网络身份验证过程如图所示。具体认证流程如下：
在这里插入图片描述

第1步。用户连接到WLAN网络的SSID，通过DHCP服务器获取IP地址信息。

第2步。AC将监控用户的互联网流量。

第3步。当AC监控的用户流量达到阈值时（例如，流量阈值可以设置为5分钟累计流量为10kB），AC将向MAC绑定服务器发起MAC查询请求。

第4步。MAC绑定服务器将查询结果返回到AC:未绑定终端MAC信息。（由于此终端用户是第一次连接到WLAN网络，因此在MAC绑定服务器中没有此终端的MAC地址信息）

步骤5和AC将根据正常的Portal进程将Portal验证页重定向到终端。

第6步。用户终端输入用户名和密码信息以启动Portal验证。

第7步。实现AC和Portal服务器以及AAA服务器之间的Portal认证。

第8步。ac向mac绑定服务器发起mac绑定请求。MAC绑定服务器完成用户终端的MAC地址信息与Portal帐户的绑定。

第9步。用户身份验证成功，并且可以正常访问Internet。

在Portal的无感知认证解决方案中，用户重新访问WLAN网络认证过程，具体认证流程如下：

第1步。用户连接到WLAN网络的SSID，通过DHCP服务器获取IP地址信息。

第2步。AC将监控用户的互联网流量。

第3步。当AC监控的用户流量达到阈值时（例如，流量阈值可以设置为5分钟累计流量为10kB），AC将向MAC绑定服务器发起MAC查询请求。

第4步。MAC绑定服务器将查询结果返回到AC:终端MAC信息被绑定，并将终端Portal帐户/密码信息携带到AC以启动Portal身份验证。（由于此最终用户完成了第一次登录，MAC地址、Portal帐户/密码已在MAC绑定服务器中完成了信息绑定）

第5步。实现AC和Portal服务器以及AAA服务器之间的Portal认证。

第6步。用户身份验证成功，并且可以正常访问Internet。

更多内容关注公众号：“极客随想”。

附

TTL

TTL（Time To Live）是通过网络发送的数据包中包含的计时器值，它告诉接收者在丢弃数据包（数据包）并使其过期之前保留或使用数据包的时间。不同操作系统的TTL值不同。因此，我们可以根据TTL值确定操作系统。Linux默认值是64。
不同设备/操作系统的默认TTL值：
在这里插入图片描述

校园网Portal认证

Portal认证通常也称为Web认证，一般将Portal认证网站称为门户网站。用户上网时，必须在门户网站进行认证，如果未认证成功，仅可以访问特定的网络资源，认证成功后，才可以访问其他网络资源。
优点：
1、一般情况下，客户端不需要安装额外的软件，直接在Web页面上认证，简单方便。
2、便于运营，可以在Portal页面上进行业务拓展，如广告推送、企业宣传等。
3、技术成熟，被广泛应用于运营商、连锁快餐、酒店、学校等网络。
4、部署位置灵活，可以在接入层或关键数据的入口作访问控制。
5、用户管理灵活，可基于用户名与VLAN/IP地址/MAC地址的组合对用户进行认证。

Portal认证系统如图所示，其主要包括四个基本要素：客户端、接入设备、Portal服务器与认证服务器。
在这里插入图片描述
1、接入设备：交换机、路由器等接入设备的统称，主要有三方面的作用。

在认证之前，将认证网段内用户的所有HTTP/HTTPS请求都重定向到Portal服务器。
在认证过程中，与Portal服务器、认证服务器交互，完成对用户身份认证、授权与计费的功能。
在认证通过后，允许用户访问被管理员授权的网络资源。

2、Portal服务器：接收客户端认证请求的服务器系统，提供免费门户服务和认证界面，与接入设备交互客户端的认证信息。
3、认证服务器：与接入设备进行交互，完成对用户的认证、授权与计费。

Portal服务器可以是接入设备之外的独立实体（外置Portal服务器），也可以是存在于接入设备之内的内嵌实体（内置Portal服务器）。内置Portal服务器的接入设备实现了简单的Portal服务器功能，仅能给用户提供通过Web方式上线、下线的基本功能，并不能完全替代独立的Portal服务器，也不支持外置独立服务器的任何扩展功能，例如不支持MAC优先的Portal认证。
通过内置Portal服务器进行Portal认证，由于不需要部署额外的Portal服务器，故增强了Portal认证的通用性。但是，受限于接入设备存储空间、功能和性能，内置Portal服务器适用于功能简单、接入人数少的场景，例如小型餐馆提供的连接Internet服务。

按照网络中实施Portal认证的网络层次来分，Portal认证方式分为两种：二层认证方式和三层认证方式。

当客户端与接入设备之间为二层网络时，即客户端与接入设备直连（或之间只有二层设备存在），接入设备可以学习到客户端的MAC地址，则接入设备可以利用IP地址和MAC地址来识别用户，此时可配置Portal认证为二层认证方式。

二层认证流程简单，安全性高，但由于限制了用户只能与接入设备处于同一网段，所以组网灵活性不高。

当客户端与接入设备之间包含三层网络时，即客户端与接入设备之间存在三层转发设备，接入设备不能获取到认证客户端的MAC地址，只能以IP地址作为用户的唯一标识，此时需要将Portal认证配置为三层认证方式。

三层认证组网灵活，容易实现远程控制，但由于只能以IP地址作为用户的唯一标识，所以安全性不高。

在二层认证方式下，用户上线时的报文交互流程如图所示。对于三层认证方式，客户端与接入设备之间没有建立预连接过程，其余报文处理流程跟二层认证完全一致。
在这里插入图片描述

在认证之前客户端与接入设备之间建立起预连接，即客户端用户在认证成功之前在接入设备上已建立用户在线表项，并且只有部分网络访问权限。
客户端发起HTTP连接请求。
接入设备收到HTTP连接请求报文时，如果是访问Portal服务器或免认证网络资源的HTTP报文，则接入设备允许其通过；如果是访问其它地址的HTTP报文，则接入设备将其URL地址重定向到Portal认证页面。
客户端根据获得的URL地址向Portal服务器发起HTTP连接请求。
Portal服务器向客户端返回Portal认证页面。
用户在Portal认证页面输入用户名和密码后，客户端向Portal服务器发起Portal认证请求。
（可选）Portal服务器收到Portal认证请求后，如果Portal服务器与接入设备之间采用CHAP认证，则Portal服务器向接入设备发起Portal挑战字请求报文（REQ_CHALLENGE）；如果Portal服务器与接入设备之间采用PAP认证，则接入设备直接进行第9步。
（可选）接入设备向Portal服务器回应Portal挑战字应答报（ACK_CHALLENGE）。
Portal服务器将用户输入的用户名和密码封装在Portal认证请求报文（REQ_AUTH）中，并发送给接入设备。
接入设备根据获取到的用户名和密码，向RADIUS服务器发送RADIUS认证请求（ACCESS-REQUEST）。
RADIUS服务器对用户名和密码进行认证。如果认证成功，则RADIUS服务器向接入设备发送认证接受报文（ACCESS-ACCEPT）；如果认证失败，则RADIUS服务器返回认证拒绝报文（ACCESS-REJECT）。由于RADIUS协议合并了认证和授权的过程，因此认证接受报文中也包含了用户的授权信息。
接入设备根据接收到的认证结果接入/拒绝用户。如果允许用户接入，则接入设备向RADIUS服务器发送计费开始请求报文（ACCOUNTING-REQUEST）。
RADIUS服务器返回计费开始响应报文（ACCOUNTING-RESPONSE），并开始计费，将用户加入自身在线用户列表。
接入设备向Portal服务器返回Portal认证结果（ACK_AUTH），并将用户加入自身在线用户列表。
Portal服务器向客户端发送认证结果报文，通知客户端认证成功，并将用户加入自身在线用户列表。
Portal服务器向接入设备发送认证应答确认（AFF_ACK_AUTH）。