DDoS防御是否提供攻击日志：服务商日志功能详解与查询指南
深夜機房警報響起時，螢幕上跳動的流量尖刺總讓人血壓飆升。熬過攻擊波峰後，老闆第一個問題永遠是：「誰在打我們？」這時才發現，原來不是所有CDN廠商的DDoS防護都願意給你完整攻擊日誌。這幾年測過全球二十多家服務商，有些給的數據細到能看清攻擊者指紋，有些卻像黑盒子般神秘。
記得三年前協助某電商平台應對持續勒索攻擊，當時用的某北美CDN號稱企業級防護，實際追查時技術支援卻支吾其詞：「我們系統自動攔截了，細節屬於核心演算法不便公開。」最後是靠著自建流量鏡像才抓到攻擊源IP段，過程耗費兩天黃金應變時間。這種經驗讓我深刻體會：防禦日誌的透明度，往往比防禦數值更關鍵。
目前頭部廠商做法涇渭分明。像Cloudflare企業版會在安全事件中心保留完整攻擊元數據，包括每個SYN Flood封包的來源IP與目標端口，甚至標記出攻擊工具特徵（如LOIC或Mirai變種）。而Akamai Prolexic更狠，連清洗前的原始封包都能透過專用API撈取，不過這功能要簽保密協定才開放。反觀某些主打低價的亞洲服務商，控制台永遠只顯示「已攔截XXX Gbps攻擊」這行單薄文字，技術團隊追問時只得到制式回應。
真正影響日誌深度的技術瓶頸在流量取樣率。面對T級別攻擊，全量日誌每分鐘產生TB級數據，多數廠商採用動態採樣技術。去年測試某廠牌時發現，當攻擊流量超過200Gbps，其HTTP請求日誌取樣率竟暴跌至1/1000，關鍵的CC攻擊序列根本無法重建。後來改用StackPath的邊緣運算節點，在攻擊觸發時自動啟用全流量捕獲模式，雖然成本飆升但成功溯源到攻擊租用商。
實戰建議分三層佈局：基礎防護層至少要求提供攻擊類型分佈圖與TOP源國；取證層需確認TCP標誌位異常記錄與HTTP異常請示碼留存週期（建議72小時以上）；司法溯源層則要預先簽署原始流量提取協定。某次幫金融客戶處理跨境DDoS勒索，正是靠Akamai提供的未經清洗原始pcap檔，配合IP地理位置關聯分析，鎖定東歐某數據中心的租用伺服器群。
查日誌最怕在控制台迷航。以阿里雲DDoS高防為例，攻擊詳情藏在「安全事件」→「攻擊分析」→「事件明細」三層選單下，還得手動切換時間顆粒度。更頭痛的是各家術語差異：AWS Shield Advanced把攻擊日誌整合在CloudWatch的「DDoSDetected」事件流，Cloudflare則藏在Security Events的Firewall Events分類。建議預先建立關鍵詞對照表，例如「清洗流量」對應「scrubbing center traffic」，「源伺服器」可能標示為「origin」或「backend」。
當發現日誌缺口時，可以考慮在邊緣節點部署輕量級抓包容器。某次用Gcore的邊緣函數服務，在攻擊觸發時自動執行tcpdump並上傳至S3儲存桶，雖然損失約3%性能，但抓到攻擊者使用偽造源IP的TCP分片重組漏洞。若預算有限，在F5 BIG-IP設備啟用本地化記錄檔，也能補足CDN廠商不提供的L4層會話資訊。
攻擊日誌的價值在攻防之外更顯珍貴。去年某遊戲公司用Cloudflare的攻擊日誌做機器學習訓練，建立出可提前10分鐘預測攻擊波次的模型，誤差率僅±7%。這些被標記的惡意流量特徵，最終成為防禦系統最鋒利的矛與盾。
評論: