BGPハイジャック事件　-Youtube通信を占拠する方法

概要

事件の背景（何が起きたのか？）

  1. YouTubeのブロック試み：パキスタン政府の命令で、国内プロバイダ（パキスタン・テレコム）が自国内でYouTubeを見られないよう、YouTubeのIPアドレス帯（/24）に対する「偽の経路（ブラックホール経路）」を内部で作った。
  2. 誤広告（BGPハイジャック）：その偽の経路情報を、誤って上位プロバイダ（PCCW）へBGPで広告してしまった。
  3. 世界中へ拡散：BGPは「より細かいPrefix（/24）の経路を優先する」というルールがあるため、世界中のインターネットトラフィックがYouTubeの本物サーバーではなくパキスタンへ集中し、YouTubeが世界中でダウンした。

登場する重要単語・技術

この「誤ったBGP広告を信用して広めてしまった」対策として登場するキーワードが以下の３つ。

  • IRR（Internet Routing Registry）
    • 各AS（プロバイダ等）が「自分がどのIPアドレス帯を広報する権利を持っているか」を登録しておくデータベース。
    • 限界：誰でも登録できるなど認証が甘く、偽装を完全には防げなかった。
  • RPKI（Resource Public Key Infrastructure）
    • IRRの弱点を補うために作られた「暗号技術（電子署名）を使ったBGP経路の認証基盤」。
    • APNICやJPNICなどの地域インターネットレジストリ（RIR）が発行する証明書を使って、IPアドレスの所有権を証明します。
  • ROA（Route Origin Authorization）
    • RPKIの仕組みの中で作成される「経路証明書」データのこと。
    • 「このIPアドレス帯（例：208.65.152.0/22）を広告して良いのは、ASXXXX（YouTube）だけである」という正しいペアを電子署名付きで定義します。

なぜRPKI/ROAがあれば防げたのか？

上位プロバイダ（PCCW等）が RPKI Validation（ROV: Route Origin Validation） を導入していれば：

  1. パキスタンから「YouTubeのIPアドレス」のBGP広告が届く。
  2. RPKIデータベースと照合し、「このIPを広告して良いのはYouTubeのASだけで、パキスタンのASは許可されていない（Invalid）」と即座に判別できる。
  3. 誤ったBGP広告をその場で破棄（Drop）できたため、世界中へ被害が広がるのを防げた。

さらに深いVersion………………………………

Q.そもそも、どうやって偽の経路を作るの？

A.「通常のスタティックルートとBGPの再配送（アナウンス）」の設定によって偽の経路を作っていた。

▼パキスタンが実際に行った「偽の経路」の作り方
パキスタン・テレコムは、RTBHやFlowspecなどのセキュリティ技術を使ったわけではなく、ルーターの「通常のスタティックルートとBGPの再配送（アナウンス）」の設定ミスをやらかした。

１．国内向けの破棄設定（Null 0行き）をルーターに入れる
・パキスタン政府から「YouTubeをブロックしろ」と言われたエンジニアは、国内のユーザーがYouTubeに行けないようにするため、パキスタン・テレコムの国境ルーターに次のような設定を入れた。
・「208.65.152.0/24（YouTubeのIP）宛てのパケットが来たら、すべて Null 0（ゴミ箱・破棄）に送れ
・（※これにより、パキスタン国内のルーターにとっては、YouTube宛ての通信は自社内で消滅する「ブラックホール」になった）

👆これはIGP（OSPFやIS-ISなど）によって、Null経路が配られていた。末端のルータがYoutube宛てを受信すると、Null経路を持っている当該ルータへ運んでいた。すべてのルータにYoutube宛ては自身のルータ内でNullで破棄して！というわけではない。

２．その「破棄用の経路」を、あろうことか外（BGP）に広告してしまった
・本来、この Null 0 行きのルートはルーターの内部だけで使うもの（外部に教えてはいけないもの）。
・しかし、設定ミスかテストの意図で、パキスタン・テレコムはこの「YouTubeの経路はうち（AS17557）にあるよ！」という情報を、通常のBGPの経路情報（NLRI）としてそのまま上位プロバイダ（PCCW）に流して（アナウンスして）しまった。

