DocsDigest
一覧へLanguage: EN
OpenAICloudflare2026/06/03 17:00

Enforcing the First AS in BGP AS_PATHs

要点だけを先に読めるように短く再構成したセクションです。

元記事
OpenAIClaude

Quick Digest

要約

要点だけを先に読めるように短く再構成したセクションです。

openaijamodel: gpt-5-mini-2025-08-07

BGP AS_PATHのFirst AS検証を強制化

bgpas_pathfirst-asrpkiasparfc7606route-security

Key Points

  • AS_PATH偽装
  • First AS強制
  • RFC7606適用推奨

Summary

最近の複数のハイジャック事例では、攻撃者が未使用ASNを悪用してAS_PATHを偽装し、トラフィックを迂回・傍受していました。攻撃者は自身のASNをAS_PATHに含めず、RPKI/ASPAで有効に見える起点を作ることで検出を回避します。本稿は、左端（First AS）がピアのremote-asと一致するかを検証し、不一致の場合はRFC7606に従って当該プレフィックスを個別にwithdraw（treat-as-withdraw）する運用を強く推奨します。

Key Points

  • 攻撃手口: 未使用ASNを含む完全に偽装されたAS_PATHを広告し、正当な経路を上書きする。攻撃者は自分のASNを含めないことがある。
  • RPKI/ASPAだけでは回避できないケースが存在する（正当な起点ASNを含めれば検証を通ることがある）。
  • RFC4271はFirst ASチェックを明記、RFC7606はmalformed AS_PATHを個別にwithdrawする運用を推奨する。
  • 実測: CloudflareはAS402542を左端に付けるプローブを実施し、多くのTier‑1がルートを受け入れた一方、RFC7606未実装の一部はセッションリセットを引き起こした。
  • 継続的な悪用検証は実運用への影響を避けるため断念したが、検出はパブリックルートビューで確認可能。

Practical recommendations

  • BGP隣接設定で必ずremote-asとAS_PATH左端の一致を検査し、不一致はtreat-as-withdrawで破棄する。
  • ルータ/ベンダーの設定を確認してRFC7606準拠の処理（malformed AS_PATHの個別withdraw）を有効にする。
  • RPKI-ROVとASPAを併用してOrigin/ASP整合性を保ちつつ、First AS検証を追加の防御層として運用する。
  • monocleやMRT等のルートビューで不自然なAS関係を監視し、疑わしい挙動があればピアに報告する。
  • テストは影響範囲の限定されたプレフィックスで実施し、セッションリセット等の副作用を回避する。

Full Translation

翻訳

原文の流れを保ったまま読める翻訳セクションです。

openaijamodel: gpt-5-mini-2025-08-07

BGP AS_PATHでの最初のAS（First AS）の強制

概要

最近、Spamhausが報告した経路ハイジャックのいくつかに注目しました。これらの多くのハイジャックでは、攻撃者が未使用の自律システム番号（ASN）を悪用しているように見えます。特に、攻撃者が宛先に向かう偽のAS_PATHを作成し、トラフィックを予期しない経路へ誤誘導している事例がありました。偽造されたAS_PATHを作ることで、ハイジャッカーはトラフィックを本来の行き先とは異なる場所へ誘導しつつ、自分の正体を隠そうとします。

ハイジャッカーは経路情報を十分に削り取ることで、BGPプレフィックスのオリジンであるかのように装える場合があります。攻撃者はこのハイジャックされた経路を使ってトラフィックを傍受したり、その他の悪意ある目的に利用できます。こうしたケースに対する単純な解決策は、BGPピアの自律システム（AS）が常に広告される経路に自分のネットワークを「最初のAS（First AS）」として含めているかを基本的に検証することです。これらの保護がどれほど実装されているかを把握するために、主要ネットワークをストレステストし、それらのBGP実装を調査しました。以下で調査結果を示します。

偽造パスを含む経路ハイジャックの調査

偽の AS_PATH を作成しているという考えは、パス内の不合理なAS関係を詳しく見ることで裏付けられます。例えば、Spamhausが報告したハイジャック事例の一つに、フランスの通信事業者 Orange S.A. が所有するプレフィックスが含まれます。monocleツールを使うと、次のような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_PATHの右側にある各ASは上流（customer-to-provider）の関係を示しているはずです。つまり上の例では、AS17072がAS41128に対するトランジットプロバイダであり、AS270118がAS17072の上流、AS199524がAS270118の上流であることを示唆しています。

