一、引言为什么被攻击的 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 秒内活回来。