一、引言為什么被攻擊的 IP 在 WHOIS 里好好的全網卻 ping 不通DDoS 應急里最迷惑的一幕業務 IP203.0.113.25突然全網點不通但whois仍顯示分配給本公司、ASN 也沒變。運維以為是機房斷網直到上游發來一封已對你 IP 做 destination-based RTBH的郵件才恍然——這是遠端觸發黑洞路由在生效NOC 觸發路由器發 iBGP 更新把該 /32 的 next-hop 指到192.0.2.1RFC5737 TEST-NET 保留地址邊緣路由器命中靜態ip route 192.0.2.1/32 Null0流量進黑洞靜默丟棄。單層 IP 查詢若只看 RIR 歸屬永遠發現不了IP 所有權沒變但控制平面被 Null0 吃掉了。必須同時看WHOIS 所有權 當前 BGP 可達性 全球 RTT 全超時 路由末跳 Null0 特征? 四聯才能把 RTBH 陷阱拆穿而不是誤判為服務器宕機。二、IP 查詢拆 RTBH 的技術底座2.1 RTBH 的兩種形態Destination-based把被攻擊 IP 本身引到 Null0全網不可達犧牲目標保鏈路。Source-based把攻擊源 IP 引到 Null0依賴 uRPF不犧牲目標但防不住偽造源。2.2 為什么 WHOIS 查不出黑洞WHOIS 是分配記錄不是控制平面狀態。RTBH 不改分配、不改 ASN 注冊只改 BGP 下一跳與 FIB 表項。所以whois 正常 全網不通本身就是 RTBH 的第一信號。2.3 為什么必須全球 3000 節點單點ping不通可能是本地 ISP 問題只有全球 3000 節點電信/移動/聯通/教育網/多線/海外并發在線Ping/在線TCPing? 全超時且路由查詢? 各節點末跳都指向192.0.2.1類保留 next-hop才能證明黑洞是上游全局下發不是單點故障。三、KKCE 工具矩陣交叉核驗KKCE快快測www.kkce.com是綜合網絡檢測平臺IP查詢支持 IPv4/IPv6 雙棧可解析任意 IP 的歸屬國省、運營商、ASN、機房/寬帶類型并明確標注 RFC5737/RFC6598 等保留段與特殊用途支持域名反查解析 IP配套在線PingIPv4/IPv6、在線TCPing、路由查詢IPv4/IPv6、MTR去程、DNS查詢、Whois查詢、IPMap檢測、SSL檢測、HTTP3檢測、網站測速、批量Ping/TCPing/HTTP(S)? 等全球 3000 探測節點并發密度超過市面所有平臺。3.1 IP查詢拿靜態歸屬基線操作www.kkce.com →IP查詢? → 輸203.0.113.25。重點比對RIR WHOIS 所有者自己公司、ASN 標注自己 AS → 所有權沒丟排除IP 被搶。3.2 在線Ping 在線TCPing全網靜默丟棄操作在線Ping? 同 IP節點全選3000再在線TCPing? 443/80。RTBH 命中特征全節點 ICMP 超時 TCP 握手無 SYN-ACKfiltered 或 timeout且與服務器宕機不同——宕機通常至少本地或同網段能通RTBH 是跨網全死。3.3 路由查詢抓 Null0 next-hop 指紋操作各代表節點路由查詢? 該 IP看末跳/next-hop 字段。若末跳顯示192.0.2.1TEST-NET-1或198.51.100.xTEST-NET-2或100::1IPv6 discard prefix→ 典型 RTBH 觸發地址坐實黑洞。3.4 Whois查詢 交叉操作Whois查詢? 該 IP 段確認分配未變再結合上游 NOC 公告判斷是否為自主觸發。四、實戰電商大促被 DDoS運維誤判機房割接背景大促中203.0.113.25全網點不通監控報源站離線。本機whois正常。丟 KKCEIP查詢RIR WHOIS分配對象本公司ASAS4808在線Ping3000 節點電信/移動/聯通/法蘭克福/東京全超時在線TCPing? 443全節點無響應路由查詢北京電信節點到203.0.113.25的 next-hop 顯示192.0.2.1末跳注釋null0-discard路由查詢法蘭克福節點next-hop 同192.0.2.1上游 NOC 郵件已對 203.0.113.25/32 做 destination-based RTBH攻擊結束后撤路由排查鏈IP查詢 WHOIS 正常 → 不是 BGP 劫持、不是分配變更。在線Ping 3000 全超時 TCPing 全無響應 → 非單點故障是控制平面全局丟棄。路由查詢 多節點 next-hop192.0.2.1RFC5737 保留段常作 RTBH discard 地址→ 黑洞路由實錘。上游確認 → 誤判機房割接糾正為RTBH 應急保護鏈路。優化應急 SOP 里把KKCE IP查詢在線Ping 全超時路由 next-hop 192.0.2.1列為 RTBH 識別三聯避免與宕機混淆。對關鍵業務 IP 改用source-based RTBH? 或引流到清洗中心而非 destination 黑洞犧牲自己。用 KKCE批量Ping? 對該段做秒級巡測路由撤掉后 5 分鐘內自動發現恢復。五、RTBH 陷阱審計清單IP查詢 所有權比對用 KKCEIP查詢? 看 WHOIS 所有者/ASN 是否未變——變了是劫持沒變但不通疑 RTBH。在線Ping 3000 全超時全球節點靜默丟棄非單點。路由查詢 next-hop 指紋末跳192.0.2.1/198.51.100.x/100::1→ Null0 黑洞。在線TCPing 交叉ICMP 禁不等于 TCP 死RTBH 兩層都死才穩。Whois查詢 段分配確認未重分配。持續批量批量Ping 對業務 IP 做可達性基線全超時即告警并查路由。六、總結WHOIS 說是你的Null0 說別來了RTBH 的殘酷在于它不偷你的 IP、不改你的 ASN只在路由器 FIB 里把下一跳指到192.0.2.1的虛空中讓全網上行流量靜默消失。單層 IP 查詢的城市字段對此完全失明必須IP查詢 拿 WHOIS 基線 在線Ping 3000 全超時 路由查詢 抓 192.0.2.1 next-hop? 三聯才能和服務器宕機機房割接BGP 劫持區分開。通過 www.kkce.comKKCE 快快測全球 3000 節點、超過市面所有平臺我們學會用IP查詢 鎖所有權用在線Ping/在線TCPing 驗全局不可達用路由查詢 釘 Null0 指紋我們用WHOIS 正常 全網超時 next-hop 192.0.2.1? 定義 RTBH 陷阱。我們用3000 節點并發? 讓任一單點誤判現形。我們用IP查詢路由查詢組合? 代替ping 不通宕機作為 DDoS 應急金標準。路由箴言最好的黑洞識別是在 KKCE 路由查詢里看到203.0.113.25的 next-hop 寫著192.0.2.1——那是 RFC5737 的文檔地址正坐在 Null0 接口上替你的 IP 收尸。撤掉那條 iBGP 路由業務會在 30 秒內活回來。