👆再配布のミス！IGPで広告していたNull経路をAS外にもフィルタリングを怠ったせいで広告してしまった。それによって、インターネットに広がってしまった。

３．世界中がそれを「本物の道」と勘違いした
・上位プロバイダから見れば、送られてきたBGP情報は「普通のYouTubeへの経路」に見える。
・そのため、「YouTubeの細かいプレフィックス（/24）の道がパキスタンから来たちょっと近道だ！」と世界中のルーターが勘違いし、世界中のYouTube宛て通信がパキスタンテレコムへ向かって吸い寄せられてしまった。

👆当時、Youtubeは/22で運用されていた。これは正規のプロバイダから取得した正規のアドレス範囲。一方、パキスタンテレコムの/24はNull用のダミーの広告だが、当時は広告の正当性を確認するプロセスがおざなりであったため、論ゲストマッチの原則に基づき、より長いプレフィックスをもつパキスタンのダミー経路が優先されてしまった。

Q.どうやって復旧させたの？

A.この2008年の事件の最もドラマチックなところは、「パニックになったパキスタン側がすぐにミスに気づいて自主的に直してくれなかった」という点にある。そのため、被害が拡大する中でYouTube自身が驚きの「カウンター攻撃」に出て事態を収束させた。

▼実際の復旧・解決までのプロセス
パキスタン・テレコム側はパニックや連絡の不備もあり、すぐに誤った広告を引っ込められなかった。そこで、被害を直接受けていたYouTube（Google）側が次のようなウルトラCの対抗措置を取った。

１．YouTube側が「さらに細かいプレフィックス（/25）」で対抗広告を出した
・パキスタンが流していたのは /24 。
・これに対抗するため、YouTubeはさらに細かく分割した /25（/24 の半分のサイズ） の正当な経路情報を世界に向けて急遽広告した。

２．ロンゲストマッチによる奪還
・BGPの「より長いプレフィックスを優先する」という鉄則を利用し、パキスタンの /24 よりもさらに細かい YouTube自身の /25 の方を世界中のルーターに最優先させた。
・これにより、世界中のトラフィックが強烈に本物のYouTubeへと引き戻された。

３．上位ISPによる強制遮断
・その後、香港の上位プロバイダ（PCCW）が事態を重く見て、パキスタン・テレコムからの不正な広告を強制的に削除（Withdraw）したことで、約2時間越しに完全に幕を閉じた。

Q.プレフィックスを大きくするとどうなるの？

プレフィックスを大きくするとどうなるのか。。。大きくして対応できるなら、なぜ最初から/25で広告しなかったのか？
A.プレフィックスを大きくすると、広告するエントリー数が増大する。そのため可能な限りプレフィックスは小さめにして広告したいが、そうするとパキスタン側に負けてしまうので、ウルトラCとしてプレフィックスを大きくした

▼具体例

例えば、10.0.0.0/8という１つの広告を10.0.0.0/9にする場合は何個のプレフィックスになるのか？

ShellScript
10.0.0.0/8 →①10.0.0.0 ~ 10.255.255.255
00001010.00000000.00000000.00000000 ~ 00001010.11111111.11111111.11111111


10.0.0.0/9 →①10.0.0.0 ~ 10.127.255.255 / ②10.128.0.0 ~ 10.255.255.255
00001010.00000000.00000000.00000000 ~ 00001010.01111111.11111111.11111111
00001010.10000000.00000000.00000000 ~ 00001010.11111111.11111111.11111111


10.0.0.0/10 →①10.0.0.0 ~ 10.63.255.255 / ②10.64.0.0 ~ 10.127.255.255 / ③10.128.0.0 ~ 10.191.255.255 / ④10.192.0.0 ~ 10.255.255.255
00001010.00000000.00000000.00000000 ~ 00001010.00111111.11111111.11111111
00001010.00000000.00000000.00000000 ~ 00001010.01111111.11111111.11111111
00001010.10000000.00000000.00000000 ~ 00001010.10111111.11111111.11111111
00001010.11000000.00000000.00000000 ~ 00001010.11111111.11111111.11111111

