SYN 网络攻击原理.docVIP

TCP握手协议 第一次握手：客户端（作为源主机）通过向服务器（作为目的主机）发送TCP连接请求（又称SYN段），其中标志SYN=1,ACK=0；序列号为客户端初始序列号（简称ISN）；目的端口号为所请求的服务对应的端口；还包括最大段长度（MSS）选项。这个SYN段不携带任何数据，但是它消耗一个序列号。这一步客户端执行主动打开。 第二次握手：服务器在指定的端口等待连接，收到TCP连接请求后，将回应一个TCP连接应答（又称SYN/ACK段），其中标志SYN=1，ACK=1；序列号为服务器初始序列号；确认号为客户端初始序列号加1；目的端口号为客户端的源端口号。这个SYN/ACK段不携带数据，但消耗一个序列号。这一步服务器执行被动打开。 第三次握手：客户端再向服务器发送一个TCP连接确认报文（又称ACK段），其中标志SYN=0，ACK=1；序列号为客户端初始序列号加1；确认号为服务器的初始序列号加1。一般来说，这个ACK段不携带数据，因而不消耗序列号。 经过三次握手后，TCP连接正式建立。双方都置ACK标志，交换并确认了对方的初始序列号，可以通过连接互相传输数据。 SYN攻击原理 SYN Flood攻击属于DOS攻击的一种，它利用TCP协议缺陷，发送大量伪造的TCP连接请求，从而使得被攻击方资源耗尽(CPU满负荷或内存不足)，最终导致系统或服务器宕机。SYN Flood攻击正是利用了TCP连接的 三次握手，假设一个用户向服务器发送了SYN报文后突然死机或掉线，那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的(第 三次握手无法完成)，这种情况下 服务器端一般会重试(再次发送SYN+ACK给客户端)并等待一段时间后丢弃这个未完成的连接，这段时间的长度我们称为SYN Timeout，一般来说这个时间是分钟的数量级(大约为30秒-2分钟)；一个用户出现异常导致服务器的一个线程等待1分钟并不会对 服务器端造成什么大的影响，但如果有大量的等待丢失的情况发生，服务器端将为了维护一个非常大的半连接请求而消耗非常多的资源。我们可以想象大量的保存并遍历也会消耗非常多的 CPU时间和内存，再加上服务器端不断对列表中的IP进行SYN+ACK的重试，服务器的负载将会变得非常巨大。如果服务器的 TCP/IP栈不够强大，最后的结果往往是 堆栈溢出崩溃。相对于攻击数据流，正常的用户请求就显得十分渺小，服务器疲于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求，此时从正常客户会表现为打开页面缓慢或服务器无响应，这种情况就是我们常说的服务器端SYN Flood攻击(SYN洪水攻击)。 配合IP欺骗，SYN攻击能达到很好的效果，通常，客户端在短时间内伪造大量不存在的IP地址，向服务器不断地发送syn包，服务器回复确认包，并等待客户的确认，由于源地址是不存在的，服务器需要不断的重发直至超时，这些伪造的SYN包将长时间占用未连接队列，正常的SYN请求被丢弃，目标系统运行缓慢，严重者引起网络堵塞甚至系统瘫痪。 从防御角度来讲，存在几种的解决方法： 第一种是缩短SYN Timeout时间，由于SYN Flood攻击的效果取决于服务器上保持的SYN半连接数，这个值= SYN攻击的频度 x SYN Timeout，所以通过缩短从接收到SYN报文到确定这个报文无效并丢弃改连接的时间，例如设置为20秒以下，可以成倍的降低服务器的负荷。但过低的SYN Timeout设置可能会影响客户的正常访问。　　第二种方法是设置SYN Cookie，就是给每一个请求连接的IP地址分配一个Cookie，如果短时间内连续受到某个IP的重复SYN报文，就认定是受到了攻击，并记录地址信息，以后从这个IP地址来的包会被一概丢弃。这样做的结果也可能会影响到正常用户的访问。　　上述的两种方法只能对付比较原始的SYN Flood攻击，缩短SYN Timeout时间仅在对方攻击频度不高的情况下生效，SYN Cookie更依赖于对方使用真实的IP地址，如果攻击者以数万/秒的速度发送SYN报文，同时利用SOCK_RAW随机改写IP报文中的源地址，以上的方法将毫无用武之地。 一些TCP/IP栈的实现只能等待从有限数量的计算机发来的ACK消息，因为他们只有有限的内存缓冲区用于创建连接，如果这一缓冲区充满了虚假连接的初始信息，该服务器就会对接下来的连接停止响应，直到缓冲区里的连接企图超时。在一些创建连接不受限制的实现里，SYN洪水具有类似的影响。防御：在防火墙上过滤来自同一主机的后续连接。未来的SYN洪水令人担忧，由于释放洪水的并不寻求响应，所以无法从一个简单高容量的传输中鉴别出来。 本文章的目是介绍使用python构造packet的方法。使用ra