文章轉載自：http://www.ayazero.com/?p=75

0x00 導讀

---

0x01 DDOS分類

---

在講防禦之前簡單介紹一下各類攻擊，因為DDOS是一類攻擊而並不是一種攻擊，並且DDOS的防禦是一個可以做到相對自動化但做不到絕對自動化的過程，很多演進的攻擊方式自動化不一定能識別，還是需要進一步的專家肉眼判斷。

• 網路層攻擊

  • Syn-flood

    利用TCP建立連線時3次握手的“漏洞”，透過原始套接字傳送源地址虛假的SYN報文，使目標主機永遠無法完成3次握手，佔滿了系統的協議棧佇列，資源得不到釋放，進而拒絕服務，是網際網路中最主要的DDOS攻擊形式之一。網上有一些加固的方法，例如調整核心引數的方法，可以減少等待及重試，加速資源釋放，在小流量syn-flood的情況下可以緩解，但流量稍大時完全不抵用。防禦syn-flood的常見方法有：syn proxy、syn cookies、首包（第一次請求的syn包）丟棄等。

  • ACK-flood

    對於虛假的ACK包，目標裝置會直接回復RST包丟棄連線，所以傷害值遠不如syn-flood。DDOS的一種原始方式。

  • UDP-flood

    使用原始套接字偽造大量虛假源地址的UDP包，目前以DNS協議為主。

  • ICMP-flood

    Ping洪水，比較古老的方式。

• 應用層攻擊

  • CC

    ChallengeCollapsar的名字源於挑戰國內知名安全廠商綠盟的抗DDOS裝置-“黑洞”，透過botnet的傀儡主機或尋找匿名代理伺服器，向目標發起大量真實的http請求，最終消耗掉大量的併發資源，拖慢整個網站甚至徹底拒絕服務。

    網際網路的架構追求擴充套件性本質上是為了提高併發能力，各種SQL效能最佳化措施：消除慢查詢、分表分庫、索引、最佳化資料結構、限制搜尋頻率等本質都是為了解決資源消耗，而CC大有反其道而行之的意味，佔滿伺服器併發連線數，儘可能使請求避開快取而直接讀資料庫，讀資料庫要找最消耗資源的查詢，最好無法利用索引，每個查詢都全表掃描，這樣就能用最小的攻擊資源起到最大的拒絕服務效果。

    網際網路產品和服務依靠資料分析來驅動改進和持續運營，所以除了前端的APP、中介軟體和資料庫這類OLTP系統，後面還有OLAP，從日誌收集，儲存到資料處理和分析的大資料平臺，當CC攻擊發生時，不僅OLTP的部分受到了影響，實際上CC會產生大量日誌，直接會對後面的OLAP產生影響，影響包括兩個層面，一個當日的資料統計完全是錯誤的。第二個層面因CC期間訪問日誌劇增也會加大後端資料處理的負擔。

    CC是目前應用層攻擊的主要手段之一，在防禦上有一些方法，但不能完美解決這個問題。

  • DNS flood

    偽造源地址的海量DNS請求，用於是淹沒目標的DNS伺服器。對於攻擊特定企業權威DNS的場景，可以將源地址設定為各大ISP DNS伺服器的ip地址以突破白名單限制，將查詢的內容改為針對目標企業的域名做隨機化處理，當查詢無法命中快取時，伺服器負載會進一步增大。

    DNS不只在UDP-53提供服務，同樣在TCP協議提供服務，所以防禦的一種思路就是將UDP的查詢強制轉為TCP，要求溯源，如果是假的源地址，就不再回應。對於企業自有權威DNS伺服器而言，正常請求多來自於ISP的域名遞迴解析，所以將白名單設定為ISP的DNS server列表。對於源地址偽造成ISP DNS的請求，可以透過TTL值進一步判斷。

  • 慢速連線攻擊

    針對http協議，以知名的slowloris攻擊為起源：先建立http連線，設定一個較大的content-length，每次只傳送很少的位元組，讓伺服器一直以為http頭部沒有傳輸完成，這樣的連線一多很快就會出現連線耗盡。

    目前出現了一些變種，http慢速的post請求和慢速的read請求都是基於相同的原理。

  • DOS攻擊

    有些伺服器程式存在bug、安全漏洞，或架構性缺陷，攻擊者可以透過構造的畸形請求傳送給伺服器，伺服器因不能正確處理惡意請求而陷入僵死狀態，導致拒絕服務。例如某些版本的app伺服器程式存在緩衝區溢位，漏洞可以觸發但無法得到shell，攻擊者可以改變程式執行流程使其跳轉到空指標或無法處理的地址，使用者態的錯誤會導致程式掛起，如果錯誤不能被核心回收則可能使系統當掉。

    這類問題效果也表現為拒絕服務，但本質上屬於漏洞，可以透過patch程式的最新版本解決，筆者認為不屬於DDOS的範疇。

