昨天也許有些人無法連至特定的網站、臉書或Amazon,這是因為在世界協調時間(UTC)6月24日上午10點半(約台北時間下午6點半)時,所有透過Verizon自治系統AS701轉運的流量都先被導至美國賓州的一家小ISP,造成流量擁塞甚至是消失,波及Cloudflare全球約15%的流量,造成Cloudflare許多網站客戶的流量中斷,也影響臉書及Amazon流量。

全球網路是由不同的自治系統(Autonomous System)所組成,它們之間利用邊界閘道協定(Border Gateway Protocol,BGP)來互連,BGP負責打造網路地圖,規畫最快的路徑,但有時會因配置錯誤而產生BGP路由外洩,例如一個AS將違反政策或範圍的BGP路由資訊傳播給其它的AS,不管是這次或是日前歐洲流量被導至中國電信的事件,都是因BGP路由外洩而造成的意外。

Cloudflare的網路工程師Tom Strickx說明,此次路由外洩的始作俑者為美國賓州的一家小型ISP業者DQE Communications,該公司在自家的AS33154自治系統上使用了BGP優化工具,該工具能提供更具體的路由,例如導航到白金漢宮比導航到倫敦更為具體。

DQE把這些路由傳送給客戶Allegheny Technologies的自治系統AS396531,AS396531再把路由傳送到身為網路轉運供應商的Verizon(AS701),Verizon理應要能阻擋此一路由外洩,反之Verizon卻接受了這些路由,也讓經由AS701的流量都採用了DQE所提供的「更具體」的路由,才造成了網路大塞車。

Strickx說,此次的意外雖是因BGP路由外洩而造成,但帶來具體路線的BGP優化則讓整個情況更加惡化。

此外,Strickx還指責Verizon未作好基本的防護機制,因為有許多方式可以避免這類的BGP路由外洩,包括在一個BGP期間限制所接收的前綴數量,假設前綴數量超過閥值便可關閉該期間;或者是導入基於網路路由註冊( Internet Routing Registry,IRR)的過濾機制,以阻止其它網路接受這些出錯的具體路線,但Verizon一項都沒做,明顯過於草率與怠惰。

至於Cloudflare則推薦各界採用資源公鑰基礎設施(Resource Public Key Infrastructure,RPKI)框架,該框架可過濾來源網路與前綴數量,同時建議拒絕那些太過具體的路由,假設Verizon採用了RPKI,此事也不會發生。

在上次歐洲流量被導至中國電信的事件中,甲骨文安全分析師Doug Madory曾經批評中國電信並未採取路由保障措施,不但廣為傳播外洩的路由,也未能在事件發生時即時偵測與修復,導致錯誤存在超過2小時,不過,這次Verizon不但重蹈覆轍,還讓意外延續超過8個小時。


Advertisement

更多 iThome相關內容