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

Au_Hank

原帖由 独孤九贱 于 2007-9-20 10:19 发表


等我来，这个讨论好像已经结束了……
Linux中的syn Cookie算法效率确实不咋地，偶试着优先它，不过失败了……要向楼主多学习呀！！

除了在实践中，除了cookie算法问题，更实际的问题还有两个，这里跟楼主交流一下：
1、回应的数据包太多，Linux的路由缓存是个很大的问题——无论设置大多的dst cache，在强大的攻击下面，都是很可笑的！！！而且设得越大，散列冲突越来越多，效率也会下降很快；
——我的解决方法：直接越过路由子系统，反弹数据包：从哪里来，就从哪个接口回去，[不过在网络拓扑稍复杂的地方，这招就不行了]

2、回应的Cookie越多，意味着双倍流量，本身机器接收处理这么大的的小包就是一个头痛的问题，现在还要*2，而且对上级网关也是一个沉重的负担——在实践中，就有很多上级网关被冲动的例子！
——我的方法是随机丢包，利用2/8原理，减少回应包数量[很多好人被错杀了呀！！

就象你说的那样, 问题还多呢,还远没有到解决问题的时候. 值得讨论的地方还很多...
我只是在产生和验证COOKIE方面做了一些优化. 我也不知道这个对整体的性能能有多大的贡献,所以需要朋友们帮忙测试一下.
象你提的问题(我记得前面也有朋友提到类似问题), 说明SYN FLOOD带来的压力是方方面面的,光从一个地方下工夫恐怕远远不够.

你提出的问题1,我觉得很不错,有效地简化了处理过程....(是否甚至可以更进一步, 简化整个TCPIP的处理流程呢? )
但是2 我觉得不太可取, 除非是没有办法的情况下

另外我有两个思路和大家分享或者说探讨一下:
1: 是否可以建立一种SERVER到FIREWALL的反馈, 使合法访问的IP不受到连接速度限制,但是对其他的SYN连接做速度限制. 这个应该是
非常有效和可行的.

2: 如果对网络(包括FIREWALL, SYN-PROXY)的压力过大的话, 是不是可以考虑将上行和下行的分开? 类似lvs里面的direct routing

zhonghua716

呵呵 学习了哦

独孤九贱

你提出的问题1,我觉得很不错,有效地简化了处理过程....(是否甚至可以更进一步, 简化整个TCPIP的处理流程呢?  )

本身就已经跳过了TCP/IP栈……

但是2 我觉得不太可取, 除非是没有办法的情况下
就是没有办法，头都想大了……

另外我有两个思路和大家分享或者说探讨一下:
1: 是否可以建立一种SERVER到FIREWALL的反馈, 使合法访问的IP不受到连接速度限制,但是对其他的SYN连接做速度限制. 这个应该是
非常有效和可行的.

呵呵，可以建立一个合法IP的缓存机制……至于合法IP，可以从Cookie的验证中得到，并且不光是cookie的验证，整个TCP的连接协议状态都要做认真的检测，否则很容易被攻击。

1. 2: 如果对网络(包括FIREWALL, SYN-PROXY)的压力过大的话, 是不是可以考虑将上行和下行的分开? 类似lvs里面的direct routing

复制代码

不懂你的上下行“分开”中的这个分开是什么意思？

在一个VIA2 + 128MB确SDRAM 的1G的CPU的机器上，我做了一个syncookie relay，把tcp服务器放在其后，可以实现30Mb的攻击流量的防御（此时可以访问其后的服务器，但本身的操作已经非常慢了），现在能优先的地方不多了，——驱动 & Cookie算法！

OsingWei

这都是高级的东东啊,我什么时候能达到这一步呢?

micenote

强人!
学习了!!!

zmhu

又看见高人了哈，关注中！！！！

colddawn

原帖由 独孤九贱 于 2007-9-20 22:06 发表
本身就已经跳过了TCP/IP栈……

但是2 我觉得不太可取, 除非是没有办法的情况下
就是没有办法，头都想大了……

呵呵，可以建立一个合法IP的缓存机制……至于合法IP，可以从Cookie的验证中得到，并且不光 ...

LZ首先从算法入手做优化应该是有最立竿见影效果的。
但同时你提到的这些问题也不能忽视。
本身syncookie是属于一个普适性广的方案，也就是那种虽然性能不怎么样，但以最大路化的方案来对待一切问题。
而具体到应用的时候效果就是小打小闹的synflood都可以解决，而有目的的集中性ddos就没戏了。
如果从增加其他机制的方面来考虑，则又必定影响其本身通用化的思想，而且越多的考虑反而会带来越多的问题，如以下问题：
为了保护上层服务把syncookie拿出来独立于协议栈外，甚至做到另外的网关或网桥防火墙机制中去--如果提前synack了，如何考虑并处理后端tcp选项和window等参数？
随机丢包保证不增加出站带宽压力--握手完成时间得不到保证，还可能增大connection track等其他上层机制的负担。
设立可以通过某种行为判断的正常IP或者非法IP的黑白名单--维护名单生存周期需要多少运算？怎样的状态检测才能满足？以及其实实际应用如果被发现有此机制更容易直接针对这个机制执行打击

等等等等的问题从设计时并不能完全考虑到，但一旦碰到就很头疼，所以无法在不违反RFC行为的前提下全部能实现，只有某种方案适用某种情况，而无所有情况都适用的方案，现实就是这么残酷。

不过说回来LZ这个算法可行性非常高，即使可能存在被逆向利用构造伪造ack的可能，也不失为有效的解决方案，对于使用者，能达到如此效果就已经很不错了，但对于借此卖产品的，只能说还需要更深一步的计划。

lizhaoboy

真的吗?我不信!

fuleru

强帖留名，也学习学习。

CUDev

这些都是SYN Cookie的缺点吧。
TCP选项在tcp_v4_conn_request中，报存到request_sock和inet_request_sock的相应字段中，但是SYN Cookie在tcp_v4_conn_request中，把request_sock释放掉了。
在tcp_v4_hnd_req中，调用cookie_v4_check填充一些默认值，但是这样改变了TCP协议，或者说是没有完全支持TCP协议。

关于TCP的选项字段的处理，感觉是SYN Cookie中做的不好的地方。