- 注册
- 2002-10-12
- 消息
- 47,112
- 荣誉分数
- 2,376
- 声望点数
- 393
SYN－DI防御系统
目前，随着互联网技术的逐步成熟，网络技术逐步为广大IT爱好者所掌握。而一种最简单也是最有效的攻击方式：SYN Flood 攻击。
SYN Flood 攻击在最初出现的时候，当时大多数攻击者采用的是单机的攻击方式，由于当时的很多操作系统在TCP底层处理的疏忽，通常来说，一台10M带宽的机器可以轻松让一台100M带宽的服务器停止服务，更有某些操作系统脆弱的网络底层系统在这种攻击的情况下会出现蓝屏错误，导致整个系统底层崩溃。由于这种攻击模式利用了IPv4（也就是我们现在所使用的互联网TCP/IP协议）的漏洞，采用伪造的IP地址进行攻击，导致受攻击者无法追查攻击者的来源，受攻击者只能一味地出于被动抵御的状态。
当这种攻击方式出现一段时间后，各种操作系统逐步加强了自己的网络底层，并且针对SYN Flood攻击开发出相应的抵御系统，其中比较出色的有BSD操作系统的SYN Cache、Linux的SYN Cookie等，国内领先的防火墙厂家天网防火墙在1998年开发出可以为服务器提供SYN Flood防御的SYN网关。但是以上的防御方式都有一定的局限性，操作系统的防御只能针对自身的防御，而SYN Flood网关的方式实际上是把自己推到了受攻击的最前沿。
由于操作系统本身的网络数据处理限制，网关在处理整个网络出口数据上面的限制，虽然在SYN Flood攻击防御上有一定的成效，但是，SYN Flood防御已经由原来的单机攻击，转变为多台服务器攻击的方式，原因就是在2003年底的时候，有一个开发小组发布了他们的DDOS攻击套件，这个套件由一个服务器端和客户端组成。服务器端采用木马的方式，驻留在被入侵并控制的服务器里面，客户端可以直接向这些肉鸡（指被入侵并且安装了后门系统的服务器）发出指令，由肉鸡集体向攻击目标发动SYN Flood攻击。在2004年6月在广东263IDC中心的系统中记录的结果，一个被攻击的网站的攻击流量竟然达到每秒13万个数据包，流量接近100M每秒。
在这种分布式的SYN Flood攻击模式下，不要说一般的服务器，就连某些效率稍差一点的三层交换机都无法正常工作，在测试的数据中，某国际著名品牌价值100多万￥的三层交换机在处理这些攻击数据的时候，出现30~40％左右的丢包率。
在实验室测试的数据我们可以看到，当使用SYN发包工具向调整过系统内核，并且设置了SYN Flood防御的Linux操作系统以及FreeBSD系统发包时，当SYN包流量达到50M左右的时候，Linux操作系统的CPU负载已经超过95%，并且出现60%左右的丢包，FreeBSD系统出现40%左右的丢包；当SYN包达到70M的时候，Linux操作系统已经完全对网络数据不做响应，FreeBSD操作系统的丢包率达到80%。
而后，把新的SYN-DI设备接入到网络中，并且设置启用SYN-DI防御系统，在负责发包的设备将SYN包流量设置到无限制时候，网络SYN流量接近100M，我们在SYN-DI设备上面观察，虽然设备的CPU负载高达90％，但是，在SYN-DI设备后面的两台服务器没有出现任何丢包，所有的网络应用功能正常服务。
但是由于这种新型的SYN-DI防御系统设计极为复杂，在进行防御时必须针对各个运营服务商所提供的服务类型进行策略调整，目前SYN－DI防御系统还是采用定制的方式，也就是无法将防御系统彻底产品化，只能由熟悉SYN-DI的技术工程师根据网络应用的情况以及模式进行定制，因此，目前的方案实施成本还是比较高的。
同时，SYN-DI系统在服务应用上也有一点的局限性，目前国内提供公开服务的网站里面有部分是无法采用SYN-DI方式进行防御的。
目前，随着互联网技术的逐步成熟，网络技术逐步为广大IT爱好者所掌握。而一种最简单也是最有效的攻击方式：SYN Flood 攻击。
SYN Flood 攻击在最初出现的时候，当时大多数攻击者采用的是单机的攻击方式，由于当时的很多操作系统在TCP底层处理的疏忽，通常来说，一台10M带宽的机器可以轻松让一台100M带宽的服务器停止服务，更有某些操作系统脆弱的网络底层系统在这种攻击的情况下会出现蓝屏错误，导致整个系统底层崩溃。由于这种攻击模式利用了IPv4（也就是我们现在所使用的互联网TCP/IP协议）的漏洞，采用伪造的IP地址进行攻击，导致受攻击者无法追查攻击者的来源，受攻击者只能一味地出于被动抵御的状态。
当这种攻击方式出现一段时间后，各种操作系统逐步加强了自己的网络底层，并且针对SYN Flood攻击开发出相应的抵御系统，其中比较出色的有BSD操作系统的SYN Cache、Linux的SYN Cookie等，国内领先的防火墙厂家天网防火墙在1998年开发出可以为服务器提供SYN Flood防御的SYN网关。但是以上的防御方式都有一定的局限性，操作系统的防御只能针对自身的防御，而SYN Flood网关的方式实际上是把自己推到了受攻击的最前沿。
由于操作系统本身的网络数据处理限制，网关在处理整个网络出口数据上面的限制，虽然在SYN Flood攻击防御上有一定的成效，但是，SYN Flood防御已经由原来的单机攻击，转变为多台服务器攻击的方式，原因就是在2003年底的时候，有一个开发小组发布了他们的DDOS攻击套件，这个套件由一个服务器端和客户端组成。服务器端采用木马的方式，驻留在被入侵并控制的服务器里面，客户端可以直接向这些肉鸡（指被入侵并且安装了后门系统的服务器）发出指令，由肉鸡集体向攻击目标发动SYN Flood攻击。在2004年6月在广东263IDC中心的系统中记录的结果，一个被攻击的网站的攻击流量竟然达到每秒13万个数据包，流量接近100M每秒。
在这种分布式的SYN Flood攻击模式下，不要说一般的服务器，就连某些效率稍差一点的三层交换机都无法正常工作，在测试的数据中，某国际著名品牌价值100多万￥的三层交换机在处理这些攻击数据的时候，出现30~40％左右的丢包率。
在实验室测试的数据我们可以看到，当使用SYN发包工具向调整过系统内核，并且设置了SYN Flood防御的Linux操作系统以及FreeBSD系统发包时，当SYN包流量达到50M左右的时候，Linux操作系统的CPU负载已经超过95%，并且出现60%左右的丢包，FreeBSD系统出现40%左右的丢包；当SYN包达到70M的时候，Linux操作系统已经完全对网络数据不做响应，FreeBSD操作系统的丢包率达到80%。
而后，把新的SYN-DI设备接入到网络中，并且设置启用SYN-DI防御系统，在负责发包的设备将SYN包流量设置到无限制时候，网络SYN流量接近100M，我们在SYN-DI设备上面观察，虽然设备的CPU负载高达90％，但是，在SYN-DI设备后面的两台服务器没有出现任何丢包，所有的网络应用功能正常服务。
但是由于这种新型的SYN-DI防御系统设计极为复杂，在进行防御时必须针对各个运营服务商所提供的服务类型进行策略调整，目前SYN－DI防御系统还是采用定制的方式，也就是无法将防御系统彻底产品化，只能由熟悉SYN-DI的技术工程师根据网络应用的情况以及模式进行定制，因此，目前的方案实施成本还是比较高的。
同时，SYN-DI系统在服务应用上也有一点的局限性，目前国内提供公开服务的网站里面有部分是无法采用SYN-DI方式进行防御的。
