鏈級測試 (Link Testing)
多數的追蹤技術都是從最接近victim的路由器開始，然后開始檢查上流數據鏈，直到找到攻擊流量發起源。理想情況下，這種過程可以遞歸執行直到找到攻擊源頭。這種技術假設攻擊一直保持活動直到完成追蹤，因此很難在攻擊結束后、間歇性攻擊或對追蹤進行攻擊調整等情況進行追蹤。包括下面兩種鏈級測試：
1、Input debugging
很多路由器都提供Input debugging特性，這能讓管理員在一些出口端過濾特定的數據包，而且能決定可以達到那些入口。這種特性就被用來作traceback：首先，victim在確定被攻擊時，要從所有的數據包中描述出攻擊包標志。通過這些標志，管理員在上流的出口端配置合適的Input debugging。這個過濾會體現出相關的input端口，這個過濾過程可以一直朝上流進行，直到能夠到達最初的源頭。當然這種工作很多依靠手工，一些國外的ISP聯合開發的工具能夠在它們的網絡中進行自動的追蹤。
但是這種辦法最大的問題就是管理花費。聯系多個ISP并同他們合作需要時間。因此這種辦法需要大量的時間，而且幾乎不可能完成。
2、Controlled flooding
Burch和 Cheswick提出的方法。這種方法實際上就是制造flood攻擊，通過觀察路由器的狀態來判斷攻擊路徑。首先應該有一張上游的路徑圖，當受到攻擊的時候，可以從victim的上級路由器開始依照路徑圖對上游的路由器進行控制的flood，因為這些數據包同攻擊者發起的數據包同時共享了路由器，因此增加了路由器丟包的可能性。通過這種沿路徑圖不斷向上進行，就能夠接近攻擊發起的源頭。
這種想法很有獨創性而且也很實際，但是有幾個缺點和限制。最大的缺點就是這種辦法本身就是一種DOS攻擊，會對一些信任路徑也進行DOS，這個缺點也很難用程序實施。而且，Controlled flooding要求有一個幾乎覆蓋整個網絡的拓撲圖。Burch和 Cheswick也指出，這種辦法很難用于DDOS攻擊的追蹤。這種方法也只能對正在進行攻擊的情況有效。
現在CISCO的路由器的CEF（Cisco Express Forwarding）實際上就是一種鏈級測試，也就是說，要用CEF追蹤到最終源頭的話，那么整個鏈路上的路由器都得使用CISCO的路由器，而且支持CEF。就得要Cisco 12000或者7500系列的路由器了。（不知道現在怎么樣，沒查最新的CISCO文檔），但是要用這個功能是很費資源的。
在CISCO路由器（支持ip source-track的路由器）上IP源追蹤以下面的步驟實現：
1、當發現目的被攻擊，打開整個路由器上對目的地址的追蹤，輸入命令 ip source-track。
2、每個Line Card為要追蹤的目的地址創建特定的CEF隊列。對于line card或者端口適配器用特定的ASIC作包轉換，CEF隊列用于將包置入line card或者port adapter的CPU。
3、每個line card CPU收集關于要追蹤目的的通訊信息
4、所產生的數據定時導出到路由器。要現實這些流信息的摘要，輸入命令：show ip source-track summary。要顯示每個輸入接口的更多的細節信息，輸入命令show ip source-track
5、統計被追蹤的IP地址的細目表。這可用于上游路由器繼續分析。可以在當前路由器上關閉IP source tracker，輸入命令：no ip source-track。然后在上游路由器上再打開這個功能。
6、重復步驟1到5，直到找到攻擊源。
這差不多能夠解答securitytest提的了吧。
Logging
這種方法通過在主路由器上記錄數據包，然后通過數據采集技術來決定這些數據包的穿越路徑。雖然這種辦法可以用于對攻擊后的數據進行追蹤，它也有很明顯的缺點，比如可能要求大量的資源（或者取樣），并且對付大量數據的綜合問題。
ICMP追蹤
這種方法主要依靠路由器自身產生的ICMP跟蹤消息。每個路由器都有很低的概率（比如：1/200000），數據包可能會把內容復制到一個ICMP消息包中，并且包含了到臨近源地址的路由器信息。當flood攻擊開始的時候，victim就可以利用這些ICMP消息來重新構造攻擊者的路徑。這種方式同上面介紹的比較，有很多優點，但是也有一些缺點。比如：ICMP可能被從普通流量中過濾掉，并且，ICMP追蹤消息還要同input debugging特性（將數據包同數據包input端口和/或者要到達的MAC地址關聯的能力）相關，但是，可能一些路由器就沒有這樣的功能。同時，這種辦法還必須有一種辦法來處理攻擊者可能發送的偽造ICMP Traceback消息。也就是說，我們可以把這種方式同其他辦法一起使用來讓跟蹤機制更有效。(IETF iTrace)
這就是yawl說的IETF的工作組研究的內容，當時我給Bellovin提出一些意見，但是沒有得到答案。比如：
1、盡管是隨機1/20000發送追蹤包，但是，對于偽造TRACEBACK的包情況下，對路由器的效率將有一定的影響。
2、追蹤包的認證并不能解決偽造問題。因為要判別是否是偽造包，那么必須去認證，加大了工作量。
3、即便使用NULL 認證，同樣能夠達到目的（有認證的情況下）。而且也不會有太大影響。
4、itrace的本來目的是去對付DOS的欺騙源問題，但是現在的設計仿佛讓我們更關心的是路徑而不是源頭。難道路徑比源頭更對我們解決DOS問題有用么？
等等，還有一堆問題，都是我覺得iTrace將會面臨的很難處理的問題。
數據包標記
這種技術構想（因為現在沒有實用）就是要在現有協議的基礎上進行修改，而且修改很小，不象iTrace的想法，個人認為比iTrace更好一些。這種追蹤技術有很多細節研究，形成多種標記算法，但是最好的還是經過壓縮的邊緣取樣算法。
這種技術原理就是修改IP頭中，重載其中的identification域。也就是如果沒有使用到identification域的話，將這個域定義為標記。
將16bit的idnetification分成：3bit的offset（可允許8次分片）,5bit的distance，以及8bit的邊緣分片。5bit的distance可以允許31級路由，這對于目前的網絡來說已經足夠了。
標記和重構路徑的算法是：
Marking procedure at router R: Path reconstruction procedure at victim v: let FragTbl be a table of tuples(frag,offset,distance) |
實驗室情況下這種標記技術只需要victim能夠抓到1000到2500個包就能夠重構整個路徑了，應該說結果是很好的，但是沒有投入到實用中，主要是需要路由器廠商和ISP支持。
差不多ip traceback的已經實用的技術和實驗室技術，或者已經死掉的，就主要是這些，雖然還有其他的一些。
已經很長時間沒有搞DDOS防范這一塊了，國內也有黑洞這樣的產品，以前也了解一些國外的，比如floodguard、toplayer、radware等。受securitytest提示，又了解到riverhead的，我就立刻看了看他們的白皮書。
因為前面bigfoot提出的主要是ip traceback的題目，securitytest也又到防御的問題。針對DDOS的問題ip traceback和Mitigation是不一樣的，ip traceback主要是進行追蹤，因為DDOS主要是spoof，而很難判別到真正的攻擊源，而且如果能夠很容易找到真正的攻擊源，不僅僅對付DDOS，對付其他的攻擊也很有幫助，比如法律問題等。而Mitigation是從受害者的角度，因為victim一般是沒有能力去調查整個網絡，找出source，而且，即便能夠找到source，也得有法律或者一些溝通的手段來讓source停下來（攻擊的source并不是source的攻擊者），這種意味著大量的溝通、跨ISP、跨過等類似的非技術問題，所以，通常很難處理。但是從victim的角度來說，必須得有所解決辦法，所以就需要Mitigation。
這又正好是我以前研究的范圍，所以，又會說出一大堆。對于Mitigation，其實，技術的根本就是要能從眾多的流量中將攻擊包和合法包分離出來，把攻擊包拋棄掉，讓合法包通過就性了。這就是根本，所以實際運用的技術就是要如何盡可能識別出攻擊包，而又盡可能小地影響正常包。這又得來分析DDOS（甚至DOS）的方式和原理。基本又下面幾種形式：
1、系統漏洞形成的DOS。這種特征固定，檢測和防御也容易
2、協議攻擊（一些跟系統處理相關，一些跟協議相關）。比如SYN FLOOD，碎片等。特征還好識別，檢測和防御相對容易。比如SYN COOKIE、SYN CACHE，碎片可以拋棄。比如land攻擊、smurf、teardrop等
3、bandwidth FLOOD。垃圾流量堵塞帶寬，特征不好識別，防御不容易
4、基本合法的FLOOD。比3更難了，比如分布的Slashdot 。
實際的DDOS，一般都是多種方式結合的。比如SYNFLOOD，可能同時是bandwidth FLOOD。
影響防御的主要因素就是看特征是否能得到，比如1、2就相對好解決，一些基本不影響的使用的FLOOD，則可以很好被拋棄，比如ICMP FLOOD。但是，攻擊發包工具如果將數據包更能偽裝成合法包，那么就很難識別出來了。
一般的Mitigation方法也就是：
1、Filter。對于特征明顯的，比如一些蠕蟲等，在路由器上就可以搞定。當然，過濾是最終解決辦法，只要識別出了攻擊包，就是要把這些包過濾掉。
2、隨機丟包。跟隨機算法相關，好的算法可以讓合法包受到更小影響
3、SYN COOKIE、SYN CACHE等特定防御辦法。針對一些固定的攻擊手段來防御和過濾。比如ICMP FLOOD、UDP FLOOD。SYN COOKIE等都是避免spoof問題，至少TCP還有三次握手，所以還好判斷SPOOF
4、被動消極忽略。可以說也是一種確認是否被欺騙的辦法。一般正常連接失敗會重新嘗試，但是攻擊者一般不會嘗試的。所以可以臨時拋棄第一次連接請求而接受第二次或者第三次連接請求。
5、主動發送RST。對付SYN FLOOD的，比如一些IDS上。當然，實際不是有效的。
6、統計分析和指紋。這本來是研究的主要內容，但是最后陷入了算法牛角尖，因為主要是一個算法問題。通過統計分析的角度來得到指紋，然后根據指紋來拋棄攻擊包，也是一種異常檢測的技術。說得很簡單，但是要不影響合法包也不容易，不至于變成了隨機丟包。（其實當時考慮太過復雜，非得要詳細分析出攻擊包和合法包，實際不需要，只要過濾掉足夠的攻擊包，即便讓攻擊包通過，但只要不造成DOS就可以了。）這也是很多研究者研究的主要課題，目的也就是識別攻擊包。
現在在回到securitytest提到的riverhead。關于riverhead的技術，我都只是從他們的白皮書上了解到的，但根據我的分析技術方法都沒有超出上面提到的范圍。
riverhead的核心方案就是檢測 Detection、轉移 Diversion 和 緩解 Mitigation，也就是檢測到攻擊，然后將流量轉移到他們的產品guard上，然后通過guard進行Mitigation。
它的實現步驟，就是：
因為沒有圖，所以先定義一下，才能說清楚：
#靠近分布式拒絕服務源頭的路由器為 遠端路由器
#靠近受害者的路由器為 近端路由器
#Riverhead的Guard設備附屬安裝的路由器為 附屬路由器
防御的步驟
1、首先檢測到有DDOS發生，并了解到victim
2、Guard發送BGP通告到遠端路由器（在victim的BGP通告設置前綴，并得到比原始BGP通告更高的優先權），表示從遠端路由器到victim有新的路由，并且路由到Guard的loopback interface，所有到victim的都經過附屬路由器轉移到了Guard上
3、Guard檢查流量，并且清除其中的攻擊流量，然后把安全的流量轉發到附屬路由器上，在回到victim
其中核心就是Guard，技術就是白皮書中描述的MVP架構（Multi-Verification Process），也就是下面5個層次
過濾(Filtering) ：這個模塊包含靜態和動態的DDOS過濾。靜態過濾，攔截non-essential流量，可以是用戶定義的，或者是riverhead默認提供的。動態過濾則基于行為分析和流量的細節分析，通過增加對可疑流量的確認或攔截已經確認的惡意流量，來進行實時更新
反欺騙(Anti-Spoofing)：這個模塊驗證進入系統的數據包是否被欺騙的。Guard使用了獨有的、有專利的源驗證機制來避免欺騙。也通過一些機制來確認合法流量，消除合法數據包被拋棄
異常檢測（Anomaly Recognition）：該模塊監視所有沒有被過濾和反欺騙模塊拋棄的流量，將流量同平常紀錄的基線行為進行比較，發現異常。基本原理就是通過模式匹配，區別來自black-hat和合法通訊之間的不同。該原理用來識別攻擊源和類型，而且提出攔截這類流量的指南。
異常檢測包括： 流量分類： |
協議分析（Protocol Analysis）：本模塊處理異常檢測中發現的可疑的應用方面的攻擊，比如http攻擊。協議分析也檢測一些協議錯誤行為。
流量限制（Rate Limiting）：主要是處理那些消耗太多資源的源頭流量。
所以，實際上最主要的內容就是異常檢測中的統計分析，但是從上面看似乎沒有多少特別的地方，但是，一定有很好的算法。比如FILTER，實際是對付一些很熟悉的有明顯特征的攻擊，反欺騙，就是對付syn flood這樣的，說不定也是一個syn cookie模塊，，但也許有更專利的技術。協議分析其實應該來說就比較弱了，但可以針對一些常見協議中的特定攻擊，檢測識別一些協議錯誤行為只是協議校驗，這個很簡單。流量限制則就是一種隨機丟包，最無奈的辦法，所以也是最后一個層次了。
因為這個產品主要是作Mitigation的，而不是ip traceback。但是可以判定還是有重要的問題，比如：
1、如何對付真正的bandwidth flood。如果路由器是千兆的，但是，攻擊流量已經占了90%，只流下10%讓合法使用，路由器已經先與Guard開始進行隨機丟包了。（沒辦法，這是所有防御技術的瓶頸）
2、真正的攻擊。真正的攻擊是很難或者無法識別的。比如，基本跟正常形式一樣的，如果和統計數據很接近，那么很難區別出來。還有一些攻擊，比如反射式的郵件攻擊等，這是完全合法的，但是很難分類出來。
