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的攻擊都可以使鏈路擁塞。#p#

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防御主要是消除這些網絡方案中內在的單點瓶頸。#p#

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這事得看一下動因，不能盲目應對。#p#

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的大數據資源(如果你能得到的話)物理定位攻擊者

陪叔叔們上門抓捕

上法庭訴訟

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