TCP SYN Flood检测与防范及防御方法

　　现在的攻击者,无所不在了.对于一些攻击手法,很多高手也都是看在眼里而没什么实质性防范措施.除了改端口,换IP,弄域名..还能做什么? 本篇文章介绍了TCP SYN Flood攻击的原理机制/检测与防范及防御方法,希望能给大伙一个思路.

　　TCP SYN Flood攻击的机制

　　客户端通过发送在TCP报头中SYN标志置位的数据分段到服务 端来请求建立连接。通常情况下，服务端会按照IP报头中的来源地址来返回SYN/ACK置位的数据包给客户端，客户端再返回ACK到服务端来完成一个完整的连接(Figure-1)。

　　在攻击发生时，客户端的来源IP地址是经过伪造的(spoofed)，现行的IP路由机制仅检查目的IP地址并进行转发，该IP包到达目的主机后返回路径无法通过路由达到的，于是目的主机无法通过TCP三次握手建立连接。在此期间因为TCP缓存队列已经填满，而拒绝新的连接请求。目的主机一直尝试直至超时(大约75秒)。这就是该攻击类型的基本机制。

　　发动攻击的主机只要发送较少的，来源地址经过伪装而且无法通过路由达到的SYN连接请求至目标主机提供TCP服务的端口，将目的主机的TCP缓存队列填满，就可以实施一次成功的攻击。实际情况下，发动攻击时往往是持续且高速的。

　　如下所示，为SYN Flood攻击过程示意图

　　Figure-3 SYN Flood Attack

　　这里需要使用经过伪装且无法通过路由达到的来源IP地址，因为攻击者不希望有任何第三方主机可以收到来自目的系统返回的SYN/ACK，第三方主机会返回一个RST(主机无法判断该如何处理连接情况时，会通过RST重置连接)，从而妨碍攻击进行。如下图所示：

　　Figure-4 IP Spoofing

　　由此可以看到，这种攻击方式利用了现有TCP/IP协议本身的薄弱环节，而且攻击者可以通过IP伪装有效的隐蔽自己。但对于目的主机来说，由于无法判断攻击的真正来源。而不能采取有效的防御措施。

　　TCP SYN Flood检测与防范

　　一、分析

　　从上面的分析，可以看出TCP SYN Flood远程拒绝服务攻击具有以下特点：

　　针对TCP/IP协议的薄弱环节进行攻击;

　　发动攻击时，只要很少的数据流量就可以产生显著的效果;

　　攻击来源无法定位;

　　在服务端无法区分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/IP协议本身的薄弱环节，而且攻击者可以通过IP伪装有效的隐蔽自己。但对于目的主机来说，由于无法判断攻击的真正来源。而不能采取有效的防御措施。

　　TCP SYN Flood检测与防范

　　一、分析

　　从上面的分析，可以看出TCP SYN Flood远程拒绝服务攻击具有以下特点：

　　针对TCP/IP协议的薄弱环节进行攻击;

　　发动攻击时，只要很少的数据流量就可以产生显著的效果;

　　攻击来源无法定位;

　　在服务端无法区分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万以上的同时连接数的容量，为数据传输的高效和可靠提供了强有力地保障。