Spamhausが報告した最近のルートハイジャックのいくつかに注目しました。こうしたハイジャックの試みの多くでは、明らかな悪意ある攻撃者が、未使用の自律システム番号（ASN）を利用していました。これらのハイジャックでは、攻撃者が宛先に向けて偽のAS_PATHを作成し、トラフィックを予期しない経路に誤って誘導しているようです。
偽造したAS_PATHを作成することで、ハイジャッカーはIDを隠そうとしながら、通常は意図しない場所へトラフィックを誘導しようとします。ハイジャッカーは、ボーダーゲートウェイプロトコル（BGP）プレフィックスのオリジンであることを装う可能性がある、ネットワークパスから十分な情報を盗み出すことができるからです。攻撃者は、このハイジャックされたルートを使用して、トラフィックを傍受したり、その他の悪意のある目的に使用することができます。
これらのケースに対するシンプルなソリューションがあります。それは、BGPピア自律システム（AS）が常に、アドバタイズされたルートの「最初のAS」としてネットワークを含むことの基本的な検証です。こうした安全対策がどの程度適切に実装されているかを把握するため、主要なネットワークにストレステストを行い、BGP実装について調査を行いました。これにより、私たちが学んだことを振り返ることができます。
パス内のありえないAS関係を詳しく調べると、アクターが偽のAS_PATHを作成しているという考えは裏付けられます。たとえば、Spamhausが報告したハイジャックの1つとして、フランスの通信会社Orange SAに属するプレフィックスを取り上げてみましょう。モノクルツールを使用すると、ハイジャックに関連するBGP UPDATEメッセージを簡単に見つけることができます。
➜ ~ monocle search --start-ts 2026-04-13T00:20:00Z --end-ts 2026-04-13T00:23:59Z --prefix 90.98.0.0/15 --collector rrc26 --json
{
"aggr_asn": null,
"aggr_ip": null,
"as_path": "48237 1299 199524 270118 17072 41128",
"atomic": false,
"collector": "rrc26",
"communities": null,
"local_pref": 0,
"med": 0,
"next_hop": "185.1.8.3",
"origin": "IGP",
"peer_asn": 48237,
"peer_ip": "185.1.8.3",
"prefix": "90.98.0.0/15",
"timestamp": 1776039612.0,
"type": "ANNOUNCE"
}
AS1299 (Arelion) は Tier 1 ネットワークであることがわかっています。つまり、パスの右側にあるすべての AS は、アップストリーム (顧客とプロバイダー) の関係を記述しています。これは、AS17072がAS41128のトランジットプロバイダーであることを意味し、AS170118はAS17072のトランジットプロバイダーであることを意味します。これらのネットワークについて詳しく見ると、次のようになります：
AS41128はOrange Franceに属する未使用自律システム番号です
AS17072は、主にメキシコに拠点を置くISPです。
AS270118はメキシコに拠点を置くホスティングプロバイダーです。
AS199524 はGcoreで、グローバルなピアリングプレゼンスを持つプロバイダーです。
上記のメッセージのASの順序は、未使用のオレンジフランスのASがメキシコのISPからトランジットを購入し、その後GcoreプロバイダーとTier 1プロバイダーにアップストリームされることを示唆していますが、これはまったく奇妙です。
別の例では、オリジンAS36429からプレフィックス47.1.0.0/16および47.2.0.0/16のハイジャックが報告され、AS_PATH「199524 270118 17072 13335 36429」にCloudflareのメイン自律システム番号である13335も含まれていました。これらのBGP UPDATEsの例を、Cloudflare RadarのMRT Explorerで見ることができます。
当社（Cloudflare、AS13335）は、Charter社が所有する、現在は使用されていないAS36429とは隣接性がないことを、権威をもって確認できます。つまり、これはハイジャッカーによる偽造経路で、Cloudflareの自律システム番号を、Gcore（AS199524）に向けて伝播されたアドバタイズの偽のアップストリームネットワークの1つとして含めたのです。さらに、Spamhaus氏は、すべてのハイジャックルートがシカゴのGcoreピアリングの背後にあるネットワークにつながっていたと正しく指摘しました。実際にはフォワーディング経路でメキシコのISPやCloudflareのネットワークを経由することはありませんでした。
このため、これらのパスは、最も左の共通AS（この場合はAS199524です）まで偽造されていると合理的に結論づけることができます。残りのパスはありそうもないと思われるためです。ここで起きていることは、ハイジャッカーによる特定の戦略の結果であると考えられます。次のステップなどです：
「パークされた」プレフィックスに対するBGPアナウンスメントをオリジンする
ハイジャッカー自身のローカル自律システム番号を含めずに、AS_PATHを完全に偽造する
これらのルートをGcore、AS199524にアドバタイズする
これらのハイジャックでは、Gcore（AS199524）が、ある顧客の自律システム番号に一致する最初のASの検証と適用をスキップしているようです。（この記事の後半で、これらのステップを省略する理由を説明します。）その結果、偽造されたパスが受け入れられ、ハイジャックされたプレフィックスは上流のプロバイダーとピアに伝播されます。
自律システムプロバイダ許可（ASPA）は、これらの偽造パスを無効にするのに役立ちますが、攻撃者は、RPKI-ROVが有効なオリジンAS、または正当なASPA上流ASを含めるだけで、それを回避することができます。これらの特定のハイジャックを阻止するには、BGPにすでに組み込まれている別の保護メカニズム、つまり、最初のASチェックと適用に依存する必要があります。
インターネット上でトラフィックをルーティングすることは、小包を配送するようなものです。荷物が出荷されると、その荷物を扱うすべての宅配便のログが残されます。BGPでは、これはAS_PATH（自律システムパス）と呼ばれ、そのルートのパスにある各ネットワークを追跡します。
BGPのAS_PATH属性は、パス選択に使用されます。この選択アルゴリズムは、目的地までの最適なホップリストを通過するルートを決定します。「ベスト」は複数の変数で定義されます。また、ループ防止にも使用され、ネットワークが自分のネットワークを既に通過したパスを受け入れないことを決定することができます。BGP UPDATE、ひいてはルートが通過するネットワークの記録を保持する以外に、AS_PATHは、オペレータが設定したルーティングポリシーによって検証することもできます。たとえば、予期せぬ影響を与えるBGPの異常を回避するために、所定のASを回避したり、意図的にルーティングしたりすることもできます。
BGPは信頼に基づいて構築されており、AS_PATHは簡単に操作できます。トラフィックを移動させるためのASプリペンドのような一見正当な理由から、トラフィックを人為的に引き寄せたり、オリジン攻撃を実行するために短縮するような悪意のある理由まで、様々です。
この2種類の悪意のあるBGP操作がどのように実行されるかを見てみましょう。
AS64506は、ルートオリジン認証（Route Origin Authorization）レコードでルートに暗号署名を行い、ルートオリジンのハイジャックを防ぎます。
AS64506はASPAオブジェクトを作成し、有効プロバイダーとしてAS64503のみを指定します
AS64505は、AS_PATHを操作して、AS64505を削除し、AS64506に発信します。
AS64502は最初のASを強制しない
ルートは、RPKI-ROV有効で、最短パスであり、トラフィックを効果的にハイジャックします。AS64506は、プレフィックスアドバタイズに有効なROAを指定することで、すべてを正しく行いました。また、唯一のプロバイダーであるAS64503からなるASPAオブジェクトも設定しています。
残念ながら、AS64505を実行しているハイジャッカーは、AS64506向けのトラフィックを引き付けることができます。顧客であるAS64501とそのプロバイダーであるAS64502がASPA検証を実行しても、無効なパスは見つかりません。なぜなら、パス「64502 64506」にバレーが存在しないからです。つまり、AS64505は、AS_PATHに自身の自律システム番号を含めることさえしない方法で、中間ASホップなしでAS64506であると偽装することができるのです。
既存のツールでこのハイジャックを防ぐ正しい方法は、AS_PATHの最初のASを強制することです。このルールを適用すると、AS64502はAS64505からのルートを適切にドロップします。
例2: AS_PATHを短縮してトラフィックを集中させる
AS64506には、AS64503とAS64505の2つのトランジットプロバイダーがあります。
AS64505は、トラフィック使用率に基づいて顧客にAS64506を請求します。
AS64505はパスから自身を削除し、ピアであるAS64504は最初のASを強制しません。
BGPパス選択アルゴリズムは、AS64501からAS64504経由のルートを最適なパスとして選択するようになりました。AS64506は、インターネットからのトラフィックを配信するために、プロバイダーであるAS64503とAS64505の両方に料金を支払います。しかし、現在、AS64505は、遠エンドの送信元からより短いBGPパスを提供しています。つまり、AS64505はAS64506に向けたすべてのトラフィックを処理し、その際に支払いを行いますが、AS64503は一切支払われません。
これらのBGPの脆弱性は、最初のASを受信したAS_PATH内のピアASと一致するように強制することによって非常に簡単に解決できます。
オペレータがBGPネイバーを設定する場合、相互接続しているネットワークのリモートASを設定する必要があります。AS_PATHの最初のASがこの値に一致しない場合、パスは操作されています。最初のAS適用手順は、RFC 4271のセクション6.3で、次のように非常に明確に概説されています。
「UPDATEメッセージを外部ピアから受信した場合、ローカルの
一番左（ポジションに関して
プロトコルメッセージのオクテット数) AS_PATH属性のASが
リクエストを送信したピアの自律システム番号に相当する
送られます。チェックがこれに該当しないと判断した場合、
サブコードがマルフォームドAS_PATHに設定されていなければならない。」
RFC 7606では、後にベンダーによるエラー処理の実装方法が修正され、不正なAS_PATHを含むルートはtreat-as-withdraw方式で破棄されるべきであると提案されています。これにより、ルーターはBGPセッション全体を中断することなく、不正な属性を持つ特定のプレフィックスをドロップすることができます。
現在のASPA草案では、最初のASの適用の重要性が明確に強調されており、不正なアナウンスによって十分なAS_PATH情報が不足しているパスはASPAが処理できないと述べています。AS_PATHの最初のASを強制することは、インターネットルーティングセキュリティに必須です。
私たちは、最初のASルールの違反に関する理論的な障害事例や過去の公表されたインシデントに縛られるのではなく、これらのAS_PATH違反がインターネット上でどの程度広く受け入れられるかを独自に測定したいと考えました。そのために、意図的にルールを違反した近隣へのBGPアナウンスを設定します。私たちが行った成果を以下に示します：
Tier 1 External BGP（EBGP）のネイバーへアドバタイズするために、1つはIPv4用、もう1つはIPv6用の2つのIPプレフィックスを割り当て
Tier 1の近隣へのテストプレフィックスアドバタイズを、Cloudflareが所有する非13335 自律システム番号（AS402542）で13335の前に意図的にプリペンド
たとえば、Genevaの通常のBGPセッションからAS1299にプレフィックスをアドバタイズしています。当社のローカルASはAS13335ですが、AS402542をAS_PATHの最初のASとして明確に含めています。
bryton@edge01.gva01> show configuration policy-options policy-statement 4-TELIA-ACCEPT-EXPORT term ADV-FIRST-AS-PROBE-CR-1695522
from {
community ANYCAST-ROUTE;
prefix-list fl_first_as_prober;
route-type internal;
}
then {
origin igp;
as-path-prepend 402542;
next-hop self;
accept;
}
bryton@edge01.gva01> show route advertising-protocol bgp <redacted_1299_ip> 162.159.82.0/24 detail | grep "AS path: "
AS path: 402542 [13335] I
この構成では、次のことを想定しています：
enforce-first-asを実行するネットワークは、RFC 7606 の撤回方式に従って、そのルートを黙って破棄します
First-asを強制しないネットワークはルートを受け入れ、インストールしてテストプレフィックスに向けて転送します
どちらの結果も、BGPパブリックルートビューに表示されます。当初の目標は、すべてのピアに向けて、アナウンスの際にFirst ASのルールに意図的に違反するプレフィックスの継続的なアナウンスを実装し、どのISPがFirst ASを検証するか、そしてそうでないISPをチェックするためのツールを皆に提供することでした。しかし、不正なBGP AS_PATHを受信した際にRFC 7606に公開されているガイダンスを実装しておらず、treat-as-withdraw動作ではなくBGPセッションをリセットするネットワークがまだ存在することがわかりました。つまり、Cloudflareへの実際のトラフィックに影響を与えることなく、First ASルールに違反する一連のアナウンスを安全に実装することはできないということです。
しかし、ポリシーが最も大きな影響を与えるネットワーク、Tier 1ネットワークについて詳しく見ることができます。これらのネットワークはインターネットのバックボーンを構成し、誰よりも最大のAS 顧客コーンを持っているため、これらのピアによるハイジャックや不正な経路は最も広範な影響を及ぼします。まず、エニーキャストプレフィックス 通常の 伝播、1.1.1.0/24 を調べてみましょう。提供することができます。
1.1.1.0/24の伝播現在、Cloudflareが直接隣接しているすべてのTier 1ネットワークから直接到達できます。
それでは、意図的に不正な方法で行われたプレフィックス162.159.82.0/24のアナウンスと比較してみましょう。
注：AS5511（Orange SA）はパブリックルートビューへの存在が限定的であるため、上記の写真にはされていませんが、当社のテストと測定の一部でした。
プレフィックスの伝播方法は、1.1.1.0/24 とは大きく異なる方法です。– Cloudflareからのアナウンスを直接受け入れるTier 1ネットワークの数は、はるかに少ないのです（この場合、AS402542がプリペンドされたAS13335からのもの）。以下は、前述のテスト基準に基づき、確認された結果です。
（無効なアナウンスを削除することで）First AS ルールを適用しているTier 1ネットワーク：
AS174（Cogent）
AS1299（Arelion）
AS3257（GTT）
AS3491 (PCCW)
AS5511（Orange SA）
AS6453 (Tata)
AS7018 (AT&T)
最初のASルールを実施していないTier 1ネットワーク（プレフィックスを受け入れてインストールする）：
このテストにより、Tier 1ネットワークの半分がFirst ASルールに違反するハイジャックに対して脆弱であるという厄介な現実が明らかになりました。
この測定調査ではTier 1ネットワークのみをテストしましたが、Tier 1以外のネットワークも数多くあり、First ASのルールを破っていることは間違いありません。
最初のAS違反テストに不合格となったTier 1ネットワークの大半がJuniper Networksルーターを実行しており、ピアのMACアドレスで識別されていることが判明しました。
これは、ベンダーのデフォルトの動作によって、First AS違反ベースの攻撃に対して「すぐに」ネットワークがどの程度安全であるかを定義することを浮き彫りにしています。デフォルトで保護されている人、されない人をより深く理解するために、BGPの実装とそのデフォルトのいくつかを見ていきましょう。
以下の表は、主要なルーティング/ネットワーキングベンダーとそのBGPポリシーを一覧にしたものです。ここで、「Yes」は、デフォルトでBGP実装がFirst ASを適用することを意味しており、これは良いことだと言えます。「いいえ」は、BGP実装がデフォルトで脆弱であることを意味します。
一部のベンダーからのデフォルトの適用がないことは、最初のASが外部BGP（EBGP）セッションに適用されない唯一の有効なユースケースであるインターネットエクスチェンジ（IX）ルートサーバーに起因する場合があります。
ルートサーバーは、ファブリック上のピア間でルートを透明に（AS_PATHに追加せずに）配布する役割を担います。これにより、ネットワークがファブリックに参加するたびに、ピアは新しいBGPセッションを設定する必要がなくなり、ルートサーバーだけでピアリングできるようになります。
実際には、ほとんどの本番ネットワークでは、透明性のあるIXルートサーバーでないネイバーとのセッションが、透明性のある近隣よりもはるかに多くなっています。ネットワーク内のすべてのピアに対して手動で「first-as」を有効にするよりも、わずかなルートサーバーセッションで「noenforce-first-as」を設定する方がはるかに理にかなっています。
「デフォルトで安全」のアプローチは、最初のAS違反から保護するには最適ですが、ベンダーに長年守られてきたデフォルトを変更するように説得するのは、一般的に困難な道のりです。ベンダーは、ルートを正常に受信するために「ファーストパーティを強制しない」設定を必要とするIXルートサーバーのBGPセッションに影響を与えないように、これを慎重に行う方法を導入する必要があります。
お客様の協力でより安全なインターネットルーティング：最初のASを適用
攻撃者は、意図的にAS_PATHを偽装し、BGPセキュリティメカニズムを回避します。RPKIベースのASPAパス検証でさえ、パスがオリジンAS以外のすべてが完全に削除され、ASPAが無効化するものが何もないような偽造されたオリジンハイジャックから保護することはできません。
良いニュースは、これらのケースに対する緩和策をすでに持っていることです。最初のASがBGPピアASと一致していることを確認し、常に適用することができます。提供した上記の表の対応する「ドキュメント」列を参照してください。IXルートサーバーネイバーに直面するものを除き、外部BGP（EBGP）セッションにFirst ASを適用することは安全でなければなりません。
ネットワーク事業者の方は、今すぐルーターにFirst ASを適用して、ネットワークとインターネット全体を保護してください。
ルーターベンダー、またはBGP実装の選択がデフォルトでFirst ASを強制する場合は、すでに安全であり、First AS違反を拒否する必要があります。
協力することで、こうした種類のハイジャックからインターネットをより安全なものにすることができます。