正在阅读：对DDoS攻击实例之SYN Flood攻击的详细内容讲述对DDoS攻击实例之SYN Flood攻击的详细内容讲述

　　此文章主要介绍的是DDoS攻击实例  SYN Flood攻击，我们大家都知道SYN-Flood是目前使用最广泛的DDoS攻击手段，早先的DoS的手段在向分布式这一阶段发展的时候也经历了千军万马过独木桥的过程。

　　SYN-Flood的攻击效果最好，应该是众黑客不约而同选择它的原因吧。那么我们一起来看看SYN-Flood的详细情况。

　　SYN-Flood是目前最流行的DDoS攻击手段，早先的DoS的手段在向分布式这一阶段发展的时候也经历了浪里淘沙的过程。SYN-Flood的攻击效果最好，应该是众黑客不约而同选择它的原因吧。那么我们一起来看看SYN-Flood的详细情况。

　　Syn Flood原理 - 三次握手

　　Syn Flood利用了TCP/IP协议的固有漏洞。面向连接的TCP三次握手是Syn Flood存在的基础。

　　TCP连接的三次握手

　　二，在第一步中，客户端向服务端提出连接请求。这时TCP SYN标志置位。客户端告诉服务端序列号区域合法，需要检查。客户端在TCP报头的序列号区中插入自己的ISN。服务端收到该TCP分段后，在第二步以自己的ISN回应(SYN标志置位)，同时确认收到客户端的第一个TCP分段(ACK标志置位)。在第三步中，客户端确认收到服务端的ISN(ACK标志置位)。到此为止建立完整的TCP连接，开始全双工模式的数据传输过程。

　　Syn Flood攻击者不会完成三次握手

　　假设一个用户向服务器发送了SYN报文后突然死机或掉线，那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的(第三次握手无法完成)，这种情况下服务器端一般会重试(再次发送SYN+ACK给客户端)并等待一段时间后丢弃这个未完成的连接，这段时间的长度我们称为SYN Timeout，一般来说这个时间是分钟的数量级(大约为30秒-2分钟);

　　一个用户出现异常导致服务器的一个线程等待1分钟并不是什么很大的问题，但如果有一个恶意的攻击者大量模拟这种情况，服务器端将为了维护一个非常大的半连接列表而消耗非常多的资源----数以万计的半连接，即使是简单的保存并遍历也会消耗非常多的CPU时间和内存，何况还要不断对这个列表中的IP进行SYN+ACK的重试。

　　实际上如果服务器的TCP/IP栈不够强大，最后的结果往往是堆栈溢出崩溃---即使服务器端的系统足够强大，服务器端也将忙于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求(毕竟客户端的正常请求比率非常之小)，此时从正常客户的角度看来，服务器失去响应，这种情况我们称做：服务器端受到了SYN Flood攻击(SYN洪水攻击)。

　　下面是我在实验室中模拟的一次Syn Flood攻击的实际过程

　　这一个局域网环境，只有一台攻击机(PIII667/128/mandrake)，被攻击的是一台Solaris 8.0 (spark)的主机，网络设备是Cisco的百兆交换机。这是在攻击并未进行之前，在Solaris上进行snoop的记录，snoop与tcpdump等网络监听工具一样，也是一个很好的网络抓包与分析的工具。可以看到攻击之前，目标主机上接到的基本上都是一些普通的网络包。 …

　　？ -> (broadcast)　ETHER Type=886F (Unknown)， size = 1510 bytes

　　？ -> (broadcast)　ETHER Type=886F (Unknown)， size = 1510 bytes

　　？ -> (multicast)　ETHER Type=0000 (LLC/802.3)， size = 52 bytes

　　？ -> (broadcast)　ETHER Type=886F (Unknown)， size = 1510 bytes

　　192.168.0.66 -> 192.168.0.255 NBT Datagram Service Type=17 Source=GU[0]

　　192.168.0.210 -> 192.168.0.255 NBT Datagram Service Type=17 Source=ROOTDC[20]

　　192.168.0.247 -> 192.168.0.255 NBT Datagram Service Type=17 Source=TSC[0]

　　？ -> (broadcast)　ETHER Type=886F (Unknown)， size = 1510 bytes

　　192.168.0.200 -> (broadcast)　ARP C Who is 192.168.0.102， 192.168.0.102 ？

　　？ -> (broadcast)　ETHER Type=886F (Unknown)， size = 1510 bytes

　　？ -> (broadcast)　ETHER Type=886F (Unknown)， size = 1510 bytes

　　192.168.0.66 -> 192.168.0.255 NBT Datagram Service Type=17 Source=GU[0]

　　192.168.0.66 -> 192.168.0.255 NBT Datagram Service Type=17 Source=GU[0]

