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

Godbach

Linux内核中提供了SYN Cookie的检验机制，用来防御SYN Flood攻击。因此，延伸出来的在SYN Cookie Firewall，用来验证SYN连接，并对通过验证报文进行转发。
具体的内容可以参考《SYN Cookie原理及其在Linux内核中的实现》
http://www.ibm.com/developerworks/cn/linux/l-syncookie/index.html

使用syn cookie检验机制的Firewall，实际上相当于一个syn proxy。它会代替server对client三次握手，对syn报文进行cookie验证，然后再将client初始的syn报文发给server，并做三次握手。这个过程中，很明显client记录的server的seq实际上firewal初始的seq。
如下图所示：


因此，Firewall就要负责这个序列号在client和server交互的报文之间进行转换（维护一个差值），直到这个连接结束。

这里的问题如下：

通常情况下，Firewall对于多个syn连接处理的时候，FW是不是就得维护多个差值。 这样的话是不是需要记录连接的五元组，并且维护一个hash表。这个hash表应该包含那些内容呢？

dreamice

如果是完全的拦截，其实对序列号不需要多做考虑

Godbach

原帖由 dreamice 于 2009-3-12 21:31 发表
如果是完全的拦截，其实对序列号不需要多做考虑

关键是防火墙做一下验证，正常的访问还得继续。不考虑序列号不行吧？

dreamice

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


关键是防火墙做一下验证，正常的访问还得继续。不考虑序列号不行吧？

关键是你拦截在什么地方，包能否走到tcp层？
一个syn包，是不会走到应用层的，只是在内核检查到有应用程序在监听这个端口，那么在tcp层就直接回ack＋syn包了，
所以，这个就看你在哪里拦截了，你若在ip层阻挡了，不让他上去，那考虑序列号也没什么意义，除非你在这个ip层模拟发ack。

Godbach

原帖由 dreamice 于 2009-3-12 22:23 发表


关键是你拦截在什么地方，包能否走到tcp层？
一个syn包，是不会走到应用层的，只是在内核检查到有应用程序在监听这个端口，那么在tcp层就直接回ack＋syn包了，
所以，这个就看你在哪里拦截了，你若在ip层 ...

dreamice兄可能没有理解那个附图的意思吧。你首先代替服务器发送了SYNcookie ，但是真正再把这个SYN发送到服务器，建立连接之后，从server发向client的报文的seq和client预期的是不一样的。

dreamice

看昏了，我以为是透明代理

Godbach

原帖由 dreamice 于 2009-3-12 22:47 发表
看昏了，我以为是透明代理

呵呵，有时间讨论一下这个转换以及实现啊。

dreamice

原帖由 Godbach 于 2009-3-12 22:59 发表


呵呵，有时间讨论一下这个转换以及实现啊。

现在内核支持透明代理，就不用考虑这些东东了

dreamice

不过我不太清楚这个应用，可能和我想的不一样

qtdszws

我想可以参考ftp的conntrack和nat实现