端口扫描技术浅析

2019-03-16 本文已影响8人慕长风啊

前言

前阵子参加腾讯面试的时候，被问到17年在图书馆复现ms17-010时的具体情境。
提及端口扫描过程时，我讲到后面自己动手写了个批量扫描445端口的脚本，但记不清技术细节了，那会儿只知道简单的调用个Socket。
现在即使回想起来，发现自己对端口探测具体原理也没法说的很完整，只知道个大概。
所以这次打算好好写写端口扫描这块儿，把基本功打牢。

思路

提及端口扫描，一般首先都会想到Nmap，所以这次的分析思路是从Nmap常用的几种端口扫描技术入手，具体分析几种常用方法的原理以及优劣，后面尝试自己动手写几个探测脚本，最后实战一波加上抓包分析看看效果。

~~下面开始正文~~

常用的几种端口扫描技术

C：源地址（Client）
S：目标地址（Server）

1.TCP SYN扫描

Nmap默认且最受欢迎的一种扫描方式，快速而不张扬
它从不完成一次完整的TCP连接，又称为半开放扫描

扫描步骤：
C发送一个SYN报文然后等待响应

S返回SYN/ACK，表明端口开放（open）
S返回RST，表明端口关闭（closed）
数次重发后C无响应，端口被过滤（filtered）
剩下情况（如ICMP不可达等错误）也显示被过滤（filtered），具体后面作抓包复现
待完成：图书馆445端口探测

优点：隐蔽，一般不会被记入系统日志
缺点：需要root权限。不适合使用多线程技术。因为在实现过程中需要自己完成对应答数据报的查找、分析，使用多线程容易发生数据报的串位现象，也就是原来应该这个线程接收的数据报被另一个线程接收，接收后，这个数据报就会被丢弃，而等待线程只好在超时之后再发送一个SYN数据报，等待应答。这样，所用的时间反而会增加。

2.TCP Connect()扫描

Nmap中，当SYN扫描不能用（一般是权限不够）时，默认用此种方法。

注意！

Nmap通过创建connect() 系统调用要求操作系统和目标机以及端口建立连接，而不像其它扫描类型直接发送原始报文。这是和Web浏览器，P2P客户端以及大多数其它网络应用程序用以建立连接一样的高层系统调用。它是叫做Berkeley Sockets API编程接口的一部分。Nmap用该API获得每个连接尝试的状态信息，而不是读取响应的原始报文。

这种高层系统调用的方法，对原始报文的控制更少，需要更多的报文得到同样的信息，效率较低，同时也会在目标机留下更多记录。

扫描步骤：

端口开放情况下：
--> C发送SYN
<-- S返回SYN/ACK，表明端口开放（open）
--> C返回ACK
<-- C主动断开连接
端口关闭时：
--> C发送SYN
<-- S返回RST/SYN，表明端口未开放（closed）

优点：
实现简单，对操作系统没有严格的权限要求。
如果想要得到从目标端口返回banners信息，也只能采用这一方法。（待实践）
缺点：
留下痕迹过多，易被发现。

以上是最常用的两种端口扫描方式，后面还有其他一些扫描方式，简单的提一提，暂不作具体实现了。

3.UDP扫描

这个其实用的比较少，因为大多流行服务都是运行在TCP协议上，但是用UDP协议的常见服务也有DNS，SNMP和DHCP这几种。
另外UDP扫描一般比较慢，用作辅助扫描比较好。
在Nmap中，UDP扫描发送空的UDP报头到目标端口，如果返回ICMP端口不可达错误（类型3，代码3），则该端口是closed，其他ICMP不可到达错误则表明端口是filtered，如果目标响应了一个UDP报文，则证明是open，多次重试还没有响应，则有可能是open，也有可能是filtered。

“UDP扫描的巨大挑战是怎样使它更快速。开放的和被过滤的端口很少响应，让Nmap超时然后再探测，以防探测帧或者响应丢失。关闭的端口常常是更大的问题。它们一般发回一个ICMP端口无法到达错误。但是不像关闭的TCP端口响应SYN或者Connect 扫描所发送的RST报文，许多主机在默认情况下限制ICMP端口不可到达消息。 Linux和Solaris对此特别严格。例如， Linux 2.4.20内核限制一秒钟只发送一条目标不可到达消息”

4.秘密扫描

“秘密扫描是一种不被审计工具所检测的扫描技术。
它通常用于在通过普通的防火墙或路由器的筛选（filtering）时隐藏自己。
秘密扫描能躲避IDS、防火墙、包过滤器和日志审计，从而获取目标端口的开放或关闭的信息。由于没有包含TCP 3次握手协议的任何部分，所以无法被记录下来，比半连接扫描更为隐蔽。
但是这种扫描的缺点是扫描结果的不可靠性会增加，而且扫描主机也需要自己构造IP包。现有的秘密扫描有TCP FIN扫描、TCP ACK扫描、NULL扫描、XMAS扫描和SYN/ACK扫描等。 ”

秘密扫描包含TCP Null扫描，FIN扫描，Xmas扫描等方式，这三种方式有个共同点，它们都是根据TCP RFC793规定来区分open和closed
按照规定，在端口关闭的情况下，若收到一个没有设置标志位的数据字段，那么主机应该舍弃这个分段，并发送一个RST数据包，否则不会响应发起扫描的客户端计算机。

Null扫描是不设置任何标志位
FIN扫描是只设置TCP FIN标志位
Xmas扫描设置FIN，PSH，和URG标志位，就像点亮圣诞树上所有的灯一样。

