一、端口扫描简介
 
1.二三四层发现的目的只是为了准确发现所有存活的主机IP，确定攻击目标。端口扫描即发现开放端口，发现攻击点。一个端口就是一个潜在的通信通道，也就是一个入侵通道。对目标计算机进行端口扫描，能得到许多有用的信息。
 2.进行端口扫描的原因
 (1):端口对应网络服务及应用端程序
 (2):服务端程序的漏洞通过端口攻入。
 (3):通过发现的端口来放大攻击面
 
二、UDP端口扫描
 
原理:因为UDP是面向无连接的传输协议，尽最大努力传输。因此使用UDP来探测开启的端口的步骤如下：
 (1):先向目标主机发送一个数据包并且目的端口是一个没有开启的端口(选择一个不常用并且尽可能大的端口)，如果收到数据包并且表明端口不可达，则表明主机存活。
 (2):然后向目标主机发送需要测试的端口，如果收到数据包且表明端口不可达，则端口关闭；如果没有收到数据包，则端口开启
优点:速度快
缺点:准确性差
 
1.scapy
 
 
 
(1):探测主机是否存活
 sr1(IP(dst=‘192.168.223.10’)/UDP(dport=8786),timeout=5,verbose=0).display()
 
 
IP(dst=‘192.168.223.10’):设置目标IP
UDP(dport=8786):设置目标端口
timeout=5:设置超时时间
verbose=0:verbose=0不显示详细信息，verbose=1显示详细信息
 
 
 
 
 
(2):探测端口是否开启
 
 
 
三、TCP端口扫描
 
TCP端口扫描可以分为两类:全连接扫描、半连接扫描
 1.全连接扫描
 
原理:扫描者向目标主机发送一个SYN+SYN/ACK数据包，目标主机会回复一个ACK数据包。无法利用scapy模块进行全连接扫描，因为如果同时向目标主机发送一个SYN+SYN/ACK数据包，目标主机会认为这是一个错误的数据包，会直接回复一个RST。如果向目标主机发送一个SYN数据包，目标主机会回复一个SYN/ACK数据包，但是此时并没有再向目标主机发送ACK数据包，因此，全连接无法建立。(但是可以使用nmap中的-sT参数来进行全连接扫描)
优点:探测结果准确
缺点:会被目标主机的日志记录
 
 
 
(1):nmap
 namp -sT IP地址
 -sT:进行全连接扫描
 可以使用-p来指定端口号或端口范围，不指定默认扫描前1000个端口
 
 
 
 
 
(2):dmitry
 dmitry使用全连接进行扫描，默认扫描最常用的150个端口
 dmitry -p IP地址
 
 
 
 
 
(3):nc
 nc -nv -w 超时时间 -z IP地址 端口号
 -n表示跟数字内容，-v表示不做域名解析 -w表示超时时间 -z表示使用扫描模式
 
 
 
2.半连接扫描(也称为隐蔽扫描)
 
原理:扫描者向目标主机发送一个SYN，如果目标主机回复了一个SYN/ACK数据包，那么说明主机存活，如果收到一个RST/ACK数据包，那么主机没有存活。因为扫描者只向目标主机发送了SYN，并没有和目标主机进行连接，因此称为半连接。
优点:不会在目标主机的日志上有所记录
缺点:扫描结果不是很准确
 
 
 
(1):scapy
 
 
 
 
 
(2):nmap
 nmap -sS IP地址
 -sS:进程半连接扫描
 可以使用-p来指定端口号或端口范围，不指定默认扫描前1000个端口
 
 
 
 
 
hping3
 hping3 IP地址 --scan 目标端口 -S
 
 

0x01 简介
 
今天用了用nmap的半连接扫描，不禁想知道半连接什么意思，它们有什么区别。
 
nmap扫描类型主要有TCP的全连接扫描(会在被扫描机器留下记录)，半连接扫描(不会留下记录)
 
0x02 原理
 
 
只有tcp三次握手完整才会在服务器留下记录，所以我们可以省略第三次握手，同样可以达到扫描的目的，但是不会在服务器留下记录。
 
我们先使用向服务器指定端口发送SYN请求，如果收到服务器的SYN+ACK回复，即可判断此端口开放，反之同理。

问题描述
 
JAVA的client和server，使用socket通信。server使用NIO。 
 
