BGP威脅再現：奈及利亞的一家ISP意外劫持了網際網路
74分鐘裡，流向谷歌和Cloudflare服務的流量繞經俄羅斯並進入中國的GFW防火牆系統。
2018年11月12日，奈及利亞一家小型網際網路服務提供商SP在更新其網路基礎設施時犯了個錯誤，將全球最大科技公司谷歌的流量切斷了74分鐘，凸顯出網際網路架構中的一個關鍵漏洞。
為理解該事件發生的原理，我們需要了解網際網路路由的工作機制。假設使用者在瀏覽器中輸入網址 Hypothetical.Domain.com 並按下回車鍵，使用者的計算機便建立了一個Web請求，並將該請求傳送至 Hypothtetical.Domain.com 伺服器。這些伺服器放置的位置可能與使用者不在同一個國家和地區。因此，使用者的網際網路服務提供商 (ISP) 必須確定怎樣將使用者的Web瀏覽器請求通過網際網路路由至正確的伺服器。為維護自身路由表，ISP和網際網路骨幹公司採用了名為邊界閘道器協議 (BGP) 的一套機制。
BGP是一個動態路由協議，能夠在變化發生時自動更新路由表。網際網路上任意兩個節點之間往往不是直接連線的，A點到B點之間的連線通常有多條路徑可供選擇。BGP的任務就是確定到達任意給定目的網路的最佳（最短）路徑，並據此對路由器做出更新。該路徑會隨路由器的掉線和上線而變更。BGP自動處理所有這些路由器變動情況。
網際網路由大量自治系統 (AS) 組成，目前準確的AS數量為63,954個。每一個AS都由網際網路編號分配機構 (IANA) 分配一個自治系統號 (ASN) 。ISP至少擁有1個ASN，通常都有多個。谷歌這樣的大公司一般都維護有自身的邊界路由基礎設施和自有ASN。
自制系統與相鄰的對等節點 (peer) 形成連線，通過這些連線將自身所知路由（所謂的“網路字首”）廣而告之。鄰居節點繼續向其他鄰居轉發路由通告，以便在網際網路骨幹網上傳播這些路由。最終，通過這些路由通告，位於北美的ISP能夠了解到通向澳洲某臺Web伺服器的路由。
起點：奈及利亞網際網路交換中心
於是，2018年11月12日究竟發生了什麼呢？所有的一切都源於名為奈及利亞網際網路交換中心 (IXPN) 的一家機構。網際網路交換中心 (IXP) 很常見，尤其是在發展中國家。這些機構為地區性ISP互聯提供中心位置，使他們能以較低的頻寬消耗共享資料。如果沒有IXP，地區性ISP就可能無法直接互聯。這意味著地區性ISP之間的流量有可能繞遠路，甚至先出個國再繞回來。
IXP也能作為連線遠端公司和服務的單點連線點。IXPN事件中，谷歌與合作的奈及利亞ISP維持有對等連線，允許從他們的網路直接連向谷歌的服務。谷歌向其奈及利亞ISP對等節點宣告自身網路字首(路由)，類似於幫他們構建了一條直達高速公路，不需要再繞道歐洲的鄉間小路。
這些對等連線協議和路由通告通常只為ISP及其客戶的利益而設，所以他們會採用路由過濾器來防止字首通告意外跑出自身網路範圍。如果沒有設定路由過濾器，使用BGP的ISP路由器就會繼續向網際網路上其他鄰居傳播路由，有可能改變通往谷歌的全球網際網路流量路由方式。
下一站：中國
2018年11月12日國際標準時間21:13，奈及利亞 MainOne Cable 公司正在對其路由基礎設施進行常規維護。維護過程中，該公司不小心錯誤配置了路由過濾器，導致212個谷歌字首和數個Cloudflare字首被通告給了其他BGP鄰居。
作為MainOne的BGP對等節點，中國電信接受了該路由通告，並將之傳遞給了自己的鄰居節點。俄羅斯Transtelecom電信公司也接受了該路由通告並繼續傳向自己的其他對等節點。截至目前，該路由通告已在網際網路上蔓延，很多自制系統都開始接受了。
74分鐘裡，全球通往谷歌和Cloudflare服務的絕大多數流量都流經俄羅斯、中國，再到奈及利亞的MainOne。Cloudflare很快發現了該問題，並更新了其路由拓撲以進行緩解。但試圖訪問谷歌服務的很多使用者卻因為其連線了通向了中國的GFW而遭攔截。其他使用者即便能夠訪問谷歌服務，也因為連線被路由到奈及利亞繞了一圈，而遭受了異乎尋常的延遲等待。
為什麼這個問題不可小視？因為該事件凸顯出網際網路架構中的一個關鍵漏洞。BGP依賴信任系統。對等節點預設鄰居節點通告的是準確的路由。一旦某個鄰居開始通告不屬於自己的網路字首，連線攔截和中間人攻擊便成為了可能。奈及利亞一家小小的ISP一不小心配錯了路由過濾器，都能中斷通往IT巨頭的網路流量。一場惡意的協同BGP劫持能造成什麼影響，大家可以自行想象。
不過，解決辦法還是有的。資源公鑰基礎設施 (RPKI) 採用加密簽名來驗證BGP路由通告，就像網站採用證書驗證一樣。路由來源驗證 (ROV) 能夠確認網路字首通告來自實際的擁有者。但不幸的是，所有通告的網路字首中僅有13%採用RPKI，且只有不到1%的自治系統會驗證路由通告。如果網際網路服務提供商和其他網際網路骨幹網參與者還不盡快開始採納這些標準，那下一場BGP劫持就不會是個意外而可能是更糟糕的情況了。
資源公鑰基礎設施(RPKI)：
https://www.apnic.net/get-ip/faqs/rpki/#what
路由來源驗證(ROV)：
https://blog.apnic.net/2018/06/19/measuring-the-adoption-of-rpki-route-origin-validation/