• 攻擊方式

  • 混合型

    在實際大流量的攻擊中，通常並不是以上述一種資料型別來攻擊，往往是混雜了TCP和UDP流量，網路層和應用層攻擊同時進行。

  • 反射型

    2004年時DRDOS第一次披露，透過將SYN包的源地址設定為目標地址，然後向大量的

    

    真實TCP伺服器傳送TCP的SYN包，而這些收到SYN包的TCP server為了完成3次握手把SYN|ACK包“應答”給目標地址，完成了一次“反射”攻擊，攻擊者隱藏了自身，但有個問題是攻擊者製造的流量和目標收到的攻擊流量是1:1，且SYN|ACK包到達目標後馬上被回以RST包，整個攻擊的投資回報率不高。

    反射型攻擊的本質是利用“質詢-應答”式協議，將質詢包的源地址透過原始套接字偽造設定為目標地址，則應答的“回包”都被髮送至目標，如果回包體積比較大或協議支援遞迴效果，攻擊流量會被放大，成為一種高價效比的流量型攻擊。

    反射型攻擊利用的協議目前包括NTP、Chargen、SSDP、DNS、RPC portmap等等。

  • 流量放大型

    以上面提到的DRDOS中常見的SSDP協議為例，攻擊者將Search type設定為ALL，搜尋所有可用的裝置和服務，這種遞迴效果產生的放大倍數是非常大的，攻擊者只需要以較小的偽造源地址的查詢流量就可以製造出幾十甚至上百倍的應答流量傳送至目標。

  • 脈衝型

    很多攻擊持續的時間非常短，通常5分鐘以內，流量圖上表現為突刺狀的脈衝。

    

    之所以這樣的攻擊流行是因為“打-打-停-停”的效果最好，剛觸發防禦閾值，防禦機制開始生效攻擊就停了，週而復始。蚊子不叮你，卻在耳邊飛，剛開燈想打它就跑沒影了，當你剛關燈它又來了，你就沒法睡覺。

    自動化的防禦機制大部分都是依靠設定閾值來觸發。儘管很多廠商宣稱自己的防禦措施都是秒級響應，但實際上比較難。

    網路層的攻擊檢測通常分為逐流和逐包，前者根據netflow以一定的抽樣比例（例如1000:1）檢測網路是否存在ddos攻擊，這種方式因為是抽樣比例，所以精確度較低，做不到秒級響應。第二種逐包檢測，檢測精度和響應時間較短，但成本比較高，一般廠商都不會無視TCO全部部署這類方案。即便是逐包檢測，其防禦清洗策略的啟動也依賴於閾值，加上清洗裝置一般情況下不會串聯部署，觸發清洗後需要引流，因此大部分場景可以做秒級檢測但做不到秒級防禦，近源清洗尚且如此，雲清洗的觸發和轉換過程就更慢了。所以利用防禦規則的生效灰度期，在觸發防禦前完成攻擊會有不錯的效果，在結果上就表現為脈衝。

  • 鏈路泛洪

    隨著DDOS攻擊技術的發展，又出現了一種新型的攻擊方式link-flooding attack，這種方式不直接攻擊目標而是以堵塞目標網路的上一級鏈路為目的。對於使用了ip anycast的企業網路來說，常規的DDOS攻擊流量會被“分攤”到不同地址的基礎設施，這樣能有效緩解大流量攻擊，所以攻擊者發明了一種新方法，攻擊至目標網路traceroute的倒數第二跳，即上聯路由，致使鏈路擁塞。國內ISP目前未開放anycast，所以這種攻擊方式的必要性有待觀望。

    

    對一級ISP和IXP的攻擊都可以使鏈路擁塞。

