问题背景

某天想到一个常见的安全面试问题："为什么masscan扫描快？"

以往我认为是下面三点原因：

• 使用syn扫描
• 扫描地址随机化
• 发包和接受包使用了性能更好的pf_ring包处理框架

随着最近补了一些网络的基础知识，感觉有点不对劲：

• nmap也支持syn扫描、扫描地址随机化，所以masscan真的是因为这两点比nmap快么？
• nmap用的是啥发包，它为什么不用pf_ring呢？
• pf_ring真的快么？

这一篇文章主要记录我对syn扫描的学习和做扫描器时遇到的案例。

分析过程

什么是syn扫描？

也叫半连接扫描，基于sendto系统调用。

在syn扫描出现之前，端口扫描大多数基于connect系统调用，因此会完成tcp三次握手。

为什么要用syn扫描？

一般都会说syn有三个好处：

* 更隐蔽（相比于connect扫描）
* 更快（相比于connect扫描）
* 比ACK/Window/Maimon scans等扫描方式（namp的-sA/sW/sM参数）兼容性好

• 真的更隐蔽么？

  说syn扫描隐蔽的原因是"被扫描主机"和"IDS/IPS"设备 因为没有看到完整的"三次握手"，所以不会记录日志。

  然而现在的防护设备似乎都认识syn扫描，所以已经没有"更隐蔽"这个优势了。

• 为什么比connect扫描快？

  我以前的误区是connect扫描握手需要三个包，而syn扫描是只需要两个包，少发了一个包所以更快。

  实际上更快的原因是：

  当客户端发出去的syn包后收不到响应时（"网络质量不好"或者"扫描目标ip不存在"时会发生）

  * connect扫描因为用的是connect系统调用，所以会重传syn包。在linux默认配置时，最多会等待32s才会返回
  
  * syn扫描因为使用sendto系统调用，它把syn包发出去后就可以立马返回，不会等syn-ack包
  

  一个需要阻塞等待，另一个发送完就返回了，那肯定是发完就返回的快啊。

看到这里，不知道你会不会质疑我：发完就返回，不等syn-ack包，那syn扫描怎么判断端口是开放的。

syn扫描是怎么判断端口是开放的？

虽然sendto系统调用"不等待syn-ack包"，但是当syn-ack包来的时候我们再接着处理就好了。

比如当系统接收到一个syn-ack包，我们看一下包是不是从我们扫描对象发过来的，如果是我们就可以从syn-ack包中取出端口信息，认为目标端口是开放的。当然为了防止一些误报，我们还可以做一些检查。

所以在syn扫描实现时，我们可以采用两个线程（masscan也是这么实现的）：

• 一个线程专门来发syn包
• 另一个线程专门来接收syn-ack包，从syn-ack包中判断端口是否开放

show me the demo

网上找的一个demo 简单实现SYN端口扫描^[1]

发送请求：

sockfd = socket(AF_INET,SOCK_RAW,IPPROTO_TCP)  # 使用SOCK_RAW创建原始套接字
..
int ret = sendto(sockfd,buffer,sizeof(tcpHeader),0,(struct sockaddr*)&target,sizeof(target)) ;  # 发送syn包后立马返回

接收请求：

size = recvfrom(sockfd,msg,sizeof(msg),0,(struct sockaddr*)&myaddr,&len) ;  // 阻塞接收ack包

之前做扫描器实践中遇到的案例

端口扫描结果中发现有的ip开放了5000+个端口，并且端口上似乎没有什么业务。

估摸着我可能遇到了 DDOS之syn flood 原理及防护^[2] 中提到的syn代理。

防火墙只要遇到syn包都回syn-ack,这样syn扫描时就会认为端口是开放的。

PS：下次再碰到这样的目标详细看看。如果读者有现成的目标案例，欢迎公众号私信给我。

总结

• syn扫描比connect扫描快是因为connect扫描不太受用户程序控制，有可能等待很久。
• syn扫描实现会有两个线程，一个线程负责发syn包，另一个线程负责接收syn-ack包、判断端口开放、回rst包

另外nmap的文档关于syn扫描和connect扫描都写得很好，值得阅读。

参考资料