[欢迎进入讨论] 关于syn-proxy的一些问题

richardhesidu

原帖由 Godbach 于 2009-3-13 16:39 发表


呵呵，是啊。我就觉得按照我的想法，内核是需要维护一个比较大的表的。

那你现在说的这种透明方式在那个版本的内核支持啊。

它对SYN包也是要进行Cookie验证的吧。

如果纯粹为了解决syn flood的话，用linux+squid的效率还是没有syn-proxy高。
这里要维护的表，远没有维护一个socket的消耗高。

Godbach

原帖由 richardhesidu 于 2009-3-13 17:27 发表

如果纯粹为了解决syn flood的话，用linux+squid的效率还是没有syn-proxy高。
这里要维护的表，远没有维护一个socket的消耗高。

恩。这样都可以在内核态完成，不过可能需要hash表吧。

Godbach

原帖由 richardhesidu 于 2009-3-13 17:27 发表

如果纯粹为了解决syn flood的话，用linux+squid的效率还是没有syn-proxy高。
这里要维护的表，远没有维护一个socket的消耗高。

richardhesidu兄觉得如果实现这样一个syn-proxy，关键的步骤有哪些？

独孤九贱

原帖由 Godbach 于 2009-3-12 17:53 发表
Linux内核中提供了SYN Cookie的检验机制，用来防御SYN Flood攻击。因此，延伸出来的在SYN Cookie Firewall，用来验证SYN连接，并对通过验证报文进行转发。
具体的内容可以参考《SYN Cookie原理及其在Linux内核 ...

是的，这个差值必须要维护。如果你的状态跟踪就是借助于Linux的Netfiter的话，这个跟踪结构就变得很简单，直接在ip_conntrack中增加相应的成员字段值就可以了。

1. struct syn_cookie{
   
2.         __u32 cookie;
   
3.         __u32 seq;
   
4. };

复制代码

1. struct ip_conntrack
   
2. {
   
3.         ……
   
4.   
   
5.         /* tcp syn cookie */
   
6.         struct syn_cookie syncookie;
   
7. }

复制代码

[ 本帖最后由 独孤九贱 于 2009-3-16 10:34 编辑 ]

Godbach

多谢九贱兄的指导啊。确实可以在链接跟踪结构体中增加一些字段
如果利用的链接跟踪，是不是就不需要判断报文的一些特征了，比如s->c的报文是不是对上一次c->s的回复呢？

独孤九贱

是的，借助于conntrack，可以省很多很多的代码和时间，自己的要实现的话，其实就是实现它其中的一部份功能，核心部件是TCP的状态机的维护(偶承认，偶水平有限，当时看Netfilter的TCP状态机的实现都看了好几天，如果自己写的话——所以说“省很多的时间”)。
但是，问题在于：大家都知道conntrack的性能受到广泛批评，所以，要高性能的话，就自己搞吧，而且借助于Netfilter，涉及到跟Netfilter的各个子模块的交互，这需要对Netfilter的整个工作流程了然于胸，比如，欺骗Netfilter的状态检测等等。
另一个技术问题在于cookie的处理，这个内核有现成的了，调用API即可。
还有一个问题是自己截包、发包，这需要了解内核态网络层组包发送的API。
还有就是性能问题，因为如果真的发生syn flooding，pps是非常多的。
还有就是ack flooding问题。例如100Mb的syn流量，要构造cookie ack，又是100Mb的回应包，但是众所周知，其中有99%都是不用回应的——这个问题很头痛，可能需要一个数学统计学的模型，My god，以前跟我们上统计学的老师是一个双博士学位的老处女，我对她没有兴趣，所以没有认真听讲，后悔呀！如果你有好的解决方案，一起讨论一下。
还有其它一些技术问题，记不得了。

————
PS：我认为，我不让攻击包进入conntrack，在pre_routing之前全处理了，保证进入conntrack的，都是正常的包，就不存在性能方面的问题了吧？哈哈，主要是我比较懒，有现成的不用，我太对不起自己了。

Godbach

PS：我认为，我不让攻击包进入conntrack，在pre_routing之前全处理了，保证进入conntrack的，都是正常的包，就不存在性能方面的问题了吧？哈哈，主要是我比较懒，有现成的不用，我太对不起自己了。

这样的话，进入系统的都是正常的包，也就没有必要在做syn-proxy了吧

独孤九贱

顶楼上，我的意思是说，“在连接跟踪之外做syn cookie，这样，连接跟踪中保存的都是正常数据包的会话，因为数量相对少几个数量级（比起所有包都进来的话），性能问题相对而言，就不那么敏感了！”

Godbach

是的，借助于conntrack，可以省很多很多的代码和时间，自己的要实现的话，其实就是实现它其中的一部份功能，核心部件是TCP的状态机的维护(偶承认，偶水平有限，当时看Netfilter的TCP状态机的实现都看了好几天，如果自己写的话——所以说“省很多的时间”)。

九贱兄的意思是借助于conntrack，已经不用考虑报文发送方和接收方的状态验证了，已经在conntrack中tcp部分做了对应的验证？

比如，欺骗Netfilter的状态检测等等。

这个欺骗之前没听说过啊，九贱兄可否介绍一下。

还有就是性能问题，因为如果真的发生syn flooding，pps是非常多的。
还有就是ack flooding问题。例如100Mb的syn流量，要构造cookie ack，又是100Mb的回应包，但是众所周知，其中有99%都是不用回应的——这个问题很头痛，可能需要一个数学统计学的模型，My god，以前跟我们上统计学的老师是一个双博士学位的老处女，我对她没有兴趣，所以没有认真听讲，后悔呀！如果你有好的解决方案，一起讨论一下。

是啊，大量的ACK包，也是个问题。

Godbach

原帖由 独孤九贱 于 2009-3-16 11:12 发表
顶楼上，我的意思是说，“在连接跟踪之外做syn cookie，这样，连接跟踪中保存的都是正常数据包的会话，因为数量相对少几个数量级（比起所有包都进来的话），性能问题相对而言，就不那么敏感了！”

看来抗synflood和conntrack他俩之间的关系很紧密啊。要是想减轻conntrack的负载，就要在它之前做synflood的防御。如果向方便快捷的实现防御synflood，最好利用conntrack。 唉，矛盾啊