インシデント・レビュー - 9月7日のSpectrum障害の背後にあるもの。BGPハイジャック博士か、それともBGPミス氏か？
RPKIチェックだけではBGPルートハイジャックを防げない
2021年9月10日
翻訳: 竹洞 陽一郎
この記事は米Catchpoint Systems社のブログ記事 Incident Review - What Was Behind the September 7 Spectrum Outage: A Case of Dr. BGP Hijack or Mr. BGP Mistake?の翻訳です。
Spelldataは、Catchpointの日本代理店です。
この記事は、Catchpoint Systemsの許可を得て、翻訳しています。
2021年9月7日 16:36(UTC)に、オハイオ州、ウィスコンシン州、ケンタッキー州を含む米国中西部のSpectrum社のケーブルTVのユーザに障害が発生しました。
同社のブロードバンドおよびテレビサービスを利用しているユーザは、ソーシャルメディアを利用して、この障害に迷惑しているとの声を上げました。
Really @Ask_Spectrum needs to get this outage together. I’ve had to reconnect to the VPN for work 20 times in 90 minutes. At this point I can’t get anything done. This is unacceptable and how you lose customers. @GetSpectrum
— excessively black (@dmoore_uknow) September 7, 2021
An average night of watching TV with @Ask_Spectrum, very cool. pic.twitter.com/VgcusIAdAu
— Brett Larter (@BrettLarter) September 3, 2021
18:11頃（UTC）に全てが解決し、ユーザへのサービスが再開されました。
Spectrumの調査についてのファクトチェック
Spectrum Customers we are aware of an Internet service interruption in the Midwest including Ohio, Wisconsin and Kentucky. Technicians are working to restore services as quickly as possible. We apologize for the inconvenience.
— Ask Spectrum (@Ask_Spectrum) September 7, 2021
Spectrumは、障害の原因となっている問題の種類について曖昧にしていました。
調査の結果、BGPルートハイジャックの可能性があることがわかりました。
BGPルートハイジャックとは、ある自律システム（AS）が、他のASに割り当てられているネットワークのオリジンであると主張することです。
ハイジャックが偶発的なものであれば、サービスの妨害につながります。
意図的に行われた場合は、最悪の場合、他のASが機密情報を盗み出す可能性があります。
何が起こったのかを理解するために、イタリアのミラノ・インターネット・エクスチェンジ（MIX）にあるRIPE NCC（RIPE Network Coordination Centre）が配備しているRISルート・コレクター「rrc10」が収集したデータを調べてみましょう。
最も近いRIBスナップショットを見ると、Spectrum（AS10796）が690のネットワークをアナウンスしており、そのほとんどがバックボーン（AS7843）を経由していることがわかります。
16:30から18:30（UTC）の間にrrc10 collectorが提供した更新ファイルから、KHS USA（AS398994）が、Spectrumが発信していた690のネットワークのうち449のネットワークをアナウンスし始めたことがわかりました。
これにより、障害が発生しました。
KHSがルートのアナウンスを停止した18:11 UTCまでは、ほとんどのRISピアでルートが確認されていました。
さて、これはBGPハイジャック博士か、それともBGPミス氏か？
このハイジャックの特徴の1つは、攻撃を受けたASのど真ん中で始まったことです。
KHSは、Spectrum AS自身（AS10796）を介してSpectrumネットワークをアナウンスし、Spectrumバックボーン（AS7843）がそれを野放しにしていました。
Spectrum AS自身（AS10796）とSpectrumのプロバイダの1つであるTata communications（AS6453）を経由してアナウンスされたルートはごく僅かでした。
他のオブザーバビリティ・プラットフォームとは異なり、Catchpoint社はクラウド・プロバイダにホストされていないため、クラウド・プロバイダが自社のソリューションに影響を与えるインシデントが発生しても、当社には影響がありません。
当社のプラットフォームは継続して動作し、何か問題を検出したらすぐにアラートを出します。
もうひとつの奇妙な点は、KHSがハイジャックの前後でネットワークをアナウンスしていなかったことです。
これは、RIPE Statが提供するBGP Updateのアクティビティ・ウィジェットからもわかります。
この障害は、Spectrum社の実験によって引き起こされたものかもしれません。
また、同様のシナリオは、キャリア内部のセキュリティ脆弱性を悪用して、キャリアのルータとの間でBGPセッションを開く方法を見つけた場合にも起こり得ます。
これにより、経路が乗っ取られ、意図的に障害が発生する可能性があります。
過去にも、このようなケースがありました。
ネットワーク管理者の教訓
いずれにしても、今回の事件からネットワーク管理者が得られる教訓はいくつかあります。
ルータへのBulletproof Securityの適用
SpectrumのケースはBGPハイジャックではないかもしれません。
いずれにしても、認識されていないソースが勝手にBGPセッションを立ち上げて、自由にネットワークをアナウンスできるようなことは絶対にあってはならないことだと言えます。
MANRS（Mutually Agreed Norms for Routing Security）には、今回のような事象の拡大を防ぐための有用なルールが用意されています。
自動制御の設定
ネットワーク管理者は、顧客がアナウンスすることを許可されていないネットワークに関連する経路アナウンスを削除するために、自動制御を設定する必要があります。
このレベルの制御がSpectrum社のルータに欠けていたのではないかと思われます。
そうでなければ、AS 398994が449のSpectrumネットワークに属するルートをハイジャックすることはできなかったでしょう。
しかし、トランジットASにとっては、単純な制御だけでは十分ではありません。
もし、AS10796がアナウンスできるネットワークのリストを設定しているASであったとしても、ハイジャックの野放し状態を止めることはできなかったでしょう。
実際、AS10796はネットワークの元々の所有者であり、ハイジャックされた449のネットワークのうち431のネットワークを含むほとんどのルートをRPKIで署名していました。
RPKIチェックで無効とされたルートを削除することは、ハイジャックの拡散を緩和するための解決策になったはずです。
しかし、それだけではハイジャックそのものを食い止めることはできません。
BGPの問題への積極的な対策
最後になりますが、ネットワーク管理者は、今回のような事象に対して、直ちに対策を講じる必要があります。
ネットワーク管理者は、24時間365日体制のBGP監視ツールを活用すべきです。
Catchpointでは、ハイジャックが発生した場合、わずか数秒でお客様にお知らせしています。
BGPセキュリティへの積極的な取り組みについて理解を深める
ハイジャックやルート・リークなどのBGPセキュリティ問題に関する5つのブログ・シリーズでは、より多くの実例や技術的な深堀りを紹介しています。