我写的高性能,简化的SYNCOOKIE实现

Au_Hank

那是因为syn cookie想不保存tcp syn这个半连接状态,从而抵抗DOS攻击, 这样当然就无法记录TCP的选项了.即便如此它还是想通过编码来记录一些很重要的TCP的选项. 我觉得它尽力了..

btw, 我很想知道我的代码到底有没有发挥很大的作用? 有没有人做了测试,能否告诉我结果呢?
目前只有一个德国的告诉我说负载确实下降了一些...

谢谢了

[ 本帖最后由 Au_Hank 于 2008-1-13 16:39 编辑 ]

Au_Hank

原帖由 CUDev 于 2008-1-12 13:13 发表
这些都是SYN Cookie的缺点吧。
TCP选项在tcp_v4_conn_request中，报存到request_sock和inet_request_sock的相应字段中，但是SYN Cookie在tcp_v4_conn_request中，把request_sock释放掉了。
在tcp_v4_hnd_req中 ...

1: 原来的syn cookie没有完全忽略tcp options

2: 密码更新前没有收到ack的合法连接被丢弃(client会傻乎乎的以为连接成功了   )
----原来的syn cookie没有这个问题

3: 完全随即产生isn(cookie),没有遵循RFC的定义产生isn.
----原来的syn cookie应该还是遵循RFC的定义产生isn的

platinum

Au_Hank 兄什么时候写一个 syn_proxy 吧

Au_Hank

原帖由 platinum 于 2008-1-13 22:17 发表
Au_Hank 兄什么时候写一个 syn_proxy 吧

这个难度估计可大了,偶还是躲吧

grayblaze

我以前做过一点关于防止ddos攻击方面的一些研究，以下是些心得
1.我觉得把防止syncookie这部分放在netfileter之后肯定是不合理的，这部分应该放得越靠前越好，最好一收到报文就进行处理。
2.syncookie最大的消耗应该是怎么分辨哪些是正常的报文，哪些是攻击报文，syncookie可以分辨这点，但是怎么记录这些信息，以后再查找这些信息很耗cpu，这个是最难的一点。
3.光syncookie防止攻击效果还不是最佳，可以结合其他手段综合应用
4.synvookie平时不需要启动，只有在检测到有攻击的时候才需要启动

Godbach

在我1.7G P4的笔记本跑的VMWARE上做算法测试,每秒能产生1000万个cookie...

在1000M网上,最多每秒也就不到200万个syn连接, 我觉得我这个简化的算法

几年前的帖子了。

不过这里很想问一下，LZ测试算法的时候是在内核态测试的，还是用户态。具体的测试方法是什么？

qtdszws

这个算法根本就不能对抗syn flood,计算函数是双向的，new_syncookie_secret能反推出来