你查了自己那台對外開放的 DNS 解析器流量記錄，發現半年來被問了異常多次同一種查詢，問的人從來不是你平常的使用者，你的伺服器也沒被打壞過一次。真正倒楣的是查詢封包裡寫著的那個陌生 IP，它從頭到尾不知道你的伺服器存在，卻收到了你送出的所有回應。
攻擊方換了引擎，不再自己出力
Cloudflare 剛發布的 2026 上半年 DDoS 威脅報告裡，藏著一條比任何單一數字都扎實的曲線——半年之間，攻擊的來源結構明顯往同一個方向挪動。讀完這篇，你會知道反射（reflection）與放大（amplification）這兩個字具體指什麼機制、DNS 和 CLDAP 這類協定為什麼特別適合被拿來借力、以及這個轉向會怎麼改變邊界該濾的東西、容量規劃該假設的上限。
一次 1 Tbps 的攻擊，防守端在算什麼帳
這篇文章會反覆出現兩種攻擊分類：network-layer（網路層，對應 OSI 第三、四層）攻擊直接洗頻寬或連線資源，DNS flood、CLDAP flood、以及超過 1 Tbps 的那些攻擊，講的都是這一層；HTTP DDoS 攻擊則是應用層（第七層），用看起來合法的 HTTP 請求把伺服器的運算資源耗盡，Media, Production & Publishing 那個 14.2% 講的是這一層。兩者的度量單位不同，網路層習慣用流量（bps）或封包數（pps）算，應用層習慣用請求數算，報告裡的數字混著兩種分類引用，讀的時候要注意自己引用的百分比是哪一層——這個分類方式是通用的網路安全背景知識，不是報告獨創的定義。
Cloudflare 在報告裡給出的第一組數字，是規模本身。半年之內，超過 1 Tbps 的網路層攻擊，Cloudflare 一共擋下 935 次；而且這個數字不是均勻分布在半年裡——Q1 到 Q2 之間的季增幅度是 519%。報告沒有拆解 Q1、Q2 各自的次數，只給了半年總量與季增率這兩個數字，但單看這個成長速度，已經足以說明一件事：這種等級的攻擊不是穩定發生的背景噪音，是在半年之內明顯加速的趨勢。把 935 次平均攤開來看，等於半年裡差不多每天都有超過 5 次攻擊踩過 1 Tbps 這個門檻——這是把報告的半年總量除以半年天數得出的粗略平均，是作者自己的算術，不是報告直接講的日速率，而且這還只是「超過 1 Tbps」這一個高門檻以上的次數，門檻以下但同樣造成實際影響的攻擊次數遠遠更多。
把鏡頭拉遠一點看整體規模。這半年 Cloudflare 總共擋下 2,320 萬次網路層 DDoS 攻擊、29.64 兆次 HTTP DDoS 請求——後面這個數字大到很難直接感受，報告自己把它換算成比較好理解的速率：平均每小時約 5,343 次網路層攻擊，每天大約 12.8 萬次。這個速率是報告針對「網路層攻擊」單獨算出來的，不包含 HTTP DDoS 請求那個更龐大的數字。5,343 這個數字本身還是抽象——它要乘上多少個小時，才會變成 2,320 萬這個總量？拖曳下面的滑桿，看看半年累積下來到底是什麼量級，也順便驗證這兩個數字彼此對不對得上。
拖曳滑桿看半年累計 · 基準：報告換算的每小時 5,343 次
這條累計曲線本身沒有解釋攻擊怎麼發生，只告訴你發生得多快。真正需要回答的問題是：如果攻擊者沒有在半年內把自己控制的裝置數量翻五、六倍，這股額外的流量從哪裡冒出來？
殭屍網路不夠用了，還是不需要了
傳統對 DDoS 規模的理解，是一道很直覺的乘法：攻擊者能打出的流量天花板，等於他控制的裝置數量，乘上每台裝置能擠出的頻寬。這個模型底下，殭屍網路越大，攻擊上限越高；而養一個更大的殭屍網路需要時間——感染新裝置、維持指揮控制、躲過偵測與清剿，這些都不是能在半年內線性放大好幾倍的事。殭屍網路的組成不是攻擊者憑空生出來的，通常仰賴長期入侵累積的裝置池，或是跟別人租用、購買既有的殭屍網路容量，不管走哪條路，時間成本都不低——這幾句是作者對殭屍網路產業運作方式的假設，報告完全沒有談殭屍網路怎麼取得、擴張速度多快。順著同一個假設，這套舊模型過去幾年大致夠用，因為殭屍網路規模的變化被認為是季度甚至年度級別的漸進趨勢，防守端可以照歷史數據抓一個大致的容量安全邊界。反射／放大轉向打破的正是這個假設——攻擊上限不再受限於攻擊者自己的資源累積速度，而是受限於全世界有多少開放服務可以被找到，這是完全不同的成長曲線。519% 的季增幅度，用這套舊模型很難自然解釋：沒有理由相信攻擊者的殭屍網路規模，在一季之內就漲了六倍。
報告自己的 Insight 2 標題寫得很直接：「The attack-vector center of gravity shifted from botnet floods to reflection and amplification.」重心從 botnet flood 挪到 reflection 與 amplification，這是報告自己講的，不是作者的推論。DNS flood 占網路層攻擊的比例在往上衝、CLDAP flood 季增 580%、同時超大型攻擊的次數也在加速，都是這個重心轉移底下的具體數字。報告沒有講的是機制層面的「為什麼」：攻擊者不需要控制更多裝置，只需要找到更多可以被借用的第三方基礎設施；出力的不再是攻擊者自己買、自己養、自己藏起來的頻寬，而是別人架設、別人維運、但沒關好的伺服器——這一句機制解讀，是作者從報告的重心轉移與協定特性之間推出來的，報告本身沒有把這個機制講出來。
拖曳分隔線比較舊模型與新模型 · 2 張圖
拖曳中線比較兩種容量模型
舊模型：攻擊流量等於攻擊者自己控制的裝置頻寬；新模型：借用沒關好的公開伺服器，一個小查詢換來大量回應導向受害者，上限變成別人的基礎設施能出多少力。
反射與放大：一個小封包怎麼變成洪流
要理解上面這個推論為什麼站得住腳，得先搞懂反射（reflection）與放大（amplification）這兩個字具體在講什麼機制。報告完全沒有解釋這兩個詞——這一整段是通用的協定設計知識，不是這份報告本身的內容，讀到這裡的機制解釋，都不要當成報告的原文。
這套機制只靠兩個環節就能運作，中間不需要攻擊者自己控制任何一台第三方伺服器，他只需要知道這台伺服器存在、而且對外開放。第一個環節是反射攻擊者偽造受害者的來源 IP，把請求送給第三方伺服器；伺服器依照封包裡的來源欄位把回應送到受害者，而不是送回真正發出請求的一方——請求的方向，在這一步被反射走了。：來源被反射到別處。第二個環節是放大回應內容比請求本身大很多。查詢越短、換到的回應越大，攻擊者能用同樣的上傳頻寬，換出好幾倍甚至更多的下行流量打向受害者。：回應遠比請求大。能同時滿足這兩個條件的服務，通常是開放解析器沒有限制查詢來源、任何人都能問的公開 DNS 或目錄服務；正常情況下它該服務的是自己網域內的使用者，一旦對外全開，就成了誰都能借用的放大器。，或是像CLDAPConnectionless LDAP，跑在 UDP 389 埠、常見於 Active Directory 環境的無連線版 LDAP；因為不用先握手就能直接查詢，也常被不小心公開曝露，是這半年成長最快的放大向量之一。這樣的服務。
這兩個條件——來源可以被偽造、回應遠大於請求——在跑 UDP 的服務上特別容易同時成立。TCP 連線要先三向交握，伺服器會先跟聲稱的來源位址確認過一輪才開始傳資料，來源位址造假在這一步就會被抓包；UDP 沒有這道手續，伺服器收到查詢就直接把回應送往封包裡寫的來源位址，中間沒有人核對過這個位址是不是真的發出查詢的那一方。DNS 解析器與 LDAP 目錄查詢，剛好都是跑在 UDP 上的服務，這也是為什麼這半年成長最快的兩個攻擊向量，會剛好都落在 DNS 與 LDAP 的親戚身上——這件事報告的數字證實了結果，但機制上的原因，是協定設計本身決定的，不是報告告訴你的。DNS 查詢本身可以壓得很短，但如果請求的紀錄型別選得好，回應可以放大到查詢的好幾倍甚至更多，具體倍率因解析器設定與紀錄型別而異，這裡不引用任何精確倍率數字，因為那既不是這份報告的內容，也超出這篇文章能核實的範圍。順著這一步往回想，網路上其實有一套行之有年的防守手段——在網路邊界檢查封包的來源位址是否合理，不合理的來源直接丟棄，讓偽造來源這一步在源頭就做不到。這裡是作者的猜測，沒有來源佐證：這套做法或許還沒被普遍部署，一個可能的原因是它保護的是別人、不是部署者自己——花錢做設定，得到的好處主要落在下游可能被反射攻擊波及的第三方身上，誘因並不直接。這也連帶讓「直接封鎖攻擊者 IP」這種傳統做法失去意義：封包抵達的來源，本來就是合法的 DNS 或 LDAP 伺服器，不是攻擊者自己的位址，擋掉來源等於擋掉一台無辜的第三方服務，攻擊者本人完全不受影響。
DNS 與 CLDAP 為什麼特別好用
回到報告本身給的數字。DNS-based 攻擊整體占了這半年網路層活動的 34.3%，這是一個比較粗的分類，涵蓋所有跟 DNS 有關的攻擊型態。往下拆到子向量，DNS flood 這一項——單純用大量 DNS 查詢或偽造回應洗流量——占網路層攻擊的比例，從 Q1 的 25.7% 一路升到 Q2 的 40.0%，這是季對季的變化，不是半年平均。CLDAP flood 的成長更陡，季增 580%，一口氣衝進 Q2 的第三大攻擊向量，但報告沒有給出 CLDAP 在 Q1、Q2 各自占多少比例，只給了這個成長率本身。
這兩個向量會同時衝這麼快，用上一段的機制回頭看並不讓人意外。DNS 解析器是網路上數量最龐大、也最容易被設定成對外全開的服務之一——很多解析器原本只該回應自己網域內的使用者，但設定上一個疏忽，就變成任何人都能拿來借用的放大器。CLDAP 則是企業內部 Active Directory 環境常見的目錄查詢協定，同樣容易被誤設成對外可見；因為它是 LDAP 的無連線版本，跑在 UDP 上，具備上一段講的兩個條件，一旦暴露在外，濫用起來跟開放的 DNS 解析器沒有本質差別（這段把報告的百分比跟協定特性連起來，是作者的解讀，報告沒有逐條說明「為什麼」）。換句話說，這半年的曲線可以讀成一場資源競賽的轉向：攻擊者原本比的是誰的殭屍網路比較大，現在比的是誰先把網路上還沒關好的開放服務摸清楚。後者的擴張速度不受限於攻擊者自身的滲透能力，而受限於這個世界的基礎設施衛生狀況——這也是為什麼 519% 這種季增幅度，配上 DNS、CLDAP 這兩個協定名字，會同時出現在同一份報告裡。
邊界該濾什麼、誰該現在就緊張
目標分布也跟著這個轉向一起挪動。Media, Production & Publishing 這個產業別連續兩季蟬聯被攻擊最多的產業，占了全部被緩解的 HTTP DDoS 請求的 14.2%——這是 HTTP 層的請求占比，跟前面講的網路層攻擊向量是兩個不同的度量。土耳其升到第 3 大受攻擊目標國家，報告把時間點跟 7 月在 Ankara 舉行的 NATO 峰會並列描述，用的是時間相關的措辭，沒有直接斷言峰會是攻擊的原因，這裡照報告的謹慎程度保留，不幫它加碼成因果。政府部門的排名從第 29 名跳到第 9 名，報告形容這是 2026 年至今單一產業別最大的一次排名移動，同樣把它跟一個叫 Operation Epic Fury 的行動放在一起提，但沒有進一步定義這個行動是什麼。土耳其與政府部門這兩個案例還有一個共同點：報告用的都是時間並列的敘述方式，不是「證實原因」的敘述方式。這裡可以再往前推一步，但要先講清楚這步是作者自己走的、報告沒有走過：反射／放大攻擊的門檻低，找到開放服務、發出偽造查詢，不需要維護殭屍網路，這類攻擊在地緣政治熱點出現時，或許特別容易被臨時徵召使用。
| 目標 | 排名／占比 | 時間點與備註 |
|---|---|---|
| Media, Production & Publishing | 產業別第 1 名，連兩季；占 14.2% 全部 HTTP DDoS 請求 | Q1、Q2 2026 皆居冠 |
| 土耳其 | 受攻擊目標國家第 3 名 | 報告將時間點與 7 月 Ankara 舉行的 NATO 峰會並列，未斷言因果 |
| 政府部門 | 產業別排名第 29 名 → 第 9 名 | 報告稱為 2026 年至今單一產業別最大排名移動，與 Operation Epic Fury 並列 |
值得放在一起看的是，前面幾段講的 DNS、CLDAP 這類反射攻擊都是網路層——它們鎖定的是頻寬與連線資源，不特別在乎受害者是哪個產業；但 Media, Production & Publishing 連兩季蟬聯第一的，是 HTTP DDoS 請求這個應用層指標。兩件事不必然是同一群攻擊者、同一種動機，報告也沒有把它們綁在一起講，這裡刻意分開陳述，不把「向量轉向」跟「產業目標」焊接成單一敘事。
這個轉向對防守端意味著什麼，報告沒有直接寫出來，但順著機制可以推回去。如果攻擊流量的上限取決於全世界有多少開放解析器可以被借用，那自己維運的 DNS 或 LDAP 服務會不會被別人拿去打第三方，就跟自己會不會被打一樣，是同一個問題的兩面；盤點自己網域內有沒有對外全開、不該開的解析器與目錄服務，關掉不必要的開放查詢，是這條鏈最上游、也最便宜的一步，比事後在邊界擋流量划算得多，這週就能排進待辦。邊界過濾的假設也要跟著更新——反射攻擊的封包在協定層面本來就是「正常」的 DNS 或 LDAP 回應，格式合法、來源看起來也合法，只是方向被騙走了，單純看封包大小或協定種類過濾效果有限，得同時看流量模式：某個服務突然湧入大量非預期的回應流量，本身就是訊號，邊界規則值得從「協定＋大小」升級到「協定＋大小＋來源合理性」。容量規劃的假設同樣要換一套算法：舊模型算的是「對方控制的裝置數量乘以每台裝置的頻寬」，新模型要算的是「對方找得到的開放服務數量乘以放大倍率」，這兩個乘法的量級完全不同，用舊假設去抓新攻擊的規模上限，估出來的數字大概率是低估——跟上游頻寬供應商確認目前的清洗容量假設是用哪一套算出來的，值得排進這個月的待辦。報告沒有回答的問題還有一個：這半年的向量轉向，是攻擊者集體換了工具鏈，還是少數幾個大規模行動重複使用同一套反射基礎設施、把統計數字撐高？報告的粒度停在季度百分比，沒有拆到個別行動或個別殭屍網路家族，這篇文章也就只能停在報告給的粒度上。
The model：下次估攻擊規模上限之前，先想一句話——你在算的是攻擊者的頻寬，還是全世界還有多少台沒關好的伺服器。