针对SYN Flood攻击，请提出一个检测攻击和防御攻击的方法，并阐述理由。
发布网友
发布时间：2022-04-14 23:26
共3个回答
热心网友
时间：2022-04-15 00:55
要明白这种攻击的基本原理，还是要从TCP连接建立的过程开始说起：
大家都知道，TCP与UDP不同，它是基于连接的，也就是说：为了在服务端和客户端之间传送TCP数据，必须先建立一个虚拟电路，也就是TCP连接，建立TCP连接的标准过程是这样的：
首先，请求端（客户端）发送一个包含SYN标志的TCP报文，SYN即同步（Synchronize），同步报文会指明客户端使用的端口以及TCP连接的初始序号；
第二步，服务器在收到客户端的SYN报文后，将返回一个SYN+ACK的报文，表示客户端的请求被接受，同时TCP序号被加一，ACK即确认（Acknowledgment）。
第三步，客户端也返回一个确认报文ACK给服务器端，同样TCP序列号被加一，到此一个TCP连接完成。
以上的连接过程在TCP协议中被称为三次握手（Three-way Handshake）。
问题就出在TCP连接的三次握手中，假设一个用户向服务器发送了SYN报文后突然死机或掉线，那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的（第三次握手无法完成），这种情况下服务器端一般会重试（再次发送SYN+ACK给客户端）并等待一段时间后丢弃这个未完成的连接，这段时间的长度我们称为SYN Timeout，一般来说这个时间是分钟的数量级（大约为30秒-2分钟）；一个用户出现异常导致服务器的一个线程等待1分钟并不是什么很大的问题，但如果有一个恶意的攻击者大量模拟这种情况，服务器端将为了维护一个非常大的半连接列表而消耗非常多的资源----数以万计的半连接，即使是简单的保存并遍历也会消耗非常多的CPU时间和内存，何况还要不断对这个列表中的IP进行SYN+ACK的重试。实际上如果服务器的TCP/IP栈不够强大，最后的结果往往是堆栈溢出崩溃---即使服务器端的系统足够强大，服务器端也将忙于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求（毕竟客户端的正常请求比率非常之小），此时从正常客户的角度看来，服务器失去响应，这种情况我们称作：服务器端受到了SYN Flood攻击（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报文中的源地址，以上的方法将毫无用武之地。
热心网友
时间：2022-04-15 02:13
发动攻击时，只要很少的数据流量就可以产生显著的效果；
攻击来源无法定位；
在服务端无法区分TCP连接请求是否合法。
二、系统检查
一般情况下，可以一些简单步骤进行检查，来判断系统是否正在遭受TCP SYN Flood攻击。
1、服务端无法提供正常的TCP服务。连接请求被拒绝或超时；
2、通过 netstat -an 命令检查系统，发现有大量的SYN_RECV连接状态。
三、防范
如何才能做到有效的防范呢?
1、 TCP Wrapper
使用TCP Wrapper(只有unix-like系统支持该功能，NT?可怜)可能在某些有限的场合下有用，比如服务端只处理有限来源IP的TCP连接请求，其它未指定来源的连接请求一概拒绝。这在一个需要面向公众提供服务的场合下是不适合的。而且攻击者可以通过IP伪装(IP Spoof)来直接攻击受TCP Wrapper保护的TCP服务，更甚者可以攻击者可以伪装成服务器本身的地址进行攻击。
2、增加TCP Backlog容量
增加TCP Backlog容量是一种治标不治本的做法。它一方面要占用更多的系统内存，另一方面延长了TCP处理缓存队列的时间。攻击者只要不停地的进行SYN Flood一样可以达到拒绝服务的目的。
3、 ISP接入
所有的ISP在边界处理进入的主干网络的IP数据包时检测其来源地址是否合法，如果非指定来源IP地址范围，可以认为是IP Spoofing行为并将之丢弃。 在实际环境中，应为涉及的范围太过广泛，该方案无法实施。这是一个社会问题而非技术问题。
TCP SYN Flood检测与防范 一、TCP连接监控(TCP Interception)
为了有效的防范TCP SYN Flood攻击，在保证通过慢速网络的用户可以正常建立到服务端的合法连接的同时，需要尽可能的减少服务端TCP Backlog的清空时间，大多数防火墙采用了TCP连接监控的工作模式。1.防火墙接到来自用户端Z的SYN连接请求，在本地建立面向该连接的监控表项；
2.防火墙将该连接请求之转发至服务端A；
3.服务端A相应该连接请求返回SYN/ACK，同时更新与该连接相关联的监控表项；
4.防火墙将该SYN/ACK转发至用户端Z；
5.防火墙发送ACK至服务端A，同时服务端A中TCP Backlog该连接的表项被移出；
6.这时，根据连接请求是否合法，可能有以下两种情况发生:
a.如果来自用户端Z的连接请求合法，防火墙将该ACK转发至服务端A，服务端A会忽略该ACK，因为一个完整的TCP连接已经建立；
b.如果来自用户端Z的连接请求非法(来源IP地址非法)，没有在规定的时间内收到返回的ACK，防火墙会发送RST至服务端A以拆除该连接。
7.开始TCP传输过程。
由此可以看出，该方法具有两个局限:
1.不论是否合法的连接请求都直接转发至服务端A，待判断为非法连接(无返回ACK)时才采取措施拆除连接，浪费服务端系统资源；
2.防火墙在本地建立表项以监控连接(一个类似TCP Backlog的表)，有可能被攻击者利用。
二、天网DoS防御网关
天网防火墙采用经过优化的TCP连接监控工作方式。该方式在处理TCP连接请求的时候，在确定连接请求是否合法以前，用户端Z与服务端A是隔断的。1.防火墙接到来自用户端Z的SYN连接请求；
2.防火墙返回一个经过特殊处理的SYN/ACK至客户端Z以验证连接的合法性；
3.这时，根据连接请求是否合法，可能有以下两种情况发生:
a．防火墙接收到来自客户端Z的ACK回应，该连接请求合法。转至第4步继续；
b．防火墙没有接收到来自客户端Z的ACK回应，该连接请求非法，不进行处理；
4.防火墙在本地建立面向该连接的监控表项，并发送与该连接请求相关联的SYN至服务端A；
5.防火墙接到来自服务端A的SYN/ACK回应；
6.防火墙返回ACK以建立一个完整的TCP连接；
7.防火墙发送ACK至客户端Z，提示可以开始TCP传输过程。
其中，在第2/3/4/7步过程中，防火墙内部进行了如下操作:
1.在第2步中，为了验证连接的合法性，防火墙返回的SYN/ACK是经过特殊处理的，并提示客户端Z暂时不要传送有效数据；
2.在第3步中，防火墙接收到来自客户端Z的ACK，检验其合法性。
3.在第4步中，防火墙在本地建立面向该连接的监控表项，同时发送与该连接相关的SYN至服务端A；
4.在第7步中，防火墙通过将TCP数据传输与监控表项进行比对，并调整序列号和窗口以使之匹配。开始TCP数据传输。
在这里，天网防火墙通过高效的算法（64K位的Hash）提供了超过30万以上的同时连接数的容量，为数据传输的高效和可靠提供了强有力地保障。
热心网友
时间：2022-04-15 03:48