0x02 多層防禦結構

---

DDOS攻擊本質上是一種只能緩解而不能完全防禦的攻擊，它不像漏洞那樣打個補丁解決了就是解決了，DDOS就算購買和部署了當前市場上比較有競爭力的防禦解決方案也完全談不上徹底根治。防火牆、IPS、WAF這些安全產品都號稱自己有一定的抗DDOS能力，而實際上他們只針對小流量下，應用層的攻擊比較有效，對於稍大流量的DDOS攻擊則無濟於事。

以2015年年中的情況為例，國內的DDOS攻擊在一個月內攻擊流量達到300G的就將近10-20次，這個數值將隨著國內家庭寬頻網速提升而進一步放大。對於200~500G的攻擊流量該如何防禦，下來將展示完整的防禦結構，通常可以分為4層。

這4層不是嚴格意義上的縱深防禦關係，也不是在所有的防禦中4層都會參與，可能有時候只是其中的2層參與防禦。但對於超大流量攻擊而言，4層就是防禦機制的全部，再沒有其他手段了。跟廠商們的市場宣傳可能有所不同，大流量攻擊的防護並不是像某些廠商宣稱的那樣靠廠商單方面就能解決的，而是多層共同參與防禦的結果。

• ISP/WAN層

  這一層通常對終端使用者不可見，如果只是中小企業，那這一層可能真的不會接觸到。但如果是大型網際網路公司，公有云廠商，甚至是雲清洗廠商，這層是必不可少的。因為當流量超過自己能處理的極限時必須要藉助電信運營商的能力。大型網際網路公司雖然自身儲備的頻寬比較大，但還沒到達輕鬆抵抗大流量DDOS的程度，畢竟頻寬是所有IDC成本中最貴的資源沒有之一。目前無論是雲端計算廠商，大型網際網路公司向外宣稱的成功抵禦200G以上攻擊的新聞背後都用到了運營商的抗D能力，另外像第三方的雲清洗平臺他們實際上或多或少的依賴電信運營商，如果只依靠本身的清洗能力，都是非常有限的。

  

  目前如中國電信的專門做抗DDOS的雲堤提供了[近源清洗]和[流量壓制]的服務，對於購買其服務的廠商來說可以自定義需要黑洞路由的IP與電信的裝置聯動，黑洞路由是一種簡單粗暴的方法，除了攻擊流量，部分真實使用者的訪問也會被一起黑洞掉，對使用者體驗是一種打折扣的行為，本質上屬於為了保障留給其餘使用者的鏈路頻寬的棄卒保帥的做法，之所以還會有這種收費服務是因為假如不這麼做，全站服務會對所有使用者徹底無法訪問。對於雲清洗廠商而言，實際上也需要藉助黑洞路由與電信聯動。

  

  相比之下，對攻擊流量的牽引，清洗，回注的防禦方式對使用者體驗的挑戰沒那麼大，但是跟黑洞路由比防禦方的成本比較高，且觸發到響應的延時較大。

  在運營商防禦這一層的主要的參與者是大型網際網路公司，公有云廠商，雲清洗廠商，其最大的意義在於應對超過自身頻寬儲備和自身DDOS防禦能力之外的超大攻擊流量時作為補充性的緩解措施。