以上のように、プレフィックスが小さくなるほど、集約できるアドレス数も減ってしまう。その結果より多くのエントリーを登録することになる。

▼プレフィックスが増大した時のエントリ数が何個になるかの計算方法

増えた分のエントリ数＝２（変更後のプレフィックス長-変更前のプレフックス長）

例１：/8 から /10 にした場合
2(10-8)=4

例２：22/ から /25 にした場合
2(25-22)=8

Q.RPKI（ResourcePublicKeyInfrastracture）とは？

RPKIを一言で言うと「このIPアドレスは、本当にこのプロバイダ（AS）が名乗っていいものか？」を暗号学的なデジタル証明書で証明・検証する仕組み。従来のBGPには「身分証の確認プロセス」がなかったため、誰でも「うちはYouTubeの経路を持っているぞ！」と嘘（あるいは間違い）を言えてしまう。そこに「身分証（証明書）」を導入するのがRPKI。

▼RPKIの全体フロー（証明書はどうなっていて、動検証するのか？）

1. 事前準備：ROA（証明書）の登録と保管
・誰が作るの？：IPアドレスの正当な持ち主（例：YouTube）が、地域インターネットレジストリ（APNICなど）を通じて「我が社はこのAS番号でこのプレフィックスを広告してよい」という証明書（ROA：RouteOriginAuthorization）を発行してもらう。
・どこに保管されるの？：このROA（証明書データ）は、インターネット上にある「RPKIリポジトリ（公開サーバー）」という専用のデータベースに、常に誰でもダウンロードできる状態で保管されます。

2. ルーター側の準備：キャッシュサーバーとの連携（ここがポイント！）
・個々のルーターが直接インターネット上のリポジトリから1つずつ証明書を都度ダウンロード・検証しているわけではない！
・キャッシュサーバー（RPKI Validatorなど）と呼ばれる専用のサーバーが、インターネット上のRPKIリポジトリからすべての正当なROA（証明書の一覧）をあらかじめ一括でダウンロードし、手元にキャッシュ（保存）しておく。
・ルーターは、そのキャッシュサーバーから定期的に「正当な証明書のリスト」を受け取って手元に持っておく

ShellScript
#キャッシュサーバとの接続設定社内に置いたキャッシュサーバー（例: 10.0.0.50）とポート323（または3323など）で接続する
router bgp 65001
  bgp rpki server tcp 10.0.0.50 port 3323 refresh 300
  
#ルーターがちゃんとキャッシュサーバーから証明書を受け取れているか確認
Router# show ip bgp rpki servers

＊キャッシュサーバは基本的に社内に配置する。で、ルータはそのキャッシュからROIを検索する
＊キャッシュサーバーが世界中から複雑な証明書（ROA）を集めて複雑な暗号検証をすべて肩代わりし、「このIPとこのASの組み合わせは Valid（有効）」というシンプルな判定用リスト（軽量化されたデータ）だけを、定期的にルーターに配給（同期）している

3. 実際のBGP受信と検証のフロー
ここで、隣のルーター（ネイバー）からBGPの経路情報が流れてくる。
①BGP経路の受信
　・ネイバーから「このIPアドレス（/24など）を、このAS番号が持っているよ」という通常のBGP経路情報が届く。（※ここには証明書はくっついていない！ただの経路の文字情報）
②手元のリスト（キャッシュ）と突合する
　・ルーターは、受け取った経路情報の 「IPプレフィックス」 と 「広告してきたAS番号」 を取り出す。
　・そして、あらかじめ手元に持っているROA（証明書のリスト）と照らし合わせる。
③暗号学的な検証（バリデーション）
　・「手元の証明書リストの中に、このAS番号がこのIPを広告してよいというデータ（電子署名付き）は存在するか？」をチェックする。
　・署名の正当性（改ざんされていないかなど）は、証明書を発行した上位機関の公開鍵を使って数学的に検証される。
　＊なお、署名の正当性は事前にキャッシュサーバが肩代わりしてくれているので、ルータはリストへの有無を見ればいいだけ。
④判定（Valid / NotFound / Invalid）
　・一致する正当な証明書があれば Valid（有効）。
　・リストになければ NotFound。
　・範囲やAS番号に矛盾があれば Invalid（無効：偽物・ミス） として、自動的にその場で破棄する。