间歇性的出现client向server建立连接三次握手已经完成，但server的selector没有响应到这连接。 
出问题的时间点，会同时有很多连接出现这个问题。 
selector没有销毁重建，一直用的都是一个。 
程序刚启动的时候必会出现一些，之后会间歇性出现。
分析问题
 
正常TCP建连接三次握手过程： 
 
 
第一步：client 发送 syn 到server 发起握手； 
第二步：server 收到 syn后回复syn+ack给client； 
第三步：client 收到syn+ack后，回复server一个ack表示收到了server的syn+ack（此时client的56911端口的连接已经是established） 
从问题的描述来看，有点像TCP建连接的时候全连接队列（accept队列）满了，尤其是症状2、4. 为了证明是这个原因，马上通过 ss -s 去看队列的溢出统计数据： 
 667399 times the listen queue of a socket overflowed
 
反复看了几次之后发现这个overflowed 一直在增加，那么可以明确的是server上全连接队列一定溢出了 
 接着查看溢出后，OS怎么处理：
 
cat /proc/sys/net/ipv4/tcp_abort_on_overflow
0
 
 
 
tcp_abort_on_overflow 为0表示如果三次握手第三步的时候全连接队列满了那么server扔掉client 发过来的ack（在server端认为连接还没建立起来） 
 为了证明客户端应用代码的异常跟全连接队列满有关系，我先把tcp_abort_on_overflow修改成 1，1表示第三步的时候如果全连接队列满了，server发送一个reset包给client，表示废掉这个握手过程和这个连接（本来在server端这个连接就还没建立起来）。 
 接着测试然后在客户端异常中可以看到很多connection reset by peer的错误，到此证明客户端错误是这个原因导致的。 
 于是开发同学翻看java 源代码发现socket 默认的backlog（这个值控制全连接队列的大小，后面再详述）是50，于是改大重新跑，经过12个小时以上的压测，这个错误一次都没出现过，同时 overflowed 也不再增加了。 
 到此问题解决，简单来说TCP三次握手后有个accept队列，进到这个队列才能从Listen变成accept，默认backlog 值是50，很容易就满了。满了之后握手第三步的时候server就忽略了client发过来的ack包（隔一段时间server重发握手第二步的syn+ack包给client），如果这个连接一直排不上队就异常了。
 