• CDN/Internet層

  CDN並不是一種抗DDOS的產品，但對於web類服務而言，他卻正好有一定的抗DDOS能力，以大型電商的搶購為例，這個訪問量非常大，從很多指標上看不亞於DDOS的CC，而在平臺側實際上在CDN層面用驗證碼過濾了絕大多數請求，最後到達資料庫的請求只佔整體請求量的很小一部分。

  對http CC型別的DDOS，不會直接到源站，CDN會先透過自身的頻寬硬抗，抗不了的或者穿透CDN的動態請求會到源站，如果源站前端的抗DDOS能力或者源站前的頻寬比較有限，就會被徹底DDOS。

  雲清洗廠商提出的策略是，預先設定好網站的CNAME，將域名指向雲清洗廠商的DNS伺服器，在一般情況下，雲清洗廠商的DNS仍將穿透CDN的回源的請求指向源站，在檢測到攻擊發生時，域名指向自己的清洗叢集，然後再將清洗後的流量回源。

  檢測方式主要是在客戶網站前部署反向代理（nginx），託管所有的併發連線。在對攻擊流量進行分流的時候，準備好一個域名到IP的地址池，當IP被攻擊時封禁並啟用地址池中的下一個IP，如此往復。

  以上是類Cloudflare的解決方案，國內雲清洗廠商的實現原理都相似。不過這類方案都有一個通病，由於國內環境不支援anycast，透過DNS引流的方式需要比較長的生效時間，這個時間依賴於DNS遞迴生效的時長，對自身完全不可控。同時CDN僅對web類服務有效，對遊戲類TCP直連的服務無效。

  網上很多使用此類抗D服務的過程可以概括為一句話：更改CNAME指向，等待DNS遞迴生效。

• DC層

  

  目前國內廠商華為的Anti-ddos產品的最高型號支援T級高達1440Gbps頻寬的防護。原理大致如下圖所示，在DC出口以映象或分光部署DDOS探針（檢測裝置），當檢測到攻擊發生時，將流量牽引到旁路部署的DDOS清洗裝置，再將經過清洗的正常流量回注到業務主機，以此完成一輪閉環。

  

  部署裝置本身並沒有太大的技術含量，有技術含量的部分都已經被當做防禦演算法封裝在產品盒子裡了。不過要指出的一點是，目前市場上的ADS盒子既有的演算法和學習能力是有限的，他仍然需要人的介入，比如：

  • 對業務流量基線的自適應學習能力是有限的，例如電商行業雙11大促日子的流量模型可能就超越了ADS的學習能力，正常流量已經觸發攻擊判定
  • 自動化觸發機制建立在閾值之上，就意味著不是完全的自動化，因為閾值是一個經驗和業務場景相關的值
  • 全域性策略是通用性策略，不能對每一個子業務起到很好的防禦效果，有可能子業務已經被D了，全域性策略還沒觸發
  • 常見的DDOS型別ADS可以自動處理，但變換形式的DDOS型別可能還需要人工識別
  • 預設的模板策略可能不適用於某些業務，需要自定義

  DDOS防禦除了整體架構設計外，比較需要專業技能的地方就是在上述例子的場景中。目前在ADS裝置裡覆蓋了3-4,7這三層的解決方案。

  

  一般情況下ADS裝置可以緩解大部分常見的DDOS攻擊型別，相對而言3-4層的攻擊手法比較固定，而7層的攻擊，由於涉及的協議較多，手法變化層出不窮，所以ADS有時候對7層的防護做不到面面俱到，比如對CC，ADS提供了http 302，驗證碼等，但還是不能很好的解決這個問題。應用層的防護需要結合業務來做，ADS則在能利用的場景下承擔輔助角色，比如對於遊戲封包的私有協議，透過給packet新增指紋的方式，ADS在客戶端和服務端中間鑑別流入的資料包是否包含指紋。

