绿盟黑洞: X86架构,Linux内核与自主专利的抗syn-flood算法。对抗单一类型的syn,udp,icmp dos效果很好,但是当多种混合时效果就略差。优点是更新快,技术支持比较好,在100M环境下对syn-flood有绝对优势。 缺点是文档和信息缺乏,同时工作(软
硬件两方面)不是很稳定。
一己拙见: 作为应急响应时备用。
Radware fireproof: ASIC/NP架构,SynApps技术,主要是基于签名的4-7层过滤算法与补充的syn-cache技术。优势是对单一类型的拒绝服务攻击效果比较好,效率也很高。缺点是由于目前的设计,导致体系缺乏灵活性,当出现特别类型的变种攻击时可能无能为力。
一己拙见: 当企业原本有计划采购Radware 设备作为常规应用是,可以考虑同时购入fireproof模块作为备用。
F5 Big-IP: X86架构,基于FreeBSD的内核,具有带阀值随机丢弃算法的syn-cache技术和针对icmp(可能还有udp?)的流量限制功能,因此可以在一定层次上缓解和抵抗syn类的拒绝服务攻击,实际效果尚可。
一己拙见: 不适合作为专业抗拒绝服务产品采购,可以作为负载均衡设备的附加功能作为增值考虑。
天网防火墙: 最早基于OpenBSD内核,X86架构,现在应该也是Linux内核了。很早就加入了抗syn-flood功能,实际应该是syn-cache/syn-cookie的改进或加强版。实际测试syn流量64B包抵抗极限大概是25M左右。当小于20M是还是可以看到效果的。同时结合良好的防火墙策略应该也可以做到针对udp/icmp等类型的限制。
一己拙见: 防火墙一般来说还是让它作为自己的专业用途(访问控制)比较好,当然在网络业务不是很重要的生产类企业来说,买个防火墙同时兼有简单的抗syn功能倒也不错。
天元龙马: 抗DOS产品没用过,但是对他的防火墙产品印象比较不好,功能太简陋了。
其他: 防火墙类产品,很多都声称自己也具有抗DOS功能,其中最著名的就是NetScreen和Nokia/Checkpoint。实测结果:
NetScreen 500 (ASIC架构) 64B包SYN,当打开SYN防护开关时,攻击流量> 18 M左右,系统资源消耗99%,网络无法连通。初步判定netscreen 500 syn抗拒极限为20 M。 (多次多地点测试结果)
Nokia i740 (NP架构,低端和早期产品 - 340以下实际为X86架构,IPSO/基于BSD内核) 64B包SYN, 自动SYN防护,攻击流量......惨不忍睹...... > 10M就不行了,系统资源消耗99%,网络无法连通,同时管理界面也失去响应。但持续攻击很久之后停止攻击后恢复响应,说明系统工作稳定性还是不错的(netscreen也一样,在正常再现工作时间测试上这两家的稳定性表现也都很好,值得赞许)。
一己拙见: Nokia和NetScreen的抗拒绝服务性能,在得到大幅改进之前还是不要提得好。
Arbor和Riverhead的产品尚未接触过,可以请熟悉的朋友谈谈。
其他的 解决方案,还有在系统级的Linux/BSD的syncookie/syn-cache功能,AIX/NT的网络缓冲队列和网络参数调整,以及网络级的 4 - 7层交换处理,例如使用CSS11000等作负载均衡或者深层过滤等等,以及在网络设备和网关上作流量速率限制。这些都可以在一定层次上缓解或减轻拒绝服务类攻击的危害,但并不是根本的解决办法,可以看情况考虑选择。也许等到ip traceback和netflow等技术推广的更广泛一些时,情况就好一点了,算是个黑夜梦吧。
最后一点看法,拒绝服务是一个麻烦又难缠的问题 -- 因为它的成因太复杂,在网络的链路层、网络层、应用层都可能出现,但大家都回避不了。作为网络道德领域或文化领域的产物,仅仅在技术层面上是很难根治的。在应对方法的选择上,大家应该牢记三个80/20规则:
1、80%的正常时间和20%被攻击时间。时间当然会影响到损失,在你的损失和规避他所需要的花费之间均衡考虑;
2、80%的常规攻击和20%的特别攻击。任何设备都不可能处理所有的攻击,那么当出现特例部分的失效情况是如何应对,以及从这一条结合第一条规则考虑你的投入产出比,也是一个重要的问题。
3、80%的正常工作时间和20%的设备失败时间。 设备都有它可能失效的时候,可能是 软件、硬件、逻辑或RP问题。例如我就采购了两台某厂商的专业抗拒绝服务产品,测试和验收时表现正常,但是当某天受到攻击我拿出来上线上架时我才发现,一台硬件失败无法启动!而另一台对这种攻击没有防护效用!这种情况怎么办?是向领导承认我失职,还是等待厂商慢慢研究出应对方案?恐怕都很难解决.
就是这样的三个原则,可能他出现的几率并不是概数的80/20,但哪怕仅仅1%的几率我们也要把它放大百倍看待。为了1%的事故考虑资产投入,然后还要担心会不会因为这1%时间中的1%措施失败几率导致我们的投入全部付诸流水。
一己拙见: 作为应急响应时备用。
Radware fireproof: ASIC/NP架构,SynApps技术,主要是基于签名的4-7层过滤算法与补充的syn-cache技术。优势是对单一类型的拒绝服务攻击效果比较好,效率也很高。缺点是由于目前的设计,导致体系缺乏灵活性,当出现特别类型的变种攻击时可能无能为力。
一己拙见: 当企业原本有计划采购Radware 设备作为常规应用是,可以考虑同时购入fireproof模块作为备用。
F5 Big-IP: X86架构,基于FreeBSD的内核,具有带阀值随机丢弃算法的syn-cache技术和针对icmp(可能还有udp?)的流量限制功能,因此可以在一定层次上缓解和抵抗syn类的拒绝服务攻击,实际效果尚可。
一己拙见: 不适合作为专业抗拒绝服务产品采购,可以作为负载均衡设备的附加功能作为增值考虑。
天网防火墙: 最早基于OpenBSD内核,X86架构,现在应该也是Linux内核了。很早就加入了抗syn-flood功能,实际应该是syn-cache/syn-cookie的改进或加强版。实际测试syn流量64B包抵抗极限大概是25M左右。当小于20M是还是可以看到效果的。同时结合良好的防火墙策略应该也可以做到针对udp/icmp等类型的限制。
一己拙见: 防火墙一般来说还是让它作为自己的专业用途(访问控制)比较好,当然在网络业务不是很重要的生产类企业来说,买个防火墙同时兼有简单的抗syn功能倒也不错。
天元龙马: 抗DOS产品没用过,但是对他的防火墙产品印象比较不好,功能太简陋了。
其他: 防火墙类产品,很多都声称自己也具有抗DOS功能,其中最著名的就是NetScreen和Nokia/Checkpoint。实测结果:
NetScreen 500 (ASIC架构) 64B包SYN,当打开SYN防护开关时,攻击流量> 18 M左右,系统资源消耗99%,网络无法连通。初步判定netscreen 500 syn抗拒极限为20 M。 (多次多地点测试结果)
Nokia i740 (NP架构,低端和早期产品 - 340以下实际为X86架构,IPSO/基于BSD内核) 64B包SYN, 自动SYN防护,攻击流量......惨不忍睹...... > 10M就不行了,系统资源消耗99%,网络无法连通,同时管理界面也失去响应。但持续攻击很久之后停止攻击后恢复响应,说明系统工作稳定性还是不错的(netscreen也一样,在正常再现工作时间测试上这两家的稳定性表现也都很好,值得赞许)。
一己拙见: Nokia和NetScreen的抗拒绝服务性能,在得到大幅改进之前还是不要提得好。
Arbor和Riverhead的产品尚未接触过,可以请熟悉的朋友谈谈。
其他的 解决方案,还有在系统级的Linux/BSD的syncookie/syn-cache功能,AIX/NT的网络缓冲队列和网络参数调整,以及网络级的 4 - 7层交换处理,例如使用CSS11000等作负载均衡或者深层过滤等等,以及在网络设备和网关上作流量速率限制。这些都可以在一定层次上缓解或减轻拒绝服务类攻击的危害,但并不是根本的解决办法,可以看情况考虑选择。也许等到ip traceback和netflow等技术推广的更广泛一些时,情况就好一点了,算是个黑夜梦吧。
最后一点看法,拒绝服务是一个麻烦又难缠的问题 -- 因为它的成因太复杂,在网络的链路层、网络层、应用层都可能出现,但大家都回避不了。作为网络道德领域或文化领域的产物,仅仅在技术层面上是很难根治的。在应对方法的选择上,大家应该牢记三个80/20规则:
1、80%的正常时间和20%被攻击时间。时间当然会影响到损失,在你的损失和规避他所需要的花费之间均衡考虑;
2、80%的常规攻击和20%的特别攻击。任何设备都不可能处理所有的攻击,那么当出现特例部分的失效情况是如何应对,以及从这一条结合第一条规则考虑你的投入产出比,也是一个重要的问题。
3、80%的正常工作时间和20%的设备失败时间。 设备都有它可能失效的时候,可能是 软件、硬件、逻辑或RP问题。例如我就采购了两台某厂商的专业抗拒绝服务产品,测试和验收时表现正常,但是当某天受到攻击我拿出来上线上架时我才发现,一台硬件失败无法启动!而另一台对这种攻击没有防护效用!这种情况怎么办?是向领导承认我失职,还是等待厂商慢慢研究出应对方案?恐怕都很难解决.
就是这样的三个原则,可能他出现的几率并不是概数的80/20,但哪怕仅仅1%的几率我们也要把它放大百倍看待。为了1%的事故考虑资产投入,然后还要担心会不会因为这1%时间中的1%措施失败几率导致我们的投入全部付诸流水。