讨论一下如何防范SYN-FLOOD攻击的问题

platinum

原帖由 llzqq 于 2005-12-3 07:32 发表
我在100M局域网试验了一下，发现效果很不错，apache没有受到直接攻击，pf把syn 包截住了。

意思是服务器没有死机，没有出现高负载？
那服务还仍然能继续向别人提供吗？别人的 syn 还进的来吗？

No.9

原帖由 llzqq 于 2005-12-3 07:32 发表
昨天研究了一下（为此还装了一台openbsd-3.8）pf防火墙是怎样对付syn flooding的，实现语句如下：


pass in proto tcp from any to port 80 flags S/SA synproxy state


我在100M局域网试验了一下，发现效 ...

用FREEBSD6.0  PF虽然保护了服务器，但别的请求也进不来，而且速度非常慢，不知是不是兼容性的原因。

colddawn

又是讨论synflood，呵呵，搀一脚
确实现在的情况是想让谁死谁就得死，不过也不是全无办法，常用的办法前面几位也都谈到了，我说一下没谈到的。
synflood原理就是通过发送大量syn包给服务器导致服务器的半连接超出系统限制而达到拒绝服务的目的。
synflood本身也有区别，最原始的synflood都是使用攻击机器自身的ip进行攻击，所以从被攻击机器上看到有ip直接发送大量的包过来，直接封掉就能搞定攻击。但是改进以后的synflood可以通过raw socket构建自身的syyn包发送，包头信息的大部分字段都可以伪造甚至全随机，例如随机源ip，这样发送给目标机器的结果就是目标机器看到有无数ip地址在向自己发送syn请求。这造成了一种分布式攻击（ddos）的假象，实际上可能攻击的机器就那一台（dos），当然多台机器同时synflood达到真正意义的ddos也是绝对可行的，并且威力更大。


防御的方法就目前来说，最有效的还是synproxy的机制，也就是用防火墙代理实现syn连接，具体后述。

我在这里首先要单独拿出来说的是一些特殊案例，实际上这些案例也非常常见。
前面讲通过raw socket构建的包头可以绝大多数字段都可以自定义，实际上，除了目标ip和目标端口以外的所有tcp/ip包头字段都是可以按照自己要求订制的，但是目前现有的一些常用synflood工具并不一定都随机填充这些字段，可能是作者偷懒，也可能是为了节省cpu计算时间用来更快的产生syn包。例如前面有人提到的hgod这个东东，他就有一个非常显著的特征：ipid=256。按照tcp/ip实现，这个ipid字段应该是随机的，所以，我们就可以明显地把hgod发出的包与正常访问产生的包区分开，linux的iptables，freebsd的ipfw都可以针对ipid进行拒绝。这时我们就可以通过简单的退避手段（牺牲ipid=256的正常包）来保证绝大多数应用的正常。
不仅是hgod，还有很多知名工具或多或少的在发送的syn包中带有一定的特征，根据这些特征过滤掉攻击包，就能保证正常服务的运行，这种方法虽然有局限，但优点为没有任何状态检测机制，简单高效，基本上就是线路能承受多少流量就能防止多少流量的攻击，所以还是有其应用价值的。其实似乎现在国内也存在这种利用特征过滤原理的抗ddos产品，具体我就不多说了，有兴趣的自己tcpdump看看能不能找到攻击包特征。

另外值得讨论的就是synproxy/syncookie了，这也是目前证明比较有效的解决方法了，至于产品，绿盟就是最好的实现。
首先讲syncookie，这个可能不少人测试过了，原理现在网上的剖析文章也很多了，自己找，就不多说了，这种方法在攻击流量不大的情况下还是有非常不错的效果的，不过攻击流量一旦稍大，据我的经验，大于10Mbps的synflood，就基本上不起作用了，原因是syncookie的半连接队列也被充满了，这时可以通过调大队列长度的方法解决，参考net.ipv4.tcp_max_syn_backlog这个sysctl变量，默认1024，上限能调到多少我不知道，但是据我的经验，最好不要大于8192，再大的结果就是syncookie本身处理就会把你的cpu资源跑光，一样ddos了。按照我的应用体验来看，好的硬件+好网卡+调优的网络参数+syncookie能在20Mbps的synflood下保证服务正常，如果谁能达到更强的攻击容纳能力请指教一下。

再说synproxy，这个能免费用的也就是pf上的那个了吧，不过pf的synproxy实现不能算好，其算法写的并不足够优化，主要弱点就是在连接状态检测这里，大量虚假ip的syn包会导致大量state产生，大量state的添加、查找、删除足以把pf拖垮，所以效果也不怎么样，按我的经验在30Mbps下基本也就挂了。

