淺析大規模DDOS防護架構-應對T級攻防

時間 2019-12-05

標籤淺析大規模 ddos 防護架構應對攻防欄目網絡爬蟲简体版

原文原文鏈接

ayazero · 2015/09/18 0:57前端

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

0x00 導讀

0x01 DDOS分類

在講防護以前簡單介紹一下各種攻擊，由於DDOS是一類攻擊而並非一種攻擊，而且DDOS的防護是一個能夠作到相對自動化但作不到絕對自動化的過程，不少演進的攻擊方式自動化不必定能識別，仍是須要進一步的專家肉眼判斷。web

網絡層攻擊算法
- Syn-floodshell
  利用TCP創建鏈接時3次握手的「漏洞」，經過原始套接字發送源地址虛假的SYN報文，使目標主機永遠沒法完成3次握手，佔滿了系統的協議棧隊列，資源得不到釋放，進而拒絕服務，是互聯網中最主要的DDOS攻擊形式之一。網上有一些加固的方法，例如調整內核參數的方法，能夠減小等待及重試，加速資源釋放，在小流量syn-flood的狀況下能夠緩解，但流量稍大時徹底不抵用。防護syn-flood的常見方法有：syn proxy、syn cookies、首包（第一次請求的syn包）丟棄等。數據庫
- ACK-flood後端
  對於虛假的ACK包，目標設備會直接回復RST包丟棄鏈接，因此傷害值遠不如syn-flood。DDOS的一種原始方式。api
- 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方案的制定者提供另類視角以便於審視方案中的短板。