• OS/APP層

  這是DDOS的最後一道防線。這一層的意義主要在於漏過ADS裝置的流量做最後一次過濾和緩解，對ADS防護不了的應用層協議做補充防護。比如NTP反射，可以透過伺服器配置禁用monlist，如果不提供基於UDP的服務，可以在邊界上直接阻斷UDP協議。

  網際網路線上服務中最大的比重就是web服務，因此有些網際網路公司喜歡自己在系統層面去做應用層的DDOS防護，例如對抗CC，有時這些功能也能順帶關聯到業務安全上，比如針對黃牛搶單等。

  

  實現方式可以是web伺服器模組，也可以是獨立部署的旁路系統，反向代理將完整的http請求轉發給檢測伺服器，檢測伺服器根據幾方面的資訊：

  • 來自相同IP的併發請求
  • 相同ip+cookie的併發請求
  • 相同http頭部可設定欄位
  • 相同的request URL

  然後儲存客戶端的連線資訊計數表，例如單位時間內相同IP+cookie再次發起連線請求則此客戶端IP的計數器+1，直到觸發閾值，然後伺服器會進行阻斷，為了避免誤殺，也可以選擇性的彈出驗證碼。

  以上是拿CC防禦舉了個例子，ADS裝置本身提供了http 302跳轉，驗證碼，Javascript解析等防禦方式，儘管OS和應用層可以做更多的事情，但畢竟有自己去開發和長期維護的代價，這個收益要看具體情況。

• 鏈路頻寬

  增加頻寬，大部分介紹DDOS防禦策略的文章裡似乎很少提及這一點，但卻是以上所有防禦的基礎，例如第二層次的CDN實際上就是拼頻寬，很多大型企業選擇自建CDN，本質上就是自己增加頻寬的行為。除了CDN之外，要保障DC出口的多ISP鏈路、備份鏈路，到下層機櫃交換機的頻寬都不存在明顯的單點瓶頸，否則抗DDOS的處理效能夠了，但是流量流經某個節點時突然把一個雜牌交換機壓垮了，最後的結果還是表現為有問題。

  對運維經驗成熟的網際網路公司而言，一般都有能容管理，對於促銷活動，高峰時段的頻寬，IDC資源的波峰波谷都有預先的準備，DDOS防禦主要是消除這些網路方案中內在的單點瓶頸。

0x03 不同型別的企業

---

DDOS的防禦本質上屬於資源的對抗，完整的4層防禦效果雖好，但有一個明顯問題就是TCO，這種成本開銷除了網際網路行業排名TOP10以外的公司基本都吃不消。或者就算付得起這錢，在IT整體投資的佔比會顯得過高，付得起不代表這種投資是正確的。所以針對不同的企業分別描述DDOS緩解方案的傾向和選擇性。

• 大型平臺

  這裡的“大”有幾層意思：

  • 公司很有錢，可以在補貼具體的業務上不“太”計較投入，對土豪來說只選效果最優方案
  • 公司不一定處在很賺錢的階段，但IDC投資規模足夠大，這樣為了保障既有的投入，安全的總投資維持一個固定百分比也是非常有必要的，在IDC盤子很大的時候沒必要省“小錢”
  • 與潛在的由於服務中斷造成的損失比，DDOS防禦的投資可以忽略不計

  對映到現實中與這幾條相關的公司：

  • 市值100億美元以上網際網路公司
  • 大型公有云廠商，IaaS、PaaS平臺
  • IDC規模多少算大呢，這個問題其實很難判斷，1w臺物理伺服器算多麼，現在應該只能算中等吧
  • 利潤比較高的業務，比如遊戲、線上支付假如被DDOS的頻率較高

  對於IDC規模比較大又有錢的公司來說，防DDOS的口訣就是“背靠運營商，大力建機房”，在擁有全部的DDOS防禦機制的前提下，不斷的提高IDC基礎設施的壁壘給攻擊者製造更高的門檻，對於網路流量比較高的公司而言，抗DDOS是有先天優勢的，因為業務急速增長而帶來的基礎設施的擴容無意識間就成了一種防禦能力，但對於沒有那麼大業務流量的公司，空買一堆頻寬燒錢恐怕也沒人願意。

  對於比較有錢，但沒那麼多線上伺服器的公司而言，自己投入太多IDC建設可能是沒必要的，此時應該轉向透過購買的手段儘可能的獲得全部的DDOS防禦機制。

