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

dreamice

原帖由 Godbach 于 2009-3-16 11:15 发表


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

synflood和syncookie机制是不是差不太多？

Godbach

原帖由 dreamice 于 2009-3-16 11:19 发表


synflood和syncookie机制是不是差不太多？

可以利用SYNcookie机制应对synflood攻击

独孤九贱

不矛盾的，在实现中，很容易解决这个问题，或者说，事实上，它根本不存在。

1、首先，在pre_routing挂一个Hook，它监听所有的tcp syn包(这里也可以做一些过滤，比如，只保护指定的目的地址等等，或者是做一个缓存，存下已验证正确的主机等等)。
2、伪造syn+ack，当然，是包含cookie的，因为这个回应的数量级非常之大，所以，效率很重要。
3、凡是收到ack，验证cookie，这里并不需要状态机。只要验证cookie就可以了，这是跟syn proxy最核心的区别了。
4、如果cookie验证不过，就不用多说了。如果过了，就要接下来伪装跟服务器端的三次握手了。这样的包才会被放进conntrack表，最多是需要做点小小的欺骗。
5、两端三次握手OK后，后续数据包都要更改序列号，就是你一开始提的问题，因为序列号保存在ip_conntrack，自己也不用维护状态机，很简单，直接更改，重新计算校验和就行了。

Godbach

1、首先，在pre_routing挂一个Hook，它监听所有的tcp syn包(这里也可以做一些过滤，比如，只保护指定的目的地址等等，或者是做一个缓存，存下已验证正确的主机等等)。
2、伪造syn+ack，当然，是包含cookie的，因为这个回应的数量级非常之大，所以，效率很重要。
3、凡是收到ack，验证cookie，这里并不需要状态机。只要验证cookie就可以了，这是跟syn proxy最核心的区别了。
4、如果cookie验证不过，就不用多说了。如果过了，就要接下来伪装跟服务器端的三次握手了。这样的包才会被放进conntrack表，最多是需要做点小小的欺骗。
5、两端三次握手OK后，后续数据包都要更改序列号，就是你一开始提的问题，因为序列号保存在ip_conntrack，自己也不用维护状态机，很简单，直接更改，重新计算校验和就行了。

多谢啊。九贱兄的这个方法确实很不错。

只是这里你在conntrack之前做了cookie验证，那么你通过什么方式把这个差值告诉conntrrack呢？

独孤九贱

你看我给你的数据结构应知道了。
通过了cookie验证，则ip_conntrack中的相应自定义字段记录cookie。而通过cookie处理的话，cookie一定是一个定值，否则为0。所以，如果cookie > 0，则应该处理seq，就这样简单噻。
实现这个框架其实不难，主要是cookie 的实现是现成的API,Netfilter的状态机也是现成的，内核截包、组包的API还是现成的。自己动手多试几回就整搞出来了，从Netfilter挂个Hook，自己动手截包伪装三次握手开始。我觉得关键还是要完善它比较困难一些，就是让它更快，更快…… 。

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

Godbach

原帖由 独孤九贱 于 2009-3-16 11:40 发表
你看我给你的数据结构应知道了。
通过了cookie验证，则ip_conntrack中的相应自定义字段记录cookie。而通过cookie处理的话，cookie一定是一个定值，否则为0。所以，如果cookie > 0，则应该处理seq，就这样简单噻 ...

那在syn cookie验证的过程中好像还得存储一下报文的相关信息吧。

richardhesidu

原帖由 Godbach 于 2009-3-16 12:44 发表


那在syn cookie验证的过程中好像还得存储一下报文的相关信息吧。

主要是在防火墙向server发送syn包以后，它需要知道去截获从server响应的怎么样的syn+ack包吧。
所以我觉得总得有个地方存储连接信息。

独孤九贱

楼上的，你让给服务器的syn请求穿过netfilter连接跟踪表（事实上，如何是使用netfilter的状态跟踪，而不是自己来实现，也应该这样做），这个信息不就有地方存储了吗？

dreamice

原帖由 独孤九贱 于 2009-3-16 13:38 发表
楼上的，你让给服务器的syn请求穿过netfilter连接跟踪表（事实上，如何是使用netfilter的状态跟踪，而不是自己来实现，也应该这样做），这个信息不就有地方存储了吗？

我比较赞同这种利用已有机制的实现方式，风险小，而且可行性要好一些。
本身netfilter的contrack机制就是比较好的。

richardhesidu

原帖由 独孤九贱 于 2009-3-16 13:38 发表
楼上的，你让给服务器的syn请求穿过netfilter连接跟踪表（事实上，如何是使用netfilter的状态跟踪，而不是自己来实现，也应该这样做），这个信息不就有地方存储了吗？

对哦。我对这个conntrack不熟悉。
多谢！