本人着手写一个syn proxy有兴趣的朋友欢迎加入

zjzf_1

本人着手写一个syn proxy有兴趣的朋友欢迎加入
我现在以freebsd为基础 基于ethernet bridge 实现一个syn proxy 以缓解syn攻击
有兴趣的朋友 我们可以共同研究

QQ:17405718

zjzf_1

三次握手
         tcp tree-way handshake
client-----1------->;server
               
client<----2--------server
              
client------3------>;server


         use tcp syn proxy
client-------1---->;syn proxy- - - - - server
         
client<-----2-----syn proxy- - - - - -server
                                       
client-------3--->;syn proxy---1---->;server
                                          
client- - - - - - - -syn proxy<---2-----server
                                          
client- - - - - - - - syn proxy----3---->;server

zjzf_1

因为我是在一个设备上实现的  不用考虑通用性  所以我不使用 现成的接口
为了更高的性能 我可能会直接更改 底层的结构
如果使用现成的接口我会选择ipf

zjzf_1

mirnshi      ........................

zjzf_1

兄弟们 有人有兴趣加入吗

zjzf_1

顺便给大家一个解决syn flood的窍门!
最高效的防护办法 就是过滤
你能把非正常连接过滤掉 这是最理想的办法
有人感觉我是在胡扯  因为制作一个完全符合syn请求规范的包 过滤肯定是行不通的

但是在我现在网络中流行的syn flood攻击软件发出的包普遍有一定的特征
红客联盟的作品HGOD算是 威力比较大使用率比较高的一个攻击软件
但他发出的第一次握手sequence number普遍小于65535也就是一个无符号整形16位

大家知道sequence number是一个32位的整数  攻击软件一般生成一个随机数作为ISN(初始序列号)  生成一个32位了随机数显然要比生成一个16位的耗时  我想HGOD应该是出于性能上的考虑 只生成一个16位的随机数

还有一些攻击软件使用的是大于65535的ISN 但是他们往往使用一个固定的高16位和一个随机的低16位来保证效率
也有一些攻击软件使用累加的办法生成ISN

按常规办法生成ISN或者一个随机的32位ISN肯定会较低攻击软件的威力
所以大多数攻击软件生成的ISN都有一定的规律

观察每个供给的包 你会发现这样那样的规律 那些混蛋为了追求性能 肯定要损失一些东西

以上是小弟的愚见  希望能给大家一些提示

下面我提出一个防火墙设计的思路 意在抛砖 没想过能捡到块玉
我有一个想法就是 过滤技术和syn proxy技术并用
在过滤无法抵挡的情况下才使用syn proxy
也就是 防火墙使用 一定的监测机制 如果能探测到攻击的规律 那么使用过滤机制   在不得已的情况下使用syn proxy

zjzf_1

[quote]原帖由 "A.com"]我认为技术的关键在于没有第3次握手的连接能不能及时清理。如果不能及时释放这些连接占用的空间，但还是能把这个代理给发死的阿。[/quote 发表：



按我的思虑不会遇到这个问题   我所说这个syn proxy 并不是传统意义上的tcp proxy  而是一个以太网桥  但是三次握手 要经过他 代理

zjzf_1

spacewalker      兄台想必 没看过syn cookies

zjzf_1

就需要用合理的数据结构和算法来解决这个问题