當前國內主要的抗DOS設備主要有:
綠盟黑洞: X86架構，Linux內核與自主專利的抗syn-flood算法。對抗單一類型的syn，udp，icmp dos效果很好，但是當多種混合時效果就略差。優(yōu)點是更新快，技術支持比較好，在100M環(huán)境下對syn-flood有絕對優(yōu)勢。 缺點是文檔和信息缺乏，同時工作(軟硬件兩方面)不是很穩(wěn)定。
一己拙見: 作為應急響應時備用。
Radware fireproof: ASIC/NP架構，SynApps技術，主要是基于簽名的4-7層過濾算法與補充的syn-cache技術。優(yōu)勢是對單一類型的拒絕服務攻擊效果比較好，效率也很高。缺點是由于目前的設計，導致體系缺乏靈活性，當出現(xiàn)特別類型的變種攻擊時可能無能為力。
一己拙見: 當企業(yè)原本有計劃采購Radware 設備作為常規(guī)應用是，可以考慮同時購入fireproof模塊作為備用。
F5 Big-IP: X86架構，基于FreeBSD的內核，具有帶閥值隨機丟棄算法的syn-cache技術和針對icmp(可能還有udp?)的流量限制功能，因此可以在一定層次上緩解和抵抗syn類的拒絕服務攻擊，實際效果尚可。
一己拙見: 不適合作為專業(yè)抗拒絕服務產(chǎn)品采購，可以作為負載均衡設備的附加功能作為增值考慮。
天網(wǎng)防火墻: 最早基于OpenBSD內核，X86架構，現(xiàn)在應該也是Linux內核了。很早就加入了抗syn-flood功能，實際應該是syn-cache/syn-cookie的改進或加強版。實際測試syn流量64B包抵抗極限大概是25M左右。當小于20M是還是可以看到效果的。同時結合良好的防火墻策略應該也可以做到針對udp/icmp等類型的限制。
一己拙見: 防火墻一般來說還是讓它作為自己的專業(yè)用途(訪問控制)比較好，當然在網(wǎng)絡業(yè)務不是很重要的生產(chǎn)類企業(yè)來說，買個防火墻同時兼有簡單的抗syn功能倒也不錯。
天元龍馬: 抗DOS產(chǎn)品沒用過，但是對他的防火墻產(chǎn)品印象比較不好，功能太簡陋了。
其他: 防火墻類產(chǎn)品，很多都聲稱自己也具有抗DOS功能，其中最著名的就是NetScreen和Nokia/Checkpoint。實測結果:
NetScreen 500 (ASIC架構) 64B包SYN，當打開SYN防護開關時，攻擊流量> 18 M左右，系統(tǒng)資源消耗99%，網(wǎng)絡無法連通。初步判定netscreen 500 syn抗拒極限為20 M。 (多次多地點測試結果)
Nokia i740 (NP架構，低端和早期產(chǎn)品 - 340以下實際為X86架構，IPSO/基于BSD內核) 64B包SYN， 自動SYN防護，攻擊流量......慘不忍睹...... > 10M就不行了，系統(tǒng)資源消耗99%，網(wǎng)絡無法連通，同時管理界面也失去響應。但持續(xù)攻擊很久之后停止攻擊后恢復響應，說明系統(tǒng)工作穩(wěn)定性還是不錯的(netscreen也一樣，在正常再現(xiàn)工作時間測試上這兩家的穩(wěn)定性表現(xiàn)也都很好，值得贊許)。
一己拙見: Nokia和NetScreen的抗拒絕服務性能，在得到大幅改進之前還是不要提得好。
Arbor和Riverhead的產(chǎn)品尚未接觸過，可以請熟悉的朋友談談。
其他的解決方案，還有在系統(tǒng)級的Linux/BSD的syncookie/syn-cache功能，AIX/NT的網(wǎng)絡緩沖隊列和網(wǎng)絡參數(shù)調整，以及網(wǎng)絡級的 4 - 7層交換處理，例如使用CSS11000等作負載均衡或者深層過濾等等，以及在網(wǎng)絡設備和網(wǎng)關上作流量速率限制。這些都可以在一定層次上緩解或減輕拒絕服務類攻擊的危害，但并不是根本的解決辦法，可以看情況考慮選擇。也許等到ip traceback和netflow等技術推廣的更廣泛一些時，情況就好一點了，算是個黑夜夢吧。
最后一點看法，拒絕服務是一個麻煩又難纏的問題 -- 因為它的成因太復雜，在網(wǎng)絡的鏈路層、網(wǎng)絡層、應用層都可能出現(xiàn)，但大家都回避不了。作為網(wǎng)絡道德領域或文化領域的產(chǎn)物，僅僅在技術層面上是很難根治的。在應對方法的選擇上，大家應該牢記三個80/20規(guī)則:
1, 80%的正常時間和20%被攻擊時間。時間當然會影響到損失，在你的損失和規(guī)避他所需要的花費之間均衡考慮；
2, 80%的常規(guī)攻擊和20%的特別攻擊。任何設備都不可能處理所有的攻擊，那么當出現(xiàn)特例部分的失效情況是如何應對，以及從這一條結合第一條規(guī)則考慮你的投入產(chǎn)出比，也是一個重要的問題。
3, 80%的正常工作時間和20%的設備失敗時間。 設備都有它可能失效的時候，可能是軟件、硬件、邏輯或RP問題。例如我就采購了兩臺某廠商的專業(yè)抗拒絕服務產(chǎn)品，測試和驗收時表現(xiàn)正常，但是當某天受到攻擊我拿出來上線上架時我才發(fā)現(xiàn),一臺硬件失敗無法啟動!而另一臺對這種攻擊沒有防護效用!這種情況怎么辦?是向領導承認我失職,還是等待廠商慢慢研究出應對方案?恐怕都很難解決.
就是這樣的三個原則，可能他出現(xiàn)的幾率并不是概數(shù)的80/20，但哪怕僅僅1%的幾率我們也要把它放大百倍看待。為了1%的事故考慮資產(chǎn)投入，然后還要擔心會不會因為這1%時間中的1%措施失敗幾率導致我們的投入全部付諸流水。
先進的技術不一定能解決問題，合理的技術才是我們所事實需要的。
