关于SYN FLOOD攻击原理的一点探讨

skipjack

原帖由 JohnBull 于 2003-2-26 20:17 发表
[quote="adrianke"]
防火墙一般是拦截syn网络包，完成路握手，仅将连接转发到真正的目的断。[quote]

这种方法就是所谓的“TCP代理”，实际上用SQUID做一个反向代理服务器也有相同的功能，但是仍然不 ...

TCP代理没有半连接状态!!!!
就算有,这个半连接也不会占用太多资源.100字节足够了,100M内存可以有100万的并发连接
我对防SYN FLOOD不感兴趣,我只是想知道对于动态协议,它怎么防?服务器不断的有新端口开放,防火墙通过状态检测可以发现这些动态端口,但防SYN FLOOD的设备一般不会进行状态检测,因为这样做效率太低了.并且现在的动态协议又很多.

killads

楼主的这篇文章用“专业”的语言把一个很简单的事情说得复杂化了

现在防御syn flood的方法 syn cookies ,流量控制这些真的很有效吗？答案是否定的。

ayazero

我怎么觉得说了一堆废话，真正的攻击来什么也没用

jackylau

老大：
2) 改变TCP参数，缩短TCP半连接的保留时间，也就是说对于最后一个ACK不要等待太久。
google似乎就是这么处理的。他的缺点就是重载时可能会影响连通率。

这个怎么改呀？能说下么？

ayazero

google: unix ip stack tuning

colddawn

syn代理确实可以做到没有半联结，原理简单说就是对方过来一个syn我就代替后面机器伪造个synack，同时设立个状态表项纪录这个ip-端口对，然后这个syn就直接丢。如果对方过来个synack，检查状态表里面有没有这个联结对，有的话说明对方确实是进行第三次握手，属于正常联结。这个时候再伪造这个联结对的syn发给后面机器，接受到后面机器的synack后再synack回去完成连接过程，这样以后基本就不用防火墙干预了。而如果是恶意的synflood的话，防火墙伪造出去的synack是不会有结果的。当然细节方面就没这么简单了，何时设立状态表项，检查seq等都是需要考虑的。

目前来说，针对synflood，synproxy确实是比较有效的广谱抗菌方法，当然能不能防也算是相对的，百兆以太网送进来了百兆的攻击，那你防火墙也没办法了，不过这也不是做防火墙的人该解决的问题了，所以对于目前防火墙厂商，也要理智对待，谁的算法好，谁的效果可能就好，不能说全部都是骗人的。

colddawn

不过synproxy确实是没办法分析动态协议的，使用synproxy很可能造成一个结果，就是telnet后面防护的机器，所有端口都是通的，因为防火墙不管你后面机器是否提供服务，对于所有的联结请求都先synack一下。

xiyang

原帖由 e4gle 于 2003-2-26 15:46 发表
都没用，所谓防火墙可以阻止synflood也是骗人的，最多做个类似syn cookie的东西，有的只是简单的处理，遇到大量的随机性强的syn洪水就挂了

防止synflood dos攻击是一个长期课题，据我所知目前效果最好的是绿盟 ...

绿盟的是无法防止游戏的cc，僵尸等攻击的
什么叫六次握手？：）还不是synproxy。

ipaddr

楼主说得很有道理。

技术手段，还是用tcp_syscookies，有效的。而且很明显。

skipjack

6次握手与3次握手是一样的,消耗的资源不比3次多.如果处理的好,会更节约资源.
我试过PIII 733 128M内存 两口82559的百兆网卡 标准的synproxy流程(见到syn包就回syn ack) 50M的syn流量可以防住(大概是74000pps).如果是千兆的环境,500M不敢说,400M我想应该是可以防住的(合700000pps).如果再用什么重传判断,随机丢包什么的偏门算法,效果会更好.
本人不认为有什么单向一次数据包判断技术,除非攻击者是傻子,用多播或广播做为TCP的源地址和目的地址