　　192.168.0.210 -> 192.168.0.255 NBT Datagram Service Type=17 Source=ROOTDC[20]

　　？ -> (multicast)　ETHER Type=0000 (LLC/802.3)， size = 52 bytes

　　？ -> (broadcast)　ETHER Type=886F (Unknown)， size = 1510 bytes

　　？ -> (broadcast)　ETHER Type=886F (Unknown)， size = 1510 bytes

　　…

　　…

　　接着，攻击机开始发包，DDoS开始了…，突然间sun主机上的snoop窗口开始飞速地翻屏，显示出接到数量巨大的Syn请求。这时的屏幕就好象是时速300公里的列车上的一扇车窗。这是在Syn Flood攻击时的snoop输出结果： …

　　127.0.0.178 -> lab183.lab.net AUTH C port=1352

　　127.0.0.178 -> lab183.lab.net TCP D=114 S=1352 Syn Seq=674711609 Len=0 Win=65535

　　127.0.0.178 -> lab183.lab.net TCP D=115 S=1352 Syn Seq=674711609 Len=0 Win=65535

　　127.0.0.178 -> lab183.lab.net UUCP-PATH C port=1352

　　127.0.0.178 -> lab183.lab.net TCP D=118 S=1352 Syn Seq=674711609 Len=0 Win=65535

　　127.0.0.178 -> lab183.lab.net NNTP C port=1352

　　127.0.0.178 -> lab183.lab.net TCP D=121 S=1352 Syn Seq=674711609 Len=0 Win=65535

　　127.0.0.178 -> lab183.lab.net TCP D=122 S=1352 Syn Seq=674711609 Len=0 Win=65535

　　127.0.0.178 -> lab183.lab.net TCP D=124 S=1352 Syn Seq=674711609 Len=0 Win=65535

　　127.0.0.178 -> lab183.lab.net TCP D=125 S=1352 Syn Seq=674711609 Len=0 Win=65535

　　127.0.0.178 -> lab183.lab.net TCP D=126 S=1352 Syn Seq=674711609 Len=0 Win=65535

　　127.0.0.178 -> lab183.lab.net TCP D=128 S=1352 Syn Seq=674711609 Len=0 Win=65535

　　127.0.0.178 -> lab183.lab.net TCP D=130 S=1352 Syn Seq=674711609 Len=0 Win=65535

　　127.0.0.178 -> lab183.lab.net TCP D=131 S=1352 Syn Seq=674711609 Len=0 Win=65535

　　127.0.0.178 -> lab183.lab.net TCP D=133 S=1352 Syn Seq=674711609 Len=0 Win=65535

　　127.0.0.178 -> lab183.lab.net TCP D=135 S=1352 Syn Seq=674711609 Len=0 Win=65535

　　…

　　…

　　这时候内容完全不同了，再也收不到刚才那些正常的网络包，只有DDoS包。大家注意一下，这里所有的Syn Flood攻击包的源地址都是伪造的，给追查工作带来很大困难。这时在被攻击主机上积累了多少Syn的半连接呢？我们用netstat来看一下：

　　# netstat -an | grep SYN

　　…

　　…

　　192.168.0.183.9　127.0.0.79.1801　0　0 24656　0 SYN_RCVD

　　192.168.0.183.13 127.0.0.79.1801　0　0 24656　0 SYN_RCVD

　　192.168.0.183.19 127.0.0.79.1801　0　0 24656　0 SYN_RCVD

　　192.168.0.183.21 127.0.0.79.1801　0　0 24656　0 SYN_RCVD

　　192.168.0.183.22 127.0.0.79.1801　0　0 24656　0 SYN_RCVD

　　192.168.0.183.23 127.0.0.79.1801　0　0 24656　0 SYN_RCVD

　　192.168.0.183.25 127.0.0.79.1801　0　0 24656　0 SYN_RCVD

　　192.168.0.183.37 127.0.0.79.1801　0　0 24656　0 SYN_RCVD

　　192.168.0.183.53 127.0.0.79.1801　0　0 24656　0 SYN_RCVD

　　…

　　…

　　其中SYN_RCVD表示当前未完成的TCP SYN队列，统计一下：

　　# netstat -an | grep SYN | wc -l

　　5273

　　# netstat -an | grep SYN | wc -l

　　5154

　　# netstat -an | grep SYN | wc -l

　　5267

　　…..

　　共有五千多个Syn的半连接存储在内存中。这时候被攻击机已经不能响应新的服务请求了，系统运行非常慢，也无法ping通。

　　上述的相关内容就是对对DDoS攻击实例之SYN Flood攻击的详细内容讲述的描述，希望会给你带来一些帮助在此方面。