• 中小企業

  資源的對抗肯定不是中小企業的強項，所以追求ROI是主要的抗DDOS策略。第一種極度省錢模式，平時裸奔，直到受攻擊才找抗DDOS廠商臨時引流，這種方案效果差一點，絕大多數企業應該都是這種心理，得過且過，能省則省，也無可厚非，不過關鍵時間知道上哪兒去找誰，知道做哪些事。

  第二種追求效果，希望有價效比。如果本身業務執行於公有云平臺，可以直接使用雲平臺提供的抗DDOS能力，對於web類可以考慮提前購買雲清洗廠商的服務。

0x04 不同型別的業務

---

不同的型別的服務所需要的DDOS防禦機制不完全相同，所以不能直接拿前述4層生搬硬套。

• Web

  對於web類服務，攻擊發生時終端使用者可以有一定的延遲容忍，在防禦機制上4層全部適用，大型平臺的一般都是4層全部擁有，規模小一點的企業一般購買雲清洗，cloudflare類的服務即可。

• 遊戲類

  Web api形式的輕遊戲跟web服務類似，而對於TCP socket型別的大型網遊，稍有延遲很影響使用者體驗，甚至很容易掉線。雲WAF、CDN等措施因為是針對web的所在在該場景下無效，只有透過DNS引流和ADS來清洗，ADS不能完美防禦的部分可以透過修改客戶端、服務端的通訊協議做一些輔助性的小動作，例如封包加tag標籤，檢測到沒有tag的包一律丟棄，防禦機制基本都是依賴於資訊不對稱的小技巧。DNS引流的部分對於有httpdns的廠商可以藉助其緩解DNS遞迴生效的時間。

• 服務策略

  • 分級策略

    對於平臺而言，有些服務被DDOS會導致全站服務不可用，例如DNS不可用則相當於全線服務不可用，對於強賬號體系應用例如電商、遊戲等如果SSO登陸不可用則全線服務不可用，攻擊者只要擊垮這些服務就能“擒賊擒王”，所以安全上也需要考慮針對不同的資產使用不同等級的保護策略，根據BCM的要求，先將資產分類分級，劃分出不同的可用性SLA要求，然後根據不同的SLA實施不同級別的防護，在具體防護策略上，能造成平臺級SPOF（單點故障）的服務或功能應投入更高成本的防禦措施，所謂更高成本不僅指購買更多的ADS裝置，同時可能建立多災備節點，並且在監控和響應優先順序上應該更高。

  • Failover機制

    DDOS防禦不只是依賴於DDOS防禦的那4層手段，同時依賴於基礎設施的強大，例如做分流，就需要多點異地災備，mirror site & hot site & standby system，雲上的系統需要跨AZ部署，這些可以隨時切換的基礎。把雞蛋放在一個籃子裡會導致沒什麼選擇。

    基礎設施和應用層面建立冗餘是技術形式上的基礎，光有這些還遠遠不夠，需要有與之配套的DRP&BCP策略集，並且需要真實的週期性的演練，意在遇到超大流量攻擊時能夠從容應對。

  • 有損服務

    在應用服務設計的時候，應該儘量避免“單點瓶頸”，避免一個點被DDOS了整個產品就不好用了，而是希望做到某些服務即使關閉或下線了仍然不影響其他線上的服務（或功能），能在遇到需要棄卒保帥的場景時有可以“割肉”的選擇，不要除了“0”就是“1”，還是要存在灰度，比如原來10個服務線上，遇到攻擊時我只要保底重要的3個服務線上即可。

