發現最新式的DDOS攻擊方式

攻擊思路的整理與提高，無意開發新的攻擊器。如利用此原理的攻擊軟件問世，與我本人skipjack無關。

引文章第一段（呵呵……有這一段足夠了）

在TCP三次握手後插入偽造的TCP包一、說明 用Socket的API Connect完成TCP建立連接的三次握手，同時子進程抓包，抓完三次握手的包後，插入第四個包即可，從對端返回的第五個包來看插入成功了，但因為插入了一個TCP包，之後的連接將發生混亂。可以將插入的那個包Data設置為HTTP Request，向WEB服務器提交請求。又如果目標系統的TCP序列號是可預計算的，那麼是否可以做帶偽源地址的Blind TCP three-time handshakes和插入，值得試驗！

作者所做的實驗其實什麼也說明不了，只是驗證了一下TCP協議序號和檢驗和計算函數而已。

我想作者八成是受了CC攻擊原理的啟發，想不通過代理的方式以達到CC攻擊效果。但在序號預測這個步驟上，說實話沒有可行性。正常TCP協議采用的同步序號是隨機值，在43億的可選空間中，以百兆帶寬的速度進行預測也將是杯水車薪。但是……

為了防御ddos，不少廠商的安全設備中都實現了無狀態的syn cookie算法，這種算法在大量syn沖擊下利用cookie序號在ack包回傳的方式判斷連接請求的合法性。所以他們的TCP協議握手部分不是一個健康的實現，本思路經修改後用於攻擊此類設備將會取得不錯的效果。下面簡單介紹攻擊者如何以64字節ACK包換取服務器1518大數據包重傳，如果源IP偽造成功，攻擊者從理論上將獲得20余倍的帶寬放大攻擊效果 .如果有兩個目標網站，本方法將一箭雙雕。

攻擊原理：利用TCP協議收到ACK後的快速重傳機制

序號亂刀之一：攻擊正常TCP/IP協議棧示意圖當我們獲得http response回應後，立即回復一個ack數據包，此ack數據包的seq值是http response數據包中的ack seq值，而ack seq值為http response數據包的seq序號值。這樣當server收到此ack數據包後，會認為是自己剛才發送的http response包在網絡中已丟失，會利用快速重傳機制加以重傳。如果我們拼命發送大量的ack包，則服務器就會不斷進行重傳。Ack數據包的大小只需64字節，但http response通常都在512字節左右，最長可達1518字節。

因為正常tcp協議序號的不可預測性，所以我們在這次攻擊中暴露了自己的真實IP.

序號亂刀之二：攻擊采用靜態syn cookie的ddos設備防護下的服務器

所謂靜態syn cookie就是以客戶端請求之syn包為參數計算回復syn ack中的seq值，並在ack包回傳時判斷連接合法性的方法，這種方法被ddos廠商大量采用，5自學網，並且獲得數量可觀的國家發明專利，呵呵………你經常會聽到ddos廠商的人說他們的設備比防火牆“牛”多了，5自學網，可輕松達到百兆線速syn防御，但百兆防火牆30M攻擊流量就可以干掉，說這種話的ddos廠商，我可以打賭他們的設備80%采用了這種syn cookie算法。

Syn cookie算法的好處是只在synflood攻擊時消耗CPU資源，這對於X86下強悍的通用CPU來說，正適用。

讀者可能會感到很奇怪，為什麼如此成熟的技術防火牆不采用，而讓ddos廠商成天擠對？這有如下幾個方面的原因：1：防火牆也用syn cookie進行synflood防御的，但大多不是靜態syn cookie，而是嚴格記錄連接狀態采用動態syn cookie，所以當syn flood攻擊時不光消耗CPU，還要消耗大量內存。這也就是我本文開頭提及的本方法可以攻擊大部分ddos廠商和小部分防火牆廠商的原因。

2：syn cookie/syn proxy是bsd系統內核源碼的一部分，在Linux最新版的2.6內核中syn proxy還沒有被包含。所以ddos設備也大多由bsd系統組成。當然bsd是開源的，移植也不是什麼大問題喽。

3：防火牆大多以Linux下的開源軟件netfilter為基礎，但netfilter中hash算法和連接表設計不是很優秀，防火牆轉發性能的瓶頸就在於此，如果再加入syn proxy表項，會進一步降低對數據包的處理能力或加大連接表體積。高端防火牆大都支持數百萬的連接數，這百萬的表項就夠防火牆喝一壺的了，再加一個syn proxy表項，性能還不得掉的稀裡嘩拉的？

4：防火牆很重要的一個網絡功能就是DNAT，在沒有DNAT操作前，防火牆不知道這些syn包的最終目的地是自身還是DMZ區的服務器，所以syn包必須DNAT後才知道是否要進行syn cookie保護。但這時就已經進入到netfilter處理框架了，性能當然就跟不上了。你見過幾個ddos設備支持NAT的？如果支持了，他的性能也會下降不少。如果防火牆工作在橋模式下，不經過netfilter處理框架，防火牆就可以搖身一變成為性能卓越的抗ddos設備了，嗎功能都沒有，當然一身輕松了。呵呵…但您買的是防火牆，會這麼大材小用嗎？

言歸正傳，采用靜態syn cookie的ddos設備，我們只需要重放一個ack包就可以達到與服務器的三次握手效果，因此可以做到源IP地址偽裝。（這個偽裝的源IP地址是你以前用過的，並且與ddos設備通訊過，並保存下來的，現在將它重放而己。如果你看不懂我在說什麼，參照我寫的《對國內ddos廠商技術點評》一文，抓包分析一下就知道了）。第二步就是發送一個正常的http request請求，隨後就是大量的虛假ack請求重傳。

天知道，誰在用我們偽裝的源IP地址，做為一個連帶的犧牲品。

你可能會認為受害服務器B會回復rst包給受害服務器A.這是有可能，但如果服務器B前面加裝了一個“狀態檢測”防火牆，就會直接丟棄這個反射的http response數據包。

本思路有價值的地方：1. 利用一條合法連接，對服務器進行下行帶寬攻擊，現在的“狀態檢測”設備不一定可以發現2. 目標服務器應用層程序感知不到這種攻擊，可以逃避基於應用層流量統計的防御方式，因為重傳是TCP協議特性，TCP協議自動完成。重傳的數據包，對應用層來說是透明的。

3. 現在只是一種思路，不局限於TCP協議。UDP加入重傳機制後，也可以保證通訊可靠性。並且這是私人或公司獨立開發的協議，漏洞會比TCP協議更大。

4. drdos的帶寬放大效果也只不過是6倍而己，並且消耗的是上行帶寬。

5. 真正的威脅不在現在，而是在對“長肥管道”的攻擊效果。對方下行帶寬越寬，攻擊效果越明顯。TCP會禁用分片，所以重傳數據包大小依靠你與服務器之間最小的那個設備的MTU值，所以你見到的TCP協議的IP首部中的長度字段不會超時1518.但在“長肥管道”中，IP首部的長度字段會達到65535的極大值，對這些數據包的重傳攻擊，會達到令人吃驚的1：1024的放大效果。

1M對1G 1G對1T明白？就是因為這點，我才會提供本思路，否則1：25的消耗也是蠻力。

攻擊完善的TCP協議其實是很困難的：1.具體可以參見RFC2581中關於Fast Retransmit/Fast Recovery的說明部分。

2.你的ack包構造不好，服務器協議棧還是會利用超時重傳，而不是快速重傳。