Nmap上这几种扫描的行为基本一致，如果收到一个RST报文，该端口被认为是 closed，而没有响应则意味着是open|filtered。如果收到ICMP不可到达错误(类型 3，代号 1，2，3，9，10，或者13)，该端口就被标记为 filtered。

放张图补充一下ICMP报文类型，方便理解防火墙过滤扫描数据包后返回的ICMP响应：

ICMP

注意！

windows系统主机不遵从RFC 793标准，且只要收到没有设置任何标志位的数据包时，不管端口是处于开放还是关闭都响应一个RST数据包。

所以上面几种方式只适用于扫描Unix，当然，这个特点还可以用于判断目标操作系统类型。

5. TCP ACK扫描

在上面的秘密扫描里提到过，个人觉得比较有意思，就单独拎出来了。
这其实也属于一种“半开放”扫描方式，扫描主机向目标主机发送ACK数据包，如果目标返回一个RST数据包，则表明该主机存在，如果这个数据包中TTL值不大于64或者WINDOW值为0，则表明目标端口出于open状态，否则为closed。
注意！
这里的TTL值，windows和Unix默认值不一样，一般可认为前者为128，后者为64，具体根据内核版本会有所区别，所以一般是对同一主机多端口发送大量ACK数据包，若其中某端口返回的RST数据包中TTL值明显小于其他，则说明该端口可能开放。

除此之外，还有TCP窗口扫描，TCP Maimon扫描和定制的TCP扫描等等，这里就不再展开了。
关于Nmap中更多的扫描姿势，可以参考：
https://nmap.org/book/man.html

打造自己的端口扫描器

我的今天的目标呢，是针对图书馆内网环境中进行单端口多IP扫描。
这里我打算借鉴masscan，zmap等工具的扫描方法——无状态SYN扫描
主要用到Python中的scapy库

先建个待扫描的ip队列和列表，列表用于去除无用ip：

ip_queue = Queue()
ip_list = list()
def load_ips():
    with open(args.file_name) as f:
        for line in f:
            ip = line.strip()
            ip_list.append(ip)
            ip_queue.put(ip)

发包函数：

def send_syn():
    while not ip_queue.empty():
        ip = ip_queue.get()
        send(IP(dst=ip)/TCP(dport=PORT, sport=RandShort(), flags=2), verbose=False)

流量嗅探，iface指定网卡，filter参数用于过滤：

# tcpdump语法过滤数据包
def sniffer():
    sniff(iface=INTERFACE, filter='tcp and dst {} and src port {}'.format(USER_IP, PORT), prn=prn)

回调函数prn，主要用于数据处理和日志打印：

# 回调函数
def prn(pkt):
    flag = pkt.getlayer(TCP).flags
    src_ip = pkt.getlayer(IP).src
    if src_ip not in ip_list:
        return
    if flag == "SA":
        print(pkt.sprintf("%IP.src%:%IP.sport%  is open!!!"))
    else:
        print(pkt.sprintf("%IP.src%:%IP.sport%  is closed.\tflag: {}".format(flag)))

最后用多线程发包，单独开个线程嗅探
详细代码可见Github：
https://github.com/Moofeng/life_tools/blob/master/syn_scan.py
实战中，注意计算带宽和速率来选择线程数

图书馆实战

原本写这篇博客的动机就是想在图书馆重新找回场子，然而接下来的事实证明我还是技艺不精啊。。
我先是用arp-scan扫描了下内网存活主机：

Command: arp-scan --interface=wlan0 -l > ips.txt

Interface: wlan0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.9.5 with 16384 hosts (https://github.com/royhills/arp-scan)
10.138.129.22   a4:50:46:e0:c2:5a   (Unknown)
10.138.129.12   18:f1:d8:c7:53:41   (Unknown)
10.138.129.8    dc:2b:2a:8d:6e:fb   Apple, Inc.
10.138.129.49   78:36:cc:f6:9a:8d   (Unknown)
10.138.129.79   1c:77:f6:a7:a0:c8   GUANGDONG OPPO MOBILE TELECOMMUNICATIONS CORP.,LTD
10.138.129.92   dc:85:de:98:81:44   AzureWave Technology Inc.
10.138.129.93   30:52:cb:77:c3:57   Liteon Technology Corporation
10.138.129.103  86:fb:a2:38:aa:f7   (Unknown)
10.138.129.50   c8:94:bb:ec:9e:cc   (Unknown)
...

整理下：

cat ips.txt | grep -E -o  "([0-9]{1,3}[\.]){3}[0-9]{1,3}" > ip.txt

然后祭出我刚刚打造的大杀器，结果...

scan_result

什么都没扫到...
担心是我写的扫描器除了问题，于是上nmap扫一下抓个包看看

nmap_445
无响应，可能是被过滤了，后面我自己也发包尝试了下，都是无响应，应该是被过滤了。
另外从抓包分析的过程中，我发现nmap会对第一次无响应的主机会重复发包，多次无响应才会返回filtered。

我上面写的代码中忘记加入这一步了，网络状况不好的话对扫描结果会有较大影响。

结语

今天先写到这儿了，在图书馆待了一天还没吃饭，先去吃饭了。
虽然这次实验很遗憾又以失败告终，但在抓包分析的过程中至少对端口扫描这一块儿了解的比较清晰了。
最后还有几个问题待解决：

最后实验过程中我把扫描范围缩小到同一子网下了，为何数据包还是会被过滤呢？难道这时候局域网内主机间通信还要经过网关吗？（我一直认为过滤是发生在网关上的，不应该所有的个人ｐｃ都过滤了４４５吧）
网上都在吐槽scapy发包速度慢，据说一次发送一个c段会比较快？
代码中没有区分端口关闭和端口过滤的情况，待解决。