深入理解TCP握手过程中建连接的流程和队列
 

 （图片来源：http://www.cnxct.com/something-about-phpfpm-s-backlog/） 
 如上图所示，这里有两个队列：syns queue(半连接队列）；accept queue（全连接队列） 
 三次握手中，在第一步server收到client的syn后，把相关信息放到半连接队列中，同时回复syn+ack给client（第二步）； 
 比如syn floods 攻击就是针对半连接队列的，攻击方不停地建连接，但是建连接的时候只做第一步，第二步中攻击方收到server的syn+ack后故意扔掉什么也不做，导致server上这个队列满其它正常请求无法进来。
 
第三步的时候server收到client的ack，如果这时全连接队列没满，那么从半连接队列拿出相关信息放入到全连接队列中，否则按tcp_abort_on_overflow指示的执行。 
 这时如果全连接队列满了并且tcp_abort_on_overflow是0的话，server过一段时间再次发送syn+ack给client（也就是重新走握手的第二步），如果client超时等待比较短，就很容易异常了。 
 在我们的os中retry 第二步的默认次数是2（centos默认是5次）： 
 net.ipv4.tcp_synack_retries = 2
 
如果TCP连接队列溢出，有哪些指标可以看呢？
 
上述解决过程有点绕，那么下次再出现类似问题有什么更快更明确的手段来确认这个问题呢？
 
netstat -s 
 [root@server ~]# netstat -s | egrep “listen|LISTEN” 
 667399 times the listen queue of a socket overflowed 
 667399 SYNs to LISTEN sockets ignored
 
比如上面看到的 667399 times ，表示全连接队列溢出的次数，隔几秒钟执行下，如果这个数字一直在增加的话肯定全连接队列偶尔满了。
 
ss 命令 
 [root@server ~]# ss -lnt 
 Recv-Q Send-Q Local Address:Port Peer Address:Port 
 0 50 :3306 :*
 
上面看到的第二列Send-Q 表示第三列的listen端口上的全连接队列最大为50，第一列Recv-Q为全连接队列当前使用了多少 
 全连接队列的大小取决于：min(backlog, somaxconn) . backlog是在socket创建的时候传入的，somaxconn是一个os级别的系统参数 
 半连接队列的大小取决于：max(64, /proc/sys/net/ipv4/tcp_max_syn_backlog)。 不同版本的os会有些差异
 
实践验证下上面的理解
 
把java中backlog改成10（越小越容易溢出），继续跑压力，这个时候client又开始报异常了，然后在server上通过 ss 命令观察到： 
 Fri May 5 13:50:23 CST 2017 
 Recv-Q Send-QLocal Address:Port Peer Address:Port 
 11 10 :3306 :*
 
按照前面的理解，这个时候我们能看到3306这个端口上的服务全连接队列最大是10，但是现在有11个在队列中和等待进队列的，肯定有一个连接进不去队列要overflow掉
 
容器中的Accept队列参数
 
Tomcat默认短连接，backlog（Tomcat里面的术语是Accept count）Ali-tomcat默认是200, Apache Tomcat默认100. 
 ss -lnt 
 Recv-Q Send-Q Local Address:Port Peer Address:Port 
 0 100 :8080 :*
 
Nginx默认是511 
 $sudo ss -lnt 
 State Recv-Q Send-Q Local Address:PortPeer Address:Port 
 LISTEN 0 511 :8085 :* 
 LISTEN 0 511 :8085 :*
 
因为Nginx是多进程模式，也就是多个进程都监听同一个端口以尽量避免上下文切换来提升性能
 
进一步思考
 
如果client走完第三步在client看来连接已经建立好了，但是server上的对应连接实际没有准备好，这个时候如果client发数据给server，server会怎么处理呢？（有同学说会reset，还是实践看看） 
 先来看一个例子： 

 （图片来自：http://blog.chinaunix.net/uid-20662820-id-4154399.html） 
 如上图，150166号包是三次握手中的第三步client发送ack给server，然后150167号包中client发送了一个长度为816的包给server，因为在这个时候client认为连接建立成功，但是server上这个连接实际没有ready，所以server没有回复，一段时间后client认为丢包了然后重传这816个字节的包，一直到超时，client主动发fin包断开该连接。 
 这个问题也叫client fooling，可以看这里：https://github.com/torvalds/linux/commit/5ea8ea2cb7f1d0db15762c9b0bb9e7330425a071 （感谢浅奕的提示) 
 从上面的实际抓包来看不是reset，而是server忽略这些包，然后client重传，一定次数后client认为异常，然后断开连接。
 
过程中发现的一个奇怪问题
 
[root@server ~]# date; netstat -s | egrep “listen|LISTEN” 
 Fri May 5 15:39:58 CST 2017 
 1641685 times the listen queue of a socket overflowed 
 1641685 SYNs to LISTEN sockets ignored
 
[root@server ~]# date; netstat -s | egrep “listen|LISTEN” 
 Fri May 5 15:39:59 CST 2017 
 1641906 times the listen queue of a socket overflowed 
 1641906 SYNs to LISTEN sockets ignored
 
如上所示： 
 overflowed和ignored居然总是一样多，并且都是同步增加，overflowed表示全连接队列溢出次数，socket ignored表示半连接队列溢出次数，没这么巧吧。 
 翻看内核源代码（http://elixir.free-electrons.com/linux/v3.18/source/net/ipv4/tcp_ipv4.c）： 
 
 可以看到overflow的时候一定会drop++（socket ignored），也就是drop一定大于等于overflow。 
 同时我也查看了另外几台server的这两个值来证明drop一定大于等于overflow： 
 server1 
 150 SYNs to LISTEN sockets dropped
 
server2 
 193 SYNs to LISTEN sockets dropped
 
server3 
 16329 times the listen queue of a socket overflowed 
 16422 SYNs to LISTEN sockets dropped
 
server4 
 20 times the listen queue of a socket overflowed 
 51 SYNs to LISTEN sockets dropped
 
server5 
 984932 times the listen queue of a socket overflowed 
 988003 SYNs to LISTEN sockets dropped
 
那么全连接队列满了会影响半连接队列吗？
 
来看三次握手第一步的源代码（http://elixir.free-electrons.com/linux/v2.6.33/source/net/ipv4/tcp_ipv4.c#L1249）： 
 
 TCP三次握手第一步的时候如果全连接队列满了会影响第一步drop 半连接的发生。大概流程的如下：
 
tcp_v4_do_rcv->tcp_rcv_state_process->tcp_v4_conn_request
//如果accept backlog队列已满，且未超时的request socket的数量大于1，则丢弃当前请求  
  if(sk_acceptq_is_full(sk) && inet_csk_reqsk_queue_yong(sk)>1)
      goto drop;
 
 
 
总结
 
全连接队列、半连接队列溢出这种问题很容易被忽视，但是又很关键，特别是对于一些短连接应用（比如Nginx、PHP，当然他们也是支持长连接的）更容易爆发。 一旦溢出，从cpu、线程状态看起来都比较正常，但是压力上不去，在client看来rt也比较高（rt=网络+排队+真正服务时间），但是从server日志记录的真正服务时间来看rt又很短。 
 希望通过本文能够帮大家理解TCP连接过程中的半连接队列和全连接队列的概念、原理和作用，更关键的是有哪些指标可以明确看到这些问题。 
 另外每个具体问题都是最好学习的机会，光看书理解肯定是不够深刻的，请珍惜每个具体问题，碰到后能够把来龙去脉弄清楚。
 
 
 
参考文章
 
 
http://veithen.github.io/2014/01/01/how-tcp-backlog-works-in-linux.html
 
 
http://www.cnblogs.com/zengkefu/p/5606696.html
 
 
http://www.cnxct.com/something-about-phpfpm-s-backlog/
 
 
http://jaseywang.me/2014/07/20/tcp-queue-%E7%9A%84%E4%B8%80%E4%BA%9B%E9%97%AE%E9%A2%98/
 
 
http://jin-yang.github.io/blog/network-synack-queue.html#
 
 
http://blog.chinaunix.net/uid-20662820-id-4154399.html
 

常见的端口扫描类型及原理
 
常见的扫描类型有以下几种：
 
     
 
 
 
秘密扫描
 
秘密扫描是一种不被审计工具所检测的扫描技术。
 它通常用于在通过普通的防火墙或路由器的筛选（filtering）时隐藏自己。
 秘密扫描能躲避IDS、防火墙、包过滤器和日志审计，从而获取目标端口的开放或关闭的信息。由于没有包含TCP 3次握手协议的任何部分，所以无法被记录下来，比半连接扫描更为隐蔽。
 但是这种扫描的缺点是扫描结果的不可靠性会增加，而且扫描主机也需要自己构造IP包。现有的秘密扫描有TCP FIN扫描、TCP ACK扫描、NULL扫描、XMAS扫描和SYN/ACK扫描等。 
 
1、Connect()扫描：
 
     此扫描试图与每一个TCP端口进行“三次握手”通信。如果能够成功建立接连，则证明端口开发，否则为关闭。准确度很高，但是最容易被防火墙和IDS检测到，并且在目标主机的日志中会记录大量的连接请求以及错误信息。
 
TCP connect端口扫描服务端与客户端建立连接成功（目标端口开放）的过程： 
 ① Client端发送SYN；
 ② Server端返回SYN/ACK，表明端口开放；
 ③ Client端返回ACK，表明连接已建立；
 ④ Client端主动断开连接。
 建立连接成功（目标端口开放）如图所示
 

 
 
 
TCP connect端口扫描服务端与客户端未建立连接成功（目标端口关闭）过程： 
 ① Client端发送SYN；
 ② Server端返回RST/ACK，表明端口未开放。
 未建立连接成功(目标端口关闭)如图所示。
 

 
 
优点：实现简单，对操作者的权限没有严格要求（有些类型的端口扫描需要操作者具有root权限），系统中的任何用户都有权力使用这个调用，而且如果想要得到从目标端口返回banners信息，也只能采用这一方法。
 另一优点是扫描速度快。如果对每个目标端口以线性的方式，使用单独的connect()调用，可以通过同时打开多个套接字，从而加速扫描。
 缺点：是会在目标主机的日志记录中留下痕迹，易被发现，并且数据包会被过滤掉。目标主机的logs文件会显示一连串的连接和连接出错的服务信息，并且能很快地使它关闭。
 
2、SYN扫描：
 
      扫描器向目标主机的一个端口发送请求连接的SYN包，扫描器在收到SYN/ACK后，不是发送的ACK应答而是发送RST包请求断开连接。这样，三次握手就没有完成，无法建立正常的TCP连接，因此，这次扫描就不会被记录到系统日志中。这种扫描技术一般不会在目标主机上留下扫描痕迹。但是，这种扫描需要有root权限。
 

     
 
端口开放：1、Client发送SYN  2、Server端发送SYN/ACK 3、Client发送RST断开（只需要前两步就可以判断端口开放）
 
端口关闭：1、Client发送SYN  2、Server端回复RST（表示端口关闭）
 
优点：SYN扫描要比TCP Connect()扫描隐蔽一些，SYN仅仅需要发送初始的SYN数据包给目标主机，如果端口开放，则相应SYN-ACK数据包；如果关闭，则响应RST数据包；
 
3、NULL扫描：
 
反向扫描----原理是将一个没有设置任何标志位的数据包发送给TCP端口，在正常的通信中至少要设置一个标志位，根据FRC 793的要求，在端口关闭的情况下，若收到一个没有设置标志位的数据字段，那么主机应该舍弃这个分段，并发送一个RST数据包，否则不会响应发起扫描的客户端计算机。也就是说，如果TCP端口处于关闭则响应一个RST数据包，若处于开放则无相应。但是应该知道理由NULL扫描要求所有的主机都符合RFC 793规定，但是windows系统主机不遵从RFC 793标准，且只要收到没有设置任何标志位的数据包时，不管端口是处于开放还是关闭都响应一个RST数据包。但是基于Unix(*nix,如Linux)遵从RFC 793标准，所以可以用NULL扫描。   经过上面的分析，我们知道NULL可以辨别某台主机运行的操作系统是什么操作系统，是为windows呢？还是*nix？
 
端口开放：Client发送Null，server没有响应
 

 
 
 
端口关闭：1、Client发送NUll   2、Server回复RST
 
 

 
 
说明：Null扫描和前面的TCP Connect（）和SYN的判断条件正好相反。在前两种扫描中，有响应数据包的表示端口开放，但在NUll扫描中，收到响应数据包表示端口关闭。反向扫描比前两种隐蔽性高些，当精确度也相对低一些。
 
用途：判断是否为Windows系统还是*nix
 
4、FIN扫描：
 
       与NULL有点类似，只是FIN为指示TCP会话结束，在FIN扫描中一个设置了FIN位的数据包被发送后，若响应RST数据包，则表示端口关闭，没有响应则表示开放。此类扫描同样不能准确判断windows系统上端口开发情况。
 
端口开放：发送FIN，没有响应
 
端口关闭：1、发送FIN  2、回复RST
 
5、ACK扫描：
 
     扫描主机向目标主机发送ACK数据包。根据返回的RST数据包有两种方法可以得到端口的信息。方法一是： 若返回的RST数据包的TTL值小于或等于64，则端口开放，反之端口关闭，如图所示。
 
 

 
 
6、Xmas-Tree扫描：
 
通过发送带有下列标志位的tcp数据包
 
                                URG：指示数据时紧急数据，应立即处理。
 
                                PSH：强制将数据压入缓冲区。
 
                                 FIN：在结束TCP会话时使用。
 
正常情况下，三个标志位不能被同时设置，但在此种扫描中可以用来判断哪些端口关闭还是开放，与上面的反向扫描情况相同，依然不能判断windows平台上的端口。
 
端口开放：发送URG/PSH/FIN,没有响应
 

 
 
 
端口关闭：1、发送URG/PSH/FIN,没有响应   2、响应RST
 
 

 
 
XMAS扫描原理和NULL扫描的类似，将TCP数据包中的ACK、FIN、RST、SYN、URG、PSH标志位置1后发送给目标主机。在目标端口开放的情况下，目标主机将不返回任何信息。
 
7、Dump扫描：
 
       也被称为Idle扫描或反向扫描，在扫描主机时应用了第三方僵尸计算机扫描。由僵尸主机向目标主机发送SYN包。目标主机端口开发时回应SYN|ACK，关闭时返回RST，僵尸主机对SYN|ACK回应RST，对RST不做回应。从僵尸主机上进行扫描时，进行的是一个从本地计算机到僵尸主机的、连续的ping操作。查看僵尸主机返回的Echo响应的ID字段，能确定目标主机上哪些端口是开放的还是关闭的。