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

ShadowStar

其实，我这边也要作这个东西。目前有2个方法。

我觉得SYN－FLOOD这个问题需要考虑如下几个关键点。
1. 效率，处理的速度（时间）。
2. 资源，防火墙的资源占用和被保护服务器的资源占用。

相比之下，代理握手的方式是效率相对较低、防火墙资源占用较大，服务器资源占用较小的。
尤其是保存syn包的方式，我觉得比较不可取。
我担心在大流量SYN－FLOOD时，防火墙被打死。

而另一种正好相对。

so, I'm in thinking.

Godbach

有效的抵御SYN flood，也许得多种方法结合着使用。
ShadowStar兄可否介绍一下另一种方法。。

ShadowStar

所谓的另一种方法，是针对于SYN-FLOOD的危害的采取的。

SYN－FLOOD主要危害是由于服务器的半开连接消耗较大资源导致的。

所以，我们可以把半开连接处理为完成连接。
也就是，放过SYN和SYN－ACK。伪造一个发送给服务器的ACK，并丢弃原始client的ACK。

这种方法会造成受到SYN－FLOOD攻击的服务器建立大量的连接。
但是防火墙本身的负担小了很多。

Godbach

所谓的另一种方法，是针对于SYN-FLOOD的危害的采取的。

SYN－FLOOD主要危害是由于服务器的半开连接消耗较大资源导致的。

所以，我们可以把半开连接处理为完成连接。
也就是，放过SYN和SYN－ACK。伪造一个发送给服务器的ACK，并丢弃原始client的ACK。

这种方法会造成受到SYN－FLOOD攻击的服务器建立大量的连接。
但是防火墙本身的负担小了很多。

ShadowStar兄的意思是让在server端建立起来连接。已建立的连接要比半连接节省资源。

但是本身使用fw保护server的，现在反而成了牺牲server保护fw，这样合适吗？

ShadowStar

原帖由 Godbach 于 2009-3-17 09:48 发表


ShadowStar兄的意思是让在server端建立起来连接。已建立的连接要比半连接节省资源。

但是本身使用fw保护server的，现在反而成了牺牲server保护fw，这样合适吗？

其实这个问题看怎么考虑了，因为这种处理方式已经处理了“SYN－FLOOD”攻击的主要危害。
而且，从防火墙和服务器整体考虑的话，这种方式的整体效率要好于代理方式，资源占用也不大。

并且可以通过对超时的syn连接（防火墙伪装完的）发送RST包，来降低服务器的连接数量。

可以保证正常的连接不受影响。

代理的方式在负载较大时，防火墙很容易成为网络的瓶颈，进而崩溃，影响的就不是一台服务器了。

Godbach

代理的方式在负载较大时，防火墙很容易成为网络的瓶颈，进而崩溃，影响的就不是一台服务器了。

恩，反正两个是串在一个绳子上的。

ShadowStar

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


恩，反正两个是串在一个绳子上的。

当然，这第二种方法与一般的用户理解还是有冲突的。

Godbach

不知ShadowStar兄是否已经采用了这种方式，效果怎么样啊？

另外，怎么确定这个SYN连接是攻击报文，而不是正常的请求呢? 因为你是拦截了server的SYN+ACK, 直接构造了ACK报文

Godbach

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


当然，这第二种方法与一般的用户理解还是有冲突的。

恩，我也觉得现在一般的用户可能还不容易接受这个方式。

ShadowStar

原帖由 Godbach 于 2009-3-17 10:16 发表
不知ShadowStar兄是否已经采用了这种方式，效果怎么样啊？

另外，怎么确定这个SYN连接是攻击报文，而不是正常的请求呢? 因为你是拦截了server的SYN+ACK, 直接构造了ACK报文

并不拦截SYN－ACK，而是在收到SYN－ACK时，直接伪造一个ACK发给服务器。
这样处理的成本小的多。

也不需要判断是否是攻击报文，只要在正常的SYN-RECV超时后发送RST就OK了；如果不超时，定时器刷新的话，自然也不会发送RST。

我还没有作，因为我手里还有别的在忙。另外，还没考虑好这样是否是最优的。