Cloudflare 分享了更多關於最近一次持續 25 分鐘的邊界網關協定 (BGP) 路由洩漏的細節，該洩漏影響了 IPv6 流量，導致明顯的擁塞、丟包和大約 12 Gbps 的流量遺失。BGP 系統可協助在稱為自治系統 (AS) 的不同網路之間路由數據，這些系統透過網路上的較小網路將資料傳送至目的地。該事件是由路由器上意外的政策配置錯誤引起的，並影響了 Cloudflare 客戶以外的外部網路。
當自治系統 (AS)違反無谷路由策略，錯誤地將從一個對等體或提供者學習到的路由通告給另一個對等體或提供者時，就會發生 BGP 路由洩漏。因此，流量會被傳送到原本不打算承載它的網路。這通常會導致網路擁塞、丟包或使用次優路徑。當使用防火牆過濾器僅允許來自特定提供者的流量通過時，這些流量會完全丟棄。
第四類路由洩漏圖，來源：Cloudflare
這家網路巨頭表示，這起最新事件與2020 年 7 月發生的事件非常相似 ，並列出了防止此類事件再次發生的措施。擬議措施包括增加更嚴格的社區為基礎的出口保障措施、對策略錯誤進行 CI/CD 檢查、改進早期檢測、驗證 RFC 9234 以及促進 RPKI ASPA 的採用。
以下根據BleepingCompute報導內容，整理造成此次事故的配置錯誤原因，並提供可在企業網路與大型 ISP／CDN 環境實際落地的防範措施。
這次 Cloudflare 的配置錯誤：
- 路由匯出政策（export policy）錯誤配置：原本 Cloudflare 想要阻止 Miami 裝置廣播 Bogotá 的 IPv6 prefix，但修改政策時「移除了特定前綴清單（prefix-lists）」，導致匯出政策變得「過度寬鬆」。
- JunOS / JunOS EVO 中 route‑type internal 匹配範圍比預期更廣：移除 prefix-lists 之後，政策開始匹配所有 iBGP 來源的 IPv6 路由，使得本來應只在 Cloudflare 內部傳遞的路由被廣播到外部 BGP 鄰居。
- 導致 Type 3 / Type 4 route leak（違反 valley-free routing 規則）：Cloudflare 不該把從一個 peer 學到的路由再傳給另一個 peer 或 provider，但因政策錯誤而導致此行為，造成全球網路流量繞經 Miami，並導致 12Gbps 以上的丟包與壅塞。
如何防範這些「配置錯誤」導致的 route leak？以下用 Cloudflare 的事件作為背景，完整分析可採取的防護手段。
- 強制使用明確的 prefix-list，而非依賴隱含的 route-type 規則
- 問題：Cloudflare 的事故源於移除 prefix-list 後，政策過度寬鬆，錯誤接受所有 iBGP 來源的 IPv6 路由並外洩。
- 防範
―所有 export policy 必須依賴明確的 prefix-list，禁止使用涵蓋範圍模糊的 match type。
―任何涉及「限制廣播範圍」的變更，都必須透過 whitelist 方式實現，而非 blacklist。
―prefix-lists 不得被空白或清除，否則 export policy 無法正確控制。
- 引入 Route Policy CI/CD 驗證（Cloudflare 事故後也採用）
- 問題：Cloudflare 表示將加入 CI/CD checks 來提早阻擋政策錯誤。
- 防範
―建立 BGP Policy 測試套件：自動檢查是否存在過度寬鬆的 export policy；測試 iBGP → eBGP 匯出是否被阻擋
―政策變更必須經過 pipeline 自動測試後才能上線
―禁止直接在生產環境 router 上即時套用未經驗證的政策
- 加入 community‑based export safeguards（Cloudflare 官方措施）
- 問題：Cloudflare 事件後明確強化，更嚴格的社群標籤（BGP community）約束匯出策略。
- 防範
―對所有 iBGP 來源路由加上「不可對外廣播」的 internal‑only 標籤
―export policy 必須嚴格允許只有特定 community 才能廣播到外部
―若沒有特定 community 檢查 → 一律拒絕匯出
―使用 well‑known communities（如 no-export、no-advertise）作第二層保護
- 採用 RPKI ASPA 及 RFC 9234 防反射（Cloudflare 事故後列為必做）
- 問題：Cloudflare 的後續防範措施之一是：推動 RPKI ASPA（Autonomous System Provider Authorization），以及落實 RFC 9234 - BGP Route-Leak Protection。
- 防範
―啟用 ASPA 驗證：防止 AS 把來自上游或同儕的路由誤傳給其他上游，能自動偵測 & 阻擋像此次的 Type 3/4 leak。
―使用 RFC 9234 的 Only-To-Customer (OTC) 安全路由屬性：
―確保路由只向客戶端廣播，不會向 peer/provider 廣播。
- 多層路由異常偵測與自動回滾（Cloudflare 事件後採用）
- 問題：Cloudflare 增強早期警示系統與異常監控，以便在 route leak 早期即時攔截。
- 防範
―監控 AS path 異常跳躍（例如意外出現太長的 AS_PATH）
―監控 prefix 第三方觀測（RouteViews / RIPE RIS）與自身公告差異
―異常即自動：回滾 last-known-good config、停用 automation pipeline以及阻擋所有非既定 prefix 的 export
- 強制實施「反向驗證」：iBGP 端不允許任意 export
- 問題：事故中 iBGP 來源路由被錯誤判定為可 export，並廣播到 peers/providers。
- 防範
―iBGP → eBGP 的 export 必須被完全預設拒絕（default deny）
―只允許：明確的 customer prefixes以及明確的 service prefixes
―使用 route-type + community + prefix-list 三重驗證避免誤放
- 兩階段部署策略：shadow commit + dry‑run
- 問題：Cloudflare 的事故來自 自動化路由變更直接在實體 router 套用。
- 防範
―第一階段：shadow deployment：在 router 內驗證新政策是否會 export 多餘的 prefix
―第二階段：dry-run：僅模擬 export，不真的廣播
―第三階段：受管推送到生產 router：需經過人工 + 自動化雙重 approve
- 設定 fail-safe policy：若缺 prefix-list → export policy 直接 fail
- 問題：Cloudflare 因 prefix-list 被移除導致 export 過度寬鬆。
- 防範
―設定「no prefix-list = deny all」策略
―任何 export policy 缺少關鍵 prefix-list → router 拒絕 commit
―JunOS / IOS-XR 都可透過 commit scripts 實作此保護
資料來源：https://www.bleepingcomputer.com/news/security/cloudflare-misconfiguration-behind-recent-bgp-route-leak/