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

richardhesidu

我的一点思路：
In PRO Routing Hook
if(is syn from client)
{
   截获syn包，发送syn+ack
}
if(is ack from client)
{
  截获ack包，验证cookie，注册ip conntrack(其中有cookie值和syn)，向server发送syn包
}
if(is syn+ack from server)
{
  截获syn+ack包，发送ack包。更新差值
}

ShadowStar

原帖由 richardhesidu 于 2009-3-17 10:31 发表
我的一点思路：
In PRO Routing Hook
if(is syn from client)
{
   截获syn包，发送syn+ack
}
if(is ack from client)
{
  截获ack包，验证cookie，注册ip conntrack(其中有cookie值和syn)，向server发送syn包
}
if(is syn+ack from server)
{
  截获syn+ack包，发送ack包。更新差值
}

这个思路有一些问题。
第一，cookie的计算，又添加了2次的csum计算。加上cookie本身就等于3次。
第二，向server发送的syn包，是保存，还是不保存重新生成？一个是内存的消耗，另一个是时间的消耗。
第三，后续所有的连接数据包都要重新计算2个csum。

总体说来，CPU的处理量太大了。

richardhesidu

不知道Godbach兄有没有考虑伪造包丢失的问题。
如果由于网路问题，client或sever没有收到，是否得考虑重发。給client发的syn+ack包可能没有问题，因为client会继续发送syn包。而由fw伪造的发给server的syn包和ack包，似乎需要考虑这个问题。

dreamice

我觉得，用透明代理的话，就没必要搞那么复杂的考虑了

ShadowStar

原帖由 dreamice 于 2009-3-17 10:41 发表
我觉得，用透明代理的话，就没必要搞那么复杂的考虑了

透明代理的问题如下：
1。防火墙本身为网络瓶颈。在大流量攻击下是否能抗得住？
2。代理本身屏蔽了原始client的IP，导致服务器本身没有真实的访问记录。

Godbach

第三，后续所有的连接数据包都要重新计算2个csum。

因为后序报文要么修改ACK，要么修改SEQ，重新计算的时候可以考虑用增量计算校验和的方式，计算耗费的资源可以忽略不计。

ShadowStar

原帖由 Godbach 于 2009-3-17 10:51 发表

因为后序报文要么修改ACK，要么修改SEQ，重新计算的时候可以考虑用增量计算校验和的方式，计算耗费的资源可以忽略不计。

还有IP的序列号呢。

Godbach

原帖由 ShadowStar 于 2009-3-17 10:51 发表


还有IP的序列号呢。

一次是fw发送的SYN+ACK，一次是sever发送的SYN+ACK。这两个报文处理在seq上不一样之外，IP的序号也不一样吗？
这两个SYN+ACK应该是对同一个SYN包相应的

ShadowStar

原帖由 Godbach 于 2009-3-17 10:53 发表


一次是fw发送的SYN+ACK，一次是sever发送的SYN+ACK。这两个报文处理在seq上不一样之外，IP的序号也不一样吗？
这两个SYN+ACK应该是对同一个SYN包相应的

当然不一样了。你截获了client的SYN，怎么能知道server的IP序列号呢？

richardhesidu

还有就是资源回收的问题了。比如ip conntrack的注销。