• 補充手段

DDOS攻擊的目的不一定完全是出於想打垮服務，比如以前在做遊戲時遇到玩家DDOS伺服器的目的竟然是因為沒搶到排在第一的房間，這種因素透過產品設計就可以根治，而有很多應用層DDOS只是為了達成另外一種目的，都跟上述4層防禦機制無關，而跟產品設計有關。所以防禦DDOS這事得看一下動因，不能盲目應對。

0x05 NIPS場景

---

ADS本質上是一個包過濾裝置，雖功用不同卻跟IPS有點相似，之前也提到有時候需要提供全站IPS的虛擬補丁功能，ADS裝置就可以充當這一角色，只是條目不宜多，只上有限的條目，下面的是NSFOCUS的ADS裝置的規則編輯介面，payload可自定義

一般安全團隊能力尚可的話，可以透過執行POC exploit，然後抓包找出攻擊payload的特徵，編輯16進位制的匹配規則，即可簡單的實現人工定製。

0x06 破防和反制

---

從安全管理者的角度看，即便是擁有完整的4層防禦機制也並非無懈可擊，號稱擁有400-500G防護能力的平臺是完全有可能被打垮的，完全的防護能力是建立在人、策略、技術手段都生效的情況才有的，如果這些環節出了問題，anti-ddos的整個過程可能會失敗。例如下面提到的這些問題：

• 超大流量攻擊時需要用到黑洞路由，但黑洞路由的IP需要由防禦方定義和聯動，“聯動”的過程就是向上遊裝置傳送封禁IP的通知，如果介面不可用，那麼此功能會失效，所以ISP級的防禦是有失效可能性的
• CDN雲清洗服務依賴於清洗服務商接管域名解析，如果雲清洗服務商本身的DNS不可用，也將導致這一層面的防禦失效，諸如此類的問題還有不少，這些抗D廠商自身並非無懈可擊
• ADS平時不一定串聯部署，但攻擊發生引流後一定是業務的前端裝置，假如這個裝置本身存在DOS的可能，即使是觸發了bypass也相當於防禦完全失效了，另一方面策略下發通常是ADS裝置跟管理節點互通，如果管理節點出現可用性問題，也將導致ADS防禦的一系列問題。
• 超大流量攻擊需要人工干預時，最基本的需求是安全或運維人員能在辦公網路連線到ADS的管理節點，能遠端運維ADS裝置，如果此時辦公網路的運維管理鏈路出現故障，不僅切斷了人員操作，還會把現場應急的緊張氣氛提升一個量級，使人更加手忙腳亂。

以上並不在於提供新的攻擊的思路，而在於向anti-ddos方案的制定者提供另類視角以便於審視方案中的短板。

0x07 立案和追蹤

---

目前對於流量在100G以上的攻擊是可以立案的，這比過去幸福了很多。過去沒有本土特色的資源甚至都沒法立案，但是立案只是萬里長征的第一步，如果你想找到人，必須成功完成以下步驟：

• 在海量的攻擊中，尋找倒推的線索，找出可能是C&C伺服器的IP或相關域名等
• “黑”吃“黑”，端掉C&C伺服器
• 透過登入IP或藉助第三方APT的大資料資源（如果你能得到的話）物理定位攻擊者
• 陪叔叔們上門抓捕
• 上法庭訴訟

如果這個人沒有特殊身份，也許你就能如願，但假如遇到一些特殊人物，你幾個月都白忙乎。而黑吃黑的能力則依賴於安全團隊本身的滲透能力比較強，且有閒情逸致做這事。這個過程對很多企業來說成本還是有點高，光有實力的安全團隊這條門檻就足以砍掉絕大多數公司。筆者過去也只是恰好有緣遇到了這麼一個團隊。