これらのネットワークを詳しく見ると:

  • AS41128 は Orange France に属する未使用のASN
  • AS17072 は主にメキシコを拠点とするISP
  • AS270118 はメキシコに拠点を置くホスティングプロバイダ
  • AS199524 はグローバルなピアリングを持つ Gcore

上記のAS順序は、未使用のOrange FranceのASがメキシコのISPからトランジットを買い、その後それがGcoreやTier 1プロバイダへ上流伝播される、というかなり奇妙な構図を示しています。

別の事例では、プレフィックス 47.1.0.0/16 と 47.2.0.0/16（オリジンAS36429）に対するハイジャックで、CloudflareのメインASNである13335がAS_PATHに含まれていました: 199524 270118 17072 13335 36429。Cloudflare RadarのMRT ExplorerでこれらのBGP UPDATEの例を確認できます。

我々（Cloudflare, AS13335）は、Charterに属する現在未使用のAS36429と隣接関係（adjacency）を持っていないことを確認できます。つまり、これはハイジャッカーによる偽造パスであり、CloudflareのASNが偽の上流ネットワークの1つとして、Gcore（AS199524）へ向けてプロパゲートされた広告に含まれていたことになります。

さらに、Spamhausが正しく指摘した通り、これらのハイジャック経路はすべてGcoreがピアリングしているシカゴのネットワークへ向かっており、実際にはメキシコのISPやCloudflareのネットワークを転送経路で通っていませんでした。これにより、このパスは左端の共通AS（このケースではAS199524）まで正当であり、それより左側のパスは不自然で偽造されていると合理的に結論できます。

我々が考える攻撃者の戦術は以下の手順に沿ったものです:

  • "parked"（放置または保留中の）プレフィックスについてBGPアナウンスを行う
  • AS_PATHを完全に偽造し、攻撃者自身のローカルASNを含めない
  • これらのルートをGcore（AS199524）へ広告する

これらのハイジャックでは、Gcore（AS199524）がFirst ASが期待される顧客のASNと一致するかどうかの検証・強制をスキップしているように見えます（後述しますが、なぜスキップするのかの理由も考察します）。結果として、偽造されたパスは受け入れられ、ハイジャックされたプレフィックスが上流のプロバイダやピアに伝播されます。

Autonomous System Provider Authorization (ASPA) はこれらの偽造パスを無効化するのに役立ちますが、攻撃者はRPKI-ROVで有効なオリジンASや正当なASPA上流ASのみを含めることで、ASPAを回避できる場合があります。これらの特定のハイジャックを止めるには、BGPに既に組み込まれている別の保護機構、すなわち First AS のチェックと強制 に頼る必要があります。

First AS チェックの重要性

インターネット上でトラフィックをルーティングすることは、荷物の配送に似ています。荷物が配送されると、その荷物を取り扱った各配達業者の記録が残ります。BGPではこれがAS_PATH（Autonomous System Path）と呼ばれ、ルートの経路中にある各ネットワークを追跡します。

BGPのAS_PATH属性はパス選択に使用されます。この選択アルゴリズムは、どの経路が目的地への「最良」のホップリストを通るかを決定します（ここでの「最良」は複数の変数で定義されます）。また、ループ防止にも使われ、ネットワークは既に自分のネットワークを通過したパスを受け入れないことを選択できます。

AS_PATHはBGP UPDATEが通過するネットワークの記録を保持するだけでなく、運用者が設定したルーティングポリシーによって特定のASを避けたり通過させたりする際の判断材料としても使われます。BGPは信頼に基づいて構築されており、AS_PATHは容易に操作可能です。ASプリペンド（AS prepending）のような一見正当な理由での操作や、短縮して人工的にトラフィックを引き寄せたりオリジン攻撃を行う悪意ある操作などが行われます。

以下に、2種類の悪意あるBGP操作の例を示します。

例 1: 偽造オリジン攻撃

  • AS64506 は自分のルートに対して RPKI ROA を使って暗号的に署名している（オリジンハイジャック防止のため）。
  • AS64506 は ASPA オブジェクトを作成し、唯一の有効なプロバイダとして AS64503 を指定している。
  • AS64505（ハイジャッカー）は自分の AS64505 を AS_PATH から削り取り、AS64506 としてオリジネートしている。
  • AS64502（中継するネットワーク）は First AS を強制していない。

この結果、ルートはRPKI-ROVで有効かつ最短経路に見え、トラフィックを効果的にハイジャックします。AS64506はROAやASPAを正しく設定しているにもかかわらず、ハイジャッカー（AS64505）は自分のASNをAS_PATHに含めないことでAS64506であるかのように装い、攻撃が成立してしまいます。

