[转]当前国内主要的抗DDOS设备

当前国内主要的抗DOS设备主要有:

　　绿盟黑洞: 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%措施失败几率导致我们的投入全部付诸流水。

　　先进的技术不一定能解决问题，合理的技术才是我们所事实需要的。

带宽是最主要的
大批量的不是攻击的访问，大量数据包的投递，也能将公网的带宽塞满
到那时候，就不是防火墙能解决的了……

对的