pf的synproxy不行并不代表synproxy这种实现思路不行，只要算法足够优化，synproxy的效率还是可以达到令人满意的效果的，目前对算法的改进基本在接受到syn包这个地方，并不用象pf的实现那样接受到syn包就建立状态，可以直接返回synack，并丢弃syn包，在受到正常的第3次握手synack包后建立状态机制，这样就能大大增大此算法的效率，当然细节方面肯定还有一些考虑，目前市场上的抗ddos产品应该在算法上都有独到之处，处理好了之后的设备能足以防到100Mbps以上的synflood，上1000M级别的设备估计就是硬件能力的比拼了，目前我还没接触到，也就无权评论了。

总之思路就这么多，好的方法基本也就这些，想从iptables限制syn速率，甚至拿出apache的ddos模块来的做法就有点头痛医脚了，说的不对的地方，请指正。

depthblue_xsc

SYN Flood攻击给互联网造成重大影响后，针对如何防御SYN Flood攻击出现了几种比较有效的技术。

2.1   SYN－cookie技术

　　一般情况下，当服务器收到一个TCP SYN报文后，马上为该连接请求分配缓冲区，然后返回一个SYN＋ACK报文，这时形成一个半连接。SYN Flood正是利用了这一点，发送大量的伪造源地址的SYN连接请求，而不完成连接。这样就大量的消耗的服务器的资源。

　　SYN－cookie技术针对标准TCP连接建立过程资源分配上的这一缺陷，改变了资源分配的策略。当服务器收到一个SYN报文后，不立即分配缓冲区，而是利用连接的信息生成一个cookie，并将这个cookie作为将要返回的SYN＋ACK报文的初始序列号。当客户端返回一个ACK报文时，根据包头信息计算cookie，与返回的确认序列号（初始的序列号＋1）的前24位进行对比，如果相同，则是一个正常连接，然后，分配资源，建立连接。

　　该技术的巧妙之点在于避免了在连接信息未完全到达前进行资源分配，使SYN Flood攻击的资源消耗失效。实现的关键之处在于cookie的计算。cookie的计算应该做到包含本次连接的状态信息，使攻击者不能伪造cookie。cookie的计算过程如下：

　　1）服务器收到一个SYN包后，计算一个消息摘要mac：
mac = MAC（A，k）；
MAC是密码学中的一个消息认证码函数，也就是满足某种安全性质的带密钥的hash函数，它能够提供cookie计算中需要的安全性。
A为客户和服务器双方的IP地址和端口号以及参数t的串联组合：
A = SOURCE_IP || SOURCE_PORT || DST_IP || DST_PORT || t
K为服务器独有的密钥；
时间参数t为32比特长的时间计数器，每64秒加1；

　　2）生成cookie：
cookie = mac（0:24）：表示取mac值的第0到24比特位；

　　3）设置将要返回的SYN+ACK报文的初始序列号，设置过程如下：
    i.              高24位用cookie代替；
   ii.              接下来的3比特位用客户要求的最大报文长度MMS代替；
   iii.              最后5比特位为t mod 32。
　　客户端收到来自服务器SYN+ACK报文后，返回一个ACK报文，这个ACK报文将带一个cookie（确认号为服务器发送过来的SYN ACK报文的初始序列号加1，所以不影响高24位），在服务器端重新计算cookie，与确认号的前24位比较，如果相同，则说明未被修改，连接合法，然后，服务器完成连接的建立过程。

　　SYN-cookie技术由于在连接建立过程中不需要在服务器端保存任何信息，实现了无状态的三次握手，从而有效的防御了SYN Flood攻击。但是该方法也存在一些弱点。由于cookie的计算只涉及了包头的部分信心，在连接建立过程中不在服务器端保存任何信息，所以失去了协议的许多功能，比如，超时重传。此外，由于计算cookie有一定的运算量，增加了连接建立的延迟时间，因此，SYN-cookie技术不能作为高性能服务器的防御手段。通常采用动态资源分配机制，当分配了一定的资源后再采用cookie技术，Linux就是这样实现的。还有一个问题是，当我们避免了SYN Flood攻击的同时，同时也提供了另一种拒绝服务攻击方式，攻击者发送大量的ACK报文，使服务器忙于计算验证。尽管如此，在预防SYN Flood攻击方面，SYN-cookie技术仍然是一种有效的技术。

2.2  地址状态监控的解决方法

　　地址状态监控的解决方法是利用监控工具对网络中的有关TCP连接的数据包进行监控，并对监听到的数据包进行处理。处理的主要依据是连接请求的源地址。

