作者：騰訊安全應急響應中心
原文鏈接：https://mp.weixin.qq.com/s/rZunI6Uxyks2TbSarsqR8A

導語

美國時間10月4日中午，Facebook公司網絡出現重大故障，故障持續了6個小時后才恢復。官方給出的故障原因，簡單來說是一次誤操作引發了連鎖反應。

（復雜點就是：在例行網絡維護中，發送的一條命令無意中關閉了其全球骨干網的所有BGP連接，在其DNS服務器與內部網絡不通后觸發了內部機制，自動禁止DNS服務所在網段的BGP路由播布，而這又導致故障范圍進一步加劇，并對故障恢復帶來極大困難）。

這是Facebook創立以來最嚴重的一次網絡訪問事故，在這起故障中，我們又看到了BGP的身影（我為什么要說“又”）。

BGP是什么？

BGP協議，全稱Border Gateway Protocol（邊界網關協議），是組成我們當今Internet的一種去中心化的自治系統間的動態路由協議，它允許Internet上不同AS（自治系統）之間自動交換IP路由信息和可達信息，最主要功能在于控制路由的傳播和選擇最好的路由，并且還具備冗余備份、消除環路的特點。

該協議，最初是在1989年1月第12次IETF會議的午餐期間，Yakov Rekhter、 Kurt Lougheed 在 Len Bosak 的幫助下設計的，并寫在了三張餐巾紙上【圖1】。

圖1

后來于1989年6月份正式發布了RFC1105（BGP-1），之后升級到了RFC1163（BGP-2）、RFC1267（BGP-3）和RFC1771（BGP- 4），并一直沿用至今（BGP- 4）。

目前全球有18W+多個AS，通過BGP協議連接構建成了我們整體的互聯網，這些AS號的使用者包括有各大ISP和內容提供商、云服務提供商、互聯網企業、教育機構等等。

圖2

BGP安全問題有哪些？

雖然BGP協議在互聯網中起著至關重要的作用，但是其安全性卻很脆弱，一般BGP互聯的2個AS之間，對于接收的IP前綴路由缺乏有效的認證機制（國內個別運營商會基于白名單做限制），導致無條件地接收或傳播鄰居AS的路由。

BGP的這種脆弱性，在遭受惡意攻擊或人為變更配置錯誤時將會變得很突顯，會對國家、運營商和企業帶來極大威脅。

BGP路由的安全威脅，可以大致分為兩大類：BGP路由劫持（包括IP前綴劫持、IP子前綴劫持、AS路徑篡改）、BGP路由泄露。

前者更多是有目的性、惡意的攻擊行為，后者多數發生在網絡變更時的配置錯誤。【圖3】列出了近10多年來的一些BGP重要安全事件。

圖3

1. BGP路由劫持

首先講講IP前綴劫持，攻擊者向外宣告自己擁有受害者的IP前綴路由（前綴與受害者AS號通告的一樣），該路由通過全球網絡傳播，其他 AS 將使用其本地策略選擇合法源 AS 的路由還是攻擊者AS 發起的虛假路由。這種劫持方式，攻擊者一般只能劫持到該IP前綴的部分流量。

更進一步地，攻擊者可以將劫持的IP前綴改成比受害者AS宣告的更明細（即IP子前綴劫持），最終其它AS將根據BGP最長匹配原則，優先選擇攻擊者宣告的虛假路由。這種方式，攻擊者正常可以劫持絕大部分該子前綴的流量。

如【圖4】，2008年2月24日，巴基斯坦為了國內言論管制封殺YouTube網站，電信局劫持了國內到YouTube對應IP子前綴208.65.153.0/24的訪問（比YouTube全球宣告的208.65.153.0/22粒度更細），但由于電信局上游運營商PCCW將該劫持路由也通告了到全球，導致YouTube有至少2/3的互聯網流量被劫持到巴基斯坦，致使其全球用戶訪問中斷了2小時。

圖4（截圖來自外部）

2. BGP路由泄露

路由泄漏是一種在現網中比較常見的路由事件，一般出現于ISP的錯誤配置，對外宣告了本不應該由該AS宣告的IP前綴路由，它能夠造成 BGP 路由發生嚴重錯誤、進而導致互聯網部分中斷或擁塞。

路由泄露，并不涉及虛假的IP前綴路由宣告，肇事者向其它AS泄露出去的路由是“合法"存在的，只是它違反了AS之間的路由策略，結果導致泄露出去的路由涉及IP的流量被重定向。

如【圖5】，2012年11月6日，因印尼運營商Moratel在其路由器的錯誤配置，導致Google的8.8.8.0/24的BGP網段路由被泄露到了Moratel上游運營商PCCW，并且被PCCW擴散了錯誤的BGP路由（由于PCCW的本地路由策略）到其網內和互聯AS，結果導致大量訪問Google的互聯網流量經過PCCW后先繞行到Moratel以至于無法處理，其中香港是影響重災區，因為PCCW是香港的主要電信服務商。

圖5（截圖來自外部）

這里也總結羅列了下BGP安全問題可能造成的影響：

1) BGP路由劫持

a. 流量被“黑洞”，正常訪問中斷

b. 流量被中間人監聽或攻擊，或重定向到虛假網站以竊取數據

c. IP被用于進行垃圾郵件活動

d. 正常用戶訪問路徑變長，網絡延遲增加

2) BGP路由泄露

a. 泄露者AS網絡流量擁塞，引發網絡丟包

b. 造成互聯網局部鏈路擁塞，引發網絡丟包

c. 泄露者AS無下一跳路徑，導致流經該AS的流量中斷

3) 其他

