看了《問綠盟黑洞》的文章好幾天了，有點想法不吐不快。前兩天正忙，現在閒下來了，說說我的想法。文章中會提到一些廠商的技術，有正有反，大家不要對號入座，主要是希望對你們的技術提高有幫助。我以原始的ddos的先行者syn flood來舉例說明，cc我不打算評價，因爲我認爲syn flood的效果遠遠好於cc，而隱蔽性是cc遠遠達不到的。先點評一下關於DDoS話題方面的一些網友的錯誤認識和廠商的技術弱點。以下如果沒有特殊指明，ddos我指的就是syn flood這種最原始、最有效、最簡單、最可愛的東西。
1.只要一談論ddos想到的就是大流量，就是無邊無際、無際無邊的帶寬消耗戰。
錯了，syn flood可不是帶寬消耗戰，drdos纔是！那是因爲syn flood的使用者使用不當，纔會有今天大家的錯誤認識。
2.天，我CPU都滿跑了，爲什麼目標機一點事都沒有？我用的可以Linux下開源的、大家都害怕的、網評第1的攻擊軟件呀。
檢查一下你的網關是不是有NAT，如果有。不是你的包沒出去，就是你的網關快陣亡了，您趕快住手吧。
去掉你前面的防火牆，因爲防火牆在你發起攻擊時，最先受到損害，更重要的是它是你財產的一部分。
你極有可能拿一款ether下的攻擊程序在pppoe網絡中使用了，爲了提高效率攻擊數據包都是自己填充的，所以程序本身可能把數據包進行了ether_type的二層封裝，如果你在pppoe環境中攻擊，請自己修改源代碼改爲PPPOE封裝。否則的話，你攻擊的不是目標機，而是在自己的房間裏大小便。要學會分析協議，下面纔是二層PPPOE封裝的正確格式：
88 64 11 00 0B D0 00 56 00 21
3.這個ddos設備沒什麼了不起，用的就是syn cookie和syn proxy。
我認爲這兩種方法是當前最有效的解決方法，就像攻擊者必須聯網才能發起攻擊一樣，這兩種措施是必做的。如果您沒用這兩種方法就實現了ddos防禦，以下的內容您就不用看了。因爲您是我見過的第一牛人，我在您面前絕對是個晚輩的。在此就不浪費您的寶貴時間了。如果您感覺我還可救，給我留點面子傳張紙條教侮我一番吧。
4.drdos比ddos時髦多了，可以四兩撥千斤
真不好意思，syn ack這個數據包應該從內網口收到纔對，從外網口收到時直接丟掉就可以了。它浪費的是你的寬帶而不是內存或者大量的cpu。
你可能會說我後面的服務器是ftp並工作在主動模式，所以有時syn ack也是不能丟的。嗯…解決方案你自己已經說出來了，自己想個辦法吧。
5.DDoS是最沒有水準的攻擊類型，菜鳥才用。
這隻能說明你只是使用ddos工具的人，而不是一個編寫ddos攻擊類程序的人。大家知道一款好的ddos攻擊軟件，所發的包在各協議首部字段的合法範圍內越隨機越好。只要有一個字段該變但你沒變的，特證過濾一下子就把你幹掉了。如果攻擊包是以多播、迴環爲源ip發送，我只能說攻擊者在和你開玩笑，看看日曆確認今天不是愚人節。
但滿足隨機就是好的攻擊軟件嗎？喵～喵～俺家的小花貓都知道，遠遠不是滴，單純發syn攻擊包就不是好的攻擊方式。浪費ddos設備資源的是握手的第三個ack包。但第三個包構造上又很有講究，舉個例子：國內某某ddos廠商的主頁，我小流量正常訪問時抓包，可以發現他沒有做syn proxy，但當我1000pps時，通過抓包就可以看出，他啓用syn proxy了，並且syn cookie也隨之打開了，你問我怎麼知道的？看看它回覆的syn ack包的tcp選項部分的變化你就明白了。這時是他啓用防護的時機，也是它最脆弱的時候，細心的構造一個syn包，一個ack包，算準了它的cookie，餵給它。喵～小花貓都知道5000pps足夠了。我不是有意這麼做的，是它在CU裏叫大家幫忙做測試，我簡單的分析了一下，是這個原理。沒叫勁，睡覺了，第二天具說有3000臺肉機參與了，不知是真是假，如果沒有了解原理，你就算動用8000臺也沒用啊！
這裏真正的技術是推算cookie，但我在市面上找不到一款ddos攻擊軟件有這個方面的功能，你可能會說這不就是cookie攻擊嗎，我不這麼認爲，我不會發大量的ack來消耗它的cpu資源，我只是想鑽它算法的空子。因爲一種cookie的算法就好比是一類ddos設備的指紋，推出這個cookie的參數與運算法則，以後遇到它的時候，它就死定了。當然廠商也不傻，算cookie的參數是個很大的數並且還是在不斷變化，但不會經常變，每次啓動的時候變一次就算很智能了。因爲每天小花貓吃飯的時候，我都會便順發送一個相同的syn包給它，它返給我的syn ack中的cookie一直都是一樣的。哈哈…如果我有耐心，終有一天我會推出來的，注意：這個syn包源IP是真實的，所以我能觀察到它的返回數據包，並且他根本就發現不了偶。一天才一個syn包嘛。
順便問問版主，綠盟在測試黑洞的時候，肯定有一種攻擊軟件是他們自己寫的，針對自己的產品的弱點、軟肋、命門、死穴、捫門發送5000pps應該就可以掛了。喵～喵～喵～小花貓嚥到了。
6.這個百兆ddos設備真牛呀，百兆的線路我都D滿了，還可以正常訪問保護的服務器
你的感嘆用錯對像了，你應該感嘆於這條網線的質量很好，一條質量優秀的網線，百兆千兆的確都可以跑起來呀。另外一個設備適用於百兆還是千兆環境的瓶頸，你沒有弄清楚。我用82559網卡，我的算法再好也不可能你把百兆線路D滿了，後面的服務器你還可以訪問。你的這種情況，我可以很負責任的告訴你，這個外表百兆ddos設備實際採用了千兆平臺和千兆網卡，而流量的瓶頸在你測試中的其它結點上。僅此而己。
7.我們的算法不對syn包做回追處理，所以你的下行帶寬沒有被浪費。
這話也說的出口，真汗！小花貓甩甩尾巴跑去喝水了。你把10kpps的發包器真接插在百兆ddos設備上面試一下，看看是回覆syn ack時CPU使用率高，還是隻接受syn包不回覆時CPU佔用率高。告訴你，後者的cpu佔用率更高一些。爲什麼呢？因爲我回復syn ack時也是一種另類的保護策略，在局域網中，攻擊者發的數據包也必須依照衝突檢測載波監聽的方式來發送攻擊包，如果你回覆等量的syn ack也就是在堵攻擊者的嘴，他發包的速度會成倍的減下來。這意味這什麼？意味着你用你的下行帶寬換來了上行帶寬，這麼好的機會你爲什麼要放棄？這就好像一羣人在用磚頭拍你，拍的你上串下蹦，左躲右閃，累的你呼吃帶喘，你心裏還在想我TM怎麼這麼聰明呀，沒有回拍他們，節約了不少力氣，所以現在身行才能如此敏捷。
8.你看我們的設備連IP地址都沒有，可以實現網絡隱身，所以很安全
幸好小花貓不在身邊，否則還不得被嗆個半死呀。這個因果關係也說的出來？那我是不是可以說工作在橋模式下的設備都很安全？這是我見過的最大的拿缺點當優點忽憂人的說詞。你把IP地址給我設上，我爲什麼要網絡隱身啊，我光明正大！你不是防ddos攻擊嗎？你自己的ip爲什麼不敢暴露在公網上提供http管理控制？廠商會找出各種的手段來忽憂你，以下是最常見的託詞：設置管理IP地址當然可以了，但要從另外的一個網口專門引出來，並且我們不對管理網口做防護，因爲這樣會增加我們系統的負載呀。呀～～呀～～呀～～，回想起測試性能的時候他們好像說自己的算法很牛，什麼國際領先啦，什麼可以抵禦所有未知的ddos攻擊啦，什麼算法CPU零負載啦，什麼指紋啦，什麼單向數據包一次檢測啦，什麼身份證啦、什麼syn包實名制啦、什麼暫住證啦….什麼這個，什麼那個了，你都這麼強了，暴露一下嘛。
不想做過多技術分析，主機型syn proxy syn cookie和網關型syn proxy syn cookie的難度不是一個數量級，原因是廠家爲了效率把syn proxy syn cookie都在驅動層實現了，你叫他們把數據包上送到系統的TCP/IP協議棧給系統自身，真的是很難爲他們。但你實現不了可以直說，忽憂我家小花貓就不厚道了。
9.我們的設備是透明接入，不會修改你的拓撲
嗯…這要看你對透明接入的瞭解程度了，我翻了翻所有ddos廠商的手冊，吃驚的發現，都是一個模子，不知是誰抄誰的。上畫三張用戶常用拓撲，一個保護服務器、一個保護防火牆，一個保護網絡，就認爲自己可以全透明接入了？下面這張圖你能透明接入嗎？內網爲三個VLAN網段，服務器放在VLAN2中，每個網段互相訪問都必須通過防火牆內網口的三個對應VLAN網卡（各網段默認網關），防火牆通過DNAT後對外映射VLAN2網段服務器。我的要求是即要求你防外網的ddos還要你防止內網對VLAN2的ddos，敢問您，您打算怎麼個透明進入法？
1) 透明接入在防火牆外網口？
2) 透明接入在防火牆內網口？
你八成會修改我的拓撲，把VLAN2轉到DMZ，然後透明接入在防火牆DMZ網口上
外網
|
防火牆
|
| 交換機trunk口
|
switch
| | |
VLAN 1 VLAN2 VLAN3
10.利用超時重傳來判斷syn包是否合法
這種方法是相當的有效啊，遠處傳來小花貓的聲音：“給它在三秒鐘之內發第二個syn包”
11.可能您感覺本文寫的不錯，但要轉載的時候，請註明原作者是skipjack，僅些而己，謝謝了
很不幸，年初時給國家某某一級刊物投稿，先開始寫了8000字，後來叫我一刪再刪，刪了再刪，圖是左減一個，右減一個，上減一個，下減一個，前減一個，後減一個。本來是一個從淺入深的分析過程，後來成了個半調子，沒幾個人可以讀懂了。稿費匯給我時，我都快哭了，4000多字纔給俺103元，從郵局走出來的時候，手裏握着這103元錢，心裏想：“今兒中午我是請老婆吃飯呢，還是請小花貓吃飯呢？”。
2006-4-6
23:33 skipjack
備註:
2006-4-9 22:02
1)修改原文,去掉筆誤(一處)與錯別字(兩處) xiyang網友說我文章中有"憤青"言語和人身攻擊詞彙,我把我認爲是的去掉了.在此表示謙意.
2)我不是做ddos產品的,所以我寫文章這麼大膽,否則我不是自己砸自己飯碗嘛?
3)我的身份大家不要猜了,我不是綠盟 天融信 金盾 神州盾 dosnipe的人(排名不分先後)
2006-4-29 21:29
zeroflag網友對第七點進行了debug。
>>沒做過測試，不知道你說不回追CPU佔有率高是不是正確，但是你的解釋有問題。
>>全雙工模式下，收發不相干，回覆數據包怎麼可能降低對方發包速度呢？望明鑑！
答覆: 觀點七: 想說明那些被動的等待重傳來判斷syn包合法性的作法是多麼的不可取.與其被堵死,不如搏一下.
對,這點在同鈾電纜環境下是正確的.在雙絞線下這麼說的確不太嚴謹.
雙絞線的上/下行帶寬是完全分開的.收對發,發對收.
我上面提的發包器,因爲源MAC沒有僞造,只是僞造了源IP,所以當我回復syn ack時,攻擊者也必須處理收包工作.這樣它的CPU負載就加大了,發包就會慢下來.
你可能會說,沒有僞造源MAC的攻擊包就是~傻~包呀,
但你不要丟記,在單一網關出口時,網關就是這種情況下的發包器,
|
|