このハイジャックを既存のツールで防ぐ正しい方法は、AS_PATHの最初のAS（First AS）を強制することです。First AS を強制すれば、AS64502はAS64505からのそのルートを適切に破棄できます。

例 2: AS_PATHを短縮してトラフィックを引き寄せる

  • AS64506 には2つのトランジットプロバイダがある：AS64503 と AS64505。
  • AS64505 は顧客AS64506に対してトラフィック使用量に基づいて課金している。
  • AS64505 は自分自身をパスから削除し、そのピアである AS64504 は First AS を強制しない。
  • BGPのパス選択アルゴリズムは、AS64501 から見て AS64504 経由の経路を最良と判断するようになる。

結果として、AS64506は両方のプロバイダ（AS64503, AS64505）に支払いをしているにもかかわらず、遠隔ソースから見てAS64505経由の経路が短くなるため、AS64505がすべてのトラフィックを処理して代金を得て、AS64503は全く支払いを受けない、という不当な状況が生じます。

こうしたBGPの脆弱性は、受信したAS_PATHのFirst ASがピアASと一致するかを強制することで非常に簡単に解決できます。オペレータがBGPネイバーを設定する際には接続先のremote ASを設定します。AS_PATHの最初のASがこの値と一致しない場合、そのパスは操作されていると判断できます。

RFC 4271 のセクション6.3には First AS の強制手順が明確に記載されています（要旨）:

"If the UPDATE message is received from an external peer, the local system MAY check whether the leftmost ... AS in the AS_PATH attribute is equal to the autonomous system number of the peer that sent the message. If the check determines this is not the case, the Error Subcode MUST be set to Malformed AS_PATH."

さらに RFC 7606 は、ベンダがどのようにエラー処理を実装すべきかを改訂しており、Malformed AS_PATH を含むルートは treat-as-withdraw（取り扱いはWithdrawと同様に扱う）方式で破棄することが推奨されています。これにより、ルータはセッション全体を切断することなく、特定のプレフィックスのみを属性異常として破棄できます。

現在のASPAドラフトでも、First ASの強制の重要性が明記されており、AS_PATH情報が不十分な（malformed）アナウンスではASPAは対応できないとされています。AS_PATHにおけるFirst ASの強制は、インターネットルーティングのセキュリティに必須です。

わざとFirst ASルールを破って計測する

First ASルール違反の理論的な失敗例や過去の公開事案に留まらず、我々は実際にどれほど多くのネットワークがこうしたAS_PATH違反を受け入れるかを測定したいと考えました。そのため、意図的にルール違反を含むBGPアナウンスをネイバーへ対して出し、どのように受理されるかを確認しました。やったことは以下の通りです：

  • IPv4およびIPv6用に2つのIPプレフィックスを割り当て、Tier 1のEBGPネイバーへ広告
  • テストプレフィックス広告で最初のASとしてCloudflare所有の非13335 ASN（AS402542）を13335の前にプリペンドして故意にFirst ASを違反

例えば、我々は通常のジュネーブ拠点からAS1299へプレフィックスを広告しました。ローカルASはAS13335ですが、AS_PATHの最初に明確にAS402542を含めています。

[email protected] > 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; }
}
[email protected] > show route advertising-protocol bgp <redacted_1299_ip> 162.159.82.0/24 detail | grep "AS path: "
AS path: 402542 [13335] I

この構成における我々の期待は次の通りです：

  • First AS を強制するネットワークは、RFC 7606 の withdraw（treat-as-withdraw）方式でルートを静かに破棄する。
  • First AS を強制しないネットワークは、ルートを受理してテストプレフィックスへのフォワーディング経路としてインストールする。

どちらの結果も、パブリックなBGPルートビューで確認可能です。

当初の目的は、First ASルールを故意に違反するプレフィックスをすべてのピアへ継続的にアナウンスし、どのISPがFirst ASを検証しているかをチェックするツールを公開することでした。しかし、調査の過程で、Malformed BGP AS_PATHを受信した際にRFC 7606のガイダンスをまだ実装しておらず、treat-as-withdrawではなくBGPセッションをリセットしてしまうネットワークが存在することが分かりました。これではCloudflareへの実際のトラフィックに影響を与えかねないため、First ASルール違反を継続的に送出することは安全に実施できませんでした。

しかし、影響力の大きいネットワーク、すなわちTier 1ネットワークに注目することで詳細に調査できます。これらのネットワークはインターネットのバックボーンを構成し、顧客コーンが最も大きいため、これらピアのハイジャックやmalformedパスの受け入れは広範な影響を持ちます。

ここからは、通常の伝播挙動を調べることから始めます…