拒絕服務攻擊（DoS）：惡意或無意導致的配置錯誤的BGP表內容，將流經該AS的流量錯誤地指向其它AS網絡，可能引發受害者AS網內擁塞或流量中斷

如何監控和防范

目前業界提出的解決方案主要有兩類：一是采集現網數據進行分析、網絡主動探測等方式，對IP前綴劫持進行檢測、定位和緩解，雖然檢測與緩解技術目前具有較高的實用性，但現網數據仍存在區域和時間維度的局限性，漏報與誤報依然無法避免，且難以預防安全事件的發生。

二是通過基于數字簽名、安全證書和加密技術等路由認證的安全機制，彌補BGP協議認證缺失的缺陷。

1. IP前綴檢測

企業可自建監測平臺，通過獲取全球BGP路由更新信息，然后選取本企業的IP前綴路由與自己AS網絡路由發布情況進行對比，主動監控感知BGP路由異常情況。包括監控BGP路由劫持（判斷BGP路由信息中AS_PATH的起源AS是否正確）、BGP路由健康度（比如判斷單位周期內的路由更新類型、數量）。

監控方案，涉及到的全球BGP路由更新數據源，可通過多種方式獲取，【圖6】羅列了幾種從外界拉取的方式，這些方案均存在一些缺陷，最明顯的就是實時性和覆蓋率問題。

圖6

若無自建監測平臺能力，可以使用商業的BGP路由監控平臺，比如BGPMon。

企業在監測到BGP路由被劫持后，可反制的手段目前比較有限，包括向ISP宣告更明細的IP子前綴BGP路由，或者聯系相關涉及ISP協助處置。

此外，作為用戶、企業、教育機構等組織網絡接入的提供商（ISP），也有義務針對接入到其網絡的AS設置路由宣告規則，限制其宣告的IP前綴，避免惡意或錯誤配置導致的錯誤IP前綴BGP路由被宣告ISP網內，并傳播到全球。

2. 全路由認證安全機制

近年來，比較推廣的方案是RPKI &ROV、 BGPsec。

2017年10月，國際互聯網工程任務組（IETF）和美國國家標準與技術研究院（NIST）、美國國土安全部（DHS）等機構共同啟動了一個名為安全域間路由（SIDR）的聯合項目，明確提出應對 BGP 協議進行保護以抵御BGP路由攻擊威脅。

“SIDR ”項目主要分為三個基本組成部分：資源公鑰基礎設施 (RPKI)、BGP 源路由驗證（ROV）和 BGP 路徑驗證 (BGPSec)。

RPKI是一個分級的認證系統，RPKI存儲有路由來源授權（Route Origin Authorization，ROA），它是一個IP地址前綴與BGP起源AS綁定簽名的記錄。互聯網中的路由器可以利用ROA來執行路由來驗證（ROV），識別并丟棄來自未授權AS的“無效的”BGP路由宣告，以此防止IP前綴劫持攻擊。

不過RPKI&ROV，只能防范如BGP路由劫持中 IP前綴、子前綴劫持這2種起源AS欺騙的簡單攻擊，像AS路徑篡改、BGP路由泄露等場景，則需要采用BGPSec方案。BGPsec旨在補充BGP源路由驗證的不足，當它與ROV結合使用時，可以防范各種針對BGP的路由劫持攻擊。

原理是路由宣告過程中，路由器從它的鄰居AS收到的IP前綴路由宣告消息進行簽名，簽名內容作為路由消息的BGPsec_Path屬性傳播給其它鄰居AS，當路由器接收到帶有BGPsec_Path屬性的IP前綴更新路由時通過檢查簽名判斷該路由的AS_Path路徑是否正確，若錯誤的話直接丟棄，并不廣播給其鄰居AS。

騰訊的一些實踐

針對外界BGP路由劫持的潛在風險，騰訊安全平臺部宙斯盾團隊聯合網絡平臺部運營團隊，搭建了騰訊BGP路由劫持監測平臺。

在方案設計上，考慮到監控準確率、時效性以及后續的擴展能力，源數據采集基于網平團隊在現網機房的部署BMP（BGP Monitoring Protocol ，BGP監控協議），通過獲取對應的BGP路由更新信息進行路由劫持監控。

監測平臺上線至今，已在現網多次監控到局部發生的騰訊網段被異常劫持或運營商側異常變更問題。

2021年4月16日晚上，Vodafone在印度的AS（55410）出現BGP路由泄露事件，錯誤地宣告了30000多個BGP網段路由，導致全球多個網絡和企業受影響，騰訊BGP路由劫持監測平臺，也及時感知發現了異常，有部分騰訊BGP網段被AS 55410劫持，并及時進行了處置，最終未影響到業務。2021年4月16日晚上，Vodafone在印度的AS（55410）出現BGP路由泄露事件，錯誤地宣告了30000多個BGP網段路由，導致全球多個網絡和企業受影響，騰訊BGP路由劫持監測平臺，也及時感知發現了異常，有部分騰訊BGP網段被AS 55410劫持，并及時進行了處置，最終未影響到業務。

寫在最后

其實在導語所述故障中除了BGP之外，還有另外一個基礎協議的身影--DNS，作為互聯網的基礎設施，BGP和DNS的安全理應得到更多的重視。

這類故障不是第一次出現，也必然不會是最后一次出現。希望從頂層設計到底層實現，從業界到廠商，能共同攜手更好的提升這里的安全能力。如同這個文章也許受眾會很窄、瀏覽量會很低，但是我們仍然希望更多的朋友能看到。

參考資料： https://queue.acm.org/detail.cfm?id=2668966

Paper 本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/1744/