Q.ROA(RouteOriginAuthorization)の取得～検証のフローは？

ROAの取得では、WebのSSL/TLS証明書（Let’s Encryptなど）でよくある「その場しのぎのファイルを置く」のではなく、「インターネットの公的な階層構造（レジストリ）そのものを使って正当性を証明する」という仕組みになっている。
▼取得～検証フロー
1. ROA（証明書）の取得・発行フロー
Webの証明書発行（CSRを生成して…という手順）とは異なり、ROAは「IPアドレスの割り当てを受けている公的な組織のポータルサイト」で直接作成・発行する。

  1. IPアドレスの正規の割り当てを受けていることの証明
    • 大前提として、そのIPアドレスブロックは、APNIC（アジア太平洋地域）やJPNICなどの上位レジストリから、正規にお金を払って割り当てを受けている自社のリソースである必要がある。
  2. 証明書発行機関（LIR / NIR）のポータルへログイン
    • 自社が管理するIPアドレスを管理しているレジストリ（日本であればJPNIC経由、または上位のLIR/ISP）の専用管理ポータルにログインする。
      ＊管理ポータルにログインしたユーザとIPアドレスはバックエンドで対応づけられているので、このポータル内で偽のIPのROAを要求することはできない。
  3. ROAの発行申請（パラメータの入力）
    • ポータル画面で、以下の情報を指定して「この内容で証明書を作ってくれ」と申請。
      • 対象のIPプレフィックス（例: 208.65.152.0/22）
      • 許可する最大プレフィックス長（例: /24 までなら分割して広告してもいいよ、という上限）
      • 広告を許可するAS番号（例: AS15169）
  4. RPKIリポジトリへの自動登録
    • 申請ボタンを押すと、レジストリ側のシステムが電子署名（デジタル証明書＝ROA）を自動生成し、インターネット上に公開されている公式の RPKIリポジトリ（公開サーバー群） に自動で登録されます。
    • （※ここで「私たちがこのIPをこのASに広告させていいという証明書」が世の中に誕生する）

2. ルーター（キャッシュサーバー）側での検証フロー
世の中に公開されたROA（証明書）を、キャッシュサーバーがどうやって拾って検証するのか、おさらいも含めて全体の流れ。

  1. キャッシュサーバーが証明書を回収
    • 社内のキャッシュサーバー（Validator）が、インターネット上の公的RPKIリポジトリから、世界中の正当なROAファイルを定期的に一括ダウンロード。
  2. 暗号学的な検証（ここで公開鍵が使われる）
    • 「公開鍵による検証」はまさにここで行われる。
    • キャッシュサーバーは、ダウンロードしたROAに付いている「電子署名」を、上位のレジストリが持つ「公開鍵」を使って数学的に検証する。「途中で改ざんされていないか」「有効期限内か」「本当に正当な機関が発行した証明書か」をここで厳しくチェックする。
  3. 安全なリスト（VRP）の作成
    • 検証に合格した「安全な証明書データ」だけを綺麗に整理し、合格リスト（VRP：Valid ROA Payload）としてキャッシュサーバー内に保持する。
  4. ルーターでの突合判定
    • ルーターはキャッシュサーバーからその合格リストを受け取っておき、ネイバーから新しいBGP経路（IPとAS番号）が届くたびにリストと突合し、「Valid（合格）」か「Invalid（不合格・偽物）」かを一瞬で判断する。

タイトルとURLをコピーしました