每个源地址都有一个状态与之对应，总共有四种状态：
初态：任何源地址刚开始的状态；
NEW状态：第一次出现或出现多次也不能断定存在的源地址的状态；
GOOD状态：断定存在的源地址所处的状态；
BAD状态：源地址不存在或不可达时所处的状态。
具体的动作和状态转换根据TCP头中的位码值决定：

　　1）监听到SYN包，如果源地址是第一次出现，则置该源地址的状态为NEW状态；如果是NEW状态或BAD状态；则将该包的RST位置1然后重新发出去，如果是GOOD状态不作任何处理。

　　2）监听到ACK或RST包，如果源地址的状态为NEW状态，则转为GOOD状态；如果是GOOD状态则不变；如果是BAD状态则转为NEW状态；如果是BAD状态则转为NEW状态。

　　3）监听到从服务器来的SYN ACK报文（目的地址为addr），表明服务器已经为从addr发来的连接请求建立了一个半连接，为防止建立的半连接过多，向服务器发送一个ACK包，建立连接，同时，开始计时，如果超时，还未收到ACK报文，证明addr不可达，如果此时addr的状态为GOOD则转为NEW状态；如果addr的状态为NEW状态则转为BAD状态；如果为addr的状态为BAD状态则不变。
状态的转换图如图3所示：

body.clientHeight)this.width=body.clientHeight" border=0>

初态
GOOD
NEW
BAD
ACK/RST
SYN
ACK/RST
  
ACK包确认超时
ACK/RST
  
ACK包确认超时

下面分析一下基于地址状态监控的方法如何能够防御SYN Flood攻击。


　　1）对于一个伪造源地址的SYN报文，若源地址第一次出现，则源地址的状态为NEW状态，当监听到服务器的SYN+ACK报文，表明服务器已经为该源地址的连接请求建立了半连接。此时，监控程序代源地址发送一个ACK报文完成连接。这样，半连接队列中的半连接数不是很多。计时器开始计时，由于源地址是伪造的，所以不会收到ACK报文，超时后，监控程序发送RST数据包，服务器释放该连接，该源地址的状态转为BAD状态。之后，对于每一个来自该源地址的SYN报文，监控程序都会主动发送一个RST报文。

　　2）对于一个合法的SYN报文，若源地址第一次出现，则源地址的状态为NEW状态，服务器响应请求，发送SYN＋ACK报文，监控程序发送ACK报文，连接建立完毕。之后，来自客户端的ACK很快会到达，该源地址的状态转为GOOD状态。服务器可以很好的处理重复到达的ACK包。
从以上分析可以看出，基于监控的方法可以很好的防御SYN Flood攻击，而不影响正常用户的连接。

　　3   小结

　　本文介绍了SYN Flood攻击的基本原理，然后详细描述了两种比较有效和方便实施的防御方法：SYN-cookie技术和基于监控的源地址状态技术。SYN-cookie技术实现了无状态的握手，避免了SYN Flood的资源消耗。基于监控的源地址状态技术能够对每一个连接服务器的IP地址的状态进行监控，主动采取措施避免SYN Flood攻击的影响。这两种技术是目前所有的防御SYN Flood攻击的最为成熟和可行的技术。

顽主

主要是办连接队列没有满，满了就会使用cookies， netfilter得状态检测机制和半廉洁队列还是算法不够优化！

ningyuzm

我想可不可以在syn cookie前置一个对syn包速率监视器啊，当进入的syn包的速率达到一个阀值时才真正启动这个syncookies代理，否则就按常规的状态检测流程进行包的过滤。这个好像和绿盟的黑洞的思路很类似。呵呵，我也是昨天才看有关这个内容的，一点愚见不要见笑。

ningyuzm

这样的话，当可能发生拒绝服务攻击了才启用代理，毕竟一般被攻击的时候也不多嘛，在syn包到达速率在容忍范围内进行正常的检测，这样应该可以保证正常情况下免除代理带来的时间资源的消耗了。

ningyuzm

顶一下

skipjack

:em11:

[ 本帖最后由 skipjack 于 2006-3-11 01:05 编辑 ]

bleach

原帖由 platinum 于 2004-5-30 15:52 发表
这个问题我也想到了
但是，一个单位的同事们会同时有20个人以上来访问吗？
何况HTTP协议不是一直ESTABLISHED的，读完网页就CLOSE
如果同一个IP有20个以上的ESTABLISHED，那肯定不正常
对吧：）

好像不成立 一个大网络若干个节点 把主页都设置为google或公司自己的竹叶 N多人同时开启IE 就把google给屏啦