自社ASN（Autonomous System番号、対外接続の経路制御単位を識別する番号）を保有し、対外接続の冗長性やBGP経路の管理体制を監査で問われるデータセンター事業者・大規模ISPのネットワーク運用担当者が対象になる。RPKI（Resource Public Key Infrastructure、経路の正当な発信者を暗号学的に証明する仕組み）を導入済みでも、ROA（Route Origin Authorization、どのASがどのプレフィックスを広告してよいかを示す証明書）の設定次第でBGPハイジャックを許してしまう事例が2026年8月に起きた。ドイツのホスティング事業者Hetznerが保有するIPアドレス帯の一部が、ルーマニアのAS62390から広告された。攻撃者は自らを起源ASとして名乗らず、AS_PATHの末尾に本来の発信者であるAS24940を残したまま偽装経路を流している[1][2]。33時間の窓を通じて、RPKIバリデータはこの経路を一貫して「Valid」（正当）と判定し続けた[1][2]。原因はROAのmaxLength（許容するプレフィックス長の上限）指定が広すぎたことにある。この事件の経緯と、自社のROA点検やASPA（Autonomous System Provider Authorization）導入の要否を判断する材料を整理する。
予備知識
- RPKI: 経路の正当な発信者を暗号学的に証明する仕組み。発信側の宣言をROA、受信側の検証をROVと呼ぶ
- ROA: どのASがどのプレフィックスを、どこまでの長さで広告してよいかを示す電子署名つきのデータ
- maxLength: ROAが許容するプレフィックス長の上限。広く設定するほど、より狭い範囲の経路まで「Valid」と判定されてしまう
- ROV: 受信側のルータがROAに照らして経路の起源とプレフィックス長を検証すること
- ASPA: 自ASNが経路を受け取ってよい上流ASを宣言する仕組み。ROAより一段上でAS間の関係を検証する
第4章がBGPのUPDATEメッセージと経路決定プロセス、第5章がバックボーン運用と経路情報の信頼性・ASの隣接関係にあてられており、AS間の経路制御を運用側の視点で押さえ直したい担当者向け。
「Valid」なのに乗っ取られた仕組み
RPKIの起源検証が見るのは、経路広告のAS_PATHの末尾（起源AS）とプレフィックス長だけである。攻撃者はその外側を偽装した。
2026年8月28日20時57分30秒（UTC）、AS62390（NexonHost）が、Hetzner（AS24940）の162.55.0.0/16の一部である162.55.80.0/24を、トランジット事業者AS6204経由で広告し始めた[1][2][3]。公開コレクタが記録したAS_PATHは「29504 15935 6204 62390 24940」で、末尾はHetznerのAS24940のままだった[1][2]。BGPの経路選択はより長いプレフィックスを先に選ぶため、この/24は受け入れた網すべてでHetznerの/16に勝った[1][3]。
Hetznerが登録していたROAは「162.55.0.0/16、origin AS24940、maxLength 24」で、/24単位の広告もこの範囲に収まる[1][2]。そのためバリデータは偽装広告を「Valid」と判定した[1][2]。中継したAS6204（INTERKVM HOST SRL）に顧客のプレフィックスを絞り込むフィルタがなく、この経路がそのまま外部へ再広告されたことも一因である[1][2]。
Doug Madory氏も、偽装された起源によって経路がRPKI Validになった点を、偽装と正規の二つのAS_PATHの対比で示している。
Taking a look at this BGP hijack of 162.55.80.0/24 that targeted Virtualizor in recent days.
Hijackers forged the origin to make the route RPKI-valid:
… 6204 62390 24940 (hijack AS path)
… 24940 (legit AS path)— Doug Madory (also on Bluesky) (@DougMadory) 元投稿を見る
より長いプレフィックスが先に選ばれるロンゲストマッチ、AS_PATHなどのパス属性、BGPの経路選択順序を図解でたどれる。今回の偽装広告が全網で勝った前提を一つずつ確認したい人向け。
33時間の窓のうち、経路が奪われていたのは約22時間
窓は8月28日20時57分から8月30日6時10分ごろまでの33時間強である[1][3]。ただし経路が実際に奪われていたのはその全部ではない。第1波の約12時間（8/28 20:57〜8/29 8:50）と第2波の約10時間（8/29 19:55〜8/30 5:45）を足した約22時間が、偽装経路が伝播していた時間になる[1][2]。
残る約11時間は、Softaculousからの通報と再三の催促を受けたHetznerが8月29日8時50分ごろに自ら162.55.80.0/24を広告して迂回を止めた時間と、その対抗広告を14時30分ごろに取り下げて/16に戻った時間である[1][2][3]。攻撃者は対抗広告が消えた5時間ほど後に、同じ経路シグネチャで戻ってきた[1][2]。一方でROVから見た露出は窓の全体にわたる。最初の広告から最後の取り下げまで、判定はValidのまま変わらなかった[2]。
伝播の広さは、RIPE NCCのRIS（Routing Information Service）が持つ368のコレクタピアを分母に測られている。波が立っている間は最大72%がこの偽装経路をベストパスとして採用し、中位数は266ピア、期間を通じては368すべてが一度はこの経路を持った[1][2]。これは経路の見え方の指標であって通信量ではなく、経路が激しく上下していたため個々の網の露出は断続的だった[2]。
証明書はその窓の早い段階で取られている。最初の偽装広告から33分後の8月28日21時30分29秒（UTC）、SoftaculousとVirtualizorの26ドメインを対象とするLet’s Encryptの証明書がCT（Certificate Transparency）ログに現れた[1]。ドメイン検証のリクエストも奪われた経路を通ったためである[1][2]。Let’s Encryptは2020年から複数地点での検証を導入しているが、RISのピアの72%が偽装経路をたどる状況では、多数決も攻撃者側に着く[1]。
同じ経路上でVirtualizorの更新エンドポイントが複製され、バージョン3.2.9.8を名乗る改ざん済みの更新パッケージが、窓の中で更新を確認したホストに配信された[1][3]。インストール後もホストは3.2.9.7と報告し、このバージョンの食い違い自体が検知の手がかりになる[1][2]。Virtualizorは、更新クライアントが更新パッケージを暗号的に検証していなかったと書いている[3]。
数百台規模のクラウドインフラをオートスケーラーとAIOps基盤で運用する日本企業のSRE・インフラ運用担当が、2026年に向き合うべき新しい障害パターンがある。ThousandEyesが公開した「2026年最大のアウテージリスク」レポート[…]
なぜ防げなかったのか、効いていた制御はROAだけだった
この経路に対して働きうる制御は四つあり、8月28日に実際に効いていたのは、Hetznerが署名していたROAだけだった。そしてそのROAは「Valid」と答えた[1]。
| 制御 | 偽装された/24への判定 | 8月28日時点の状態 |
|---|---|---|
| ROA 162.55.0.0/16・AS24940・maxLength 24 | Valid。全網が受理 | Hetznerが署名済み |
| 最小のROA（maxLengthを/16と同値にする） | Invalid。検証する網は破棄 | 当時は使われていない |
| AS24940のASPA | AS24940→AS62390のホップでInvalid | 未公開 |
| AS6204の顧客プレフィックスフィルタ | ルーマニアを出る前に拒否 | 機能していない |
四つの制御の並べ方と判定はIpregistryの整理による[1]。ASPAの行は、BGPKITが実際のAS_PATHを検証アルゴリズムに通した結果と一致する[2]。
maxLength 24は、162.55.0.0/16の中にありうる256通りの/24をすべて事前に許可する設定であり、攻撃者はそのうち1つを使っただけで「Valid」判定を得た[1][2]。9月3日時点で、RIPE NCCとCloudflareのバリデータはこのROAを162.55.0.0/16・AS24940・maxLength 16として表示している[1]。Hetzner自身はこの変更を公表していないが、BGPKITが8月31日に取得したスナップショットとの間でオブジェクトが変わっており、同じ広告を今流せばInvalidになる[1]。
最小のROAで防げたという指摘は、事件が公表された当日にコミュニティからも出ていた。
@DougMadory > more specific than Hetzner’s normal announcement of the surrounding block (162.55.0.0/16), so under standard BGP route selection it took precedence on every network that accepted it.
Wow, good example where signing the minimal /16 ROA (RFC9319) would have helped.
— Bryton Herdes (@next_hopself) 元投稿を見る
ASPAは起源の一つ上、誰が上流を名乗ってよいかを検証する。BGPKITが今回のAS_PATHをASPAの検証アルゴリズムに通したところ、AS24940のASPAが1つ公開されているだけで偽装経路はInvalidになり、Hetznerの正規経路はUnknownのままで巻き添えが出ないという結果になった[2]。ただし普及は限定的である。Hurricane Electricの9月2日時点の集計では、経路広告されているASNのうちASPAレコードを持つのは2,543、割合にして2.89%にとどまり、Hetznerも偽装経路上のどのASも含まれていない[1]。
四つ目の顧客プレフィックスフィルタは最も地味な制御である。AS6204がAS62390に許可したプレフィックスだけを受け入れていれば、この広告はセッションの時点で拒否され、1ホップで終わっていた[1][2]。
AWSは2026年4月14日、自社のVPCと他クラウドのVPCをインターネットを通さずに直接つなぐマネージドサービス「AWS Interconnect – multicloud」を一般提供開始した[1]。開始時の接続先はGoogle Cl[…]
日本でこの型に備えるとき、指針はすでにある
JPNICは日本国内におけるリソース証明書の発行主体であり、「RPKIのROAを使ったインターネットにおける不正経路への対策ガイドライン」のVersion 1.1を2026年3月27日に公開している[4]。総務省の事業で調査研究と実証実験を経て案が作られ、令和6年4月にサイバーセキュリティタスクフォースのICTサイバーセキュリティ政策分科会（第5回）で案のレビューを受けたうえでJPNICが引き受けた文書で、第1章が経営の観点、第2章以降が技術の観点という構成になっている[4]。なお日本のIPアドレス分配は、アジア太平洋地域を受け持つ地域インターネットレジストリ（RIR）であるAPNICと、その下で国内の割り振りを担う国別インターネットレジストリ（NIR）のJPNICという階層で動いている[5][6]。
このガイドラインは、登録する最大プレフィックス長を実際に広報する経路のプレフィックス長と一致させるよう求めている。実際の広報経路が/19なのに/24まで許可した場合、「サブプレフィックス攻撃」と呼ばれる方法によって、より長いプレフィックス長を持つ不正な経路情報の影響を受ける可能性がある、という説明である[4]。今回のHetznerは/16に対してmaxLength 24を許可していたので、この型そのものにあたる。ただしVersion 1.1は同じ箇所で、サブプレフィックス攻撃について運用上の条件が限定されていて報告例はまだないとも書いている[4]。3月時点のその記述が、8月の事例で更新を迫られた形になる。
実施事項は立場で分かれる。JPNICやAPNICからIPアドレスの分配を受けている組織は、ROAを作成し、それを実際のBGP経路と一致するように保つことが必須事項とされる[4]。今回の事件の核心にあたる最大プレフィックス長は、必須事項ではなく運用上の注意として扱われている。登録する最大プレフィックス長は実際に広報する経路の長さと一致させておくこと、実際の広報が/19なのに/24まで許可するとサブプレフィックス攻撃の影響を受ける可能性があることが挙げられ、この攻撃は攻撃者のBGPルータがROAに記載されたオリジンASを使って不正経路を発信するもので報告例はまだないと書かれている[4]。Hetznerの事例は、AS24940を起源として名乗ったまま/16のROAが許す/24を広告しており、この型に当てはまる。ASを運用している組織は、ROVの実施が推奨事項で、自組織でROAキャッシュサーバを運用する方式A、IXP等が提供するROAキャッシュサーバを使う方式B、ROVが行われているトランジット経路を使う方式Cの三つが挙げられている[4]。
費用の話も同じ文書にある。ROVで増えるのはROA作成依頼の手間とROV可能なルータの設備・運用コストで、CPU負荷やメモリ使用量の増加はROV対応ルータであれば問題になる量ではないとしている[4]。加えて、推奨事項を実施している組織はその旨を公に示すことができ、実施について民間で認定され、今後は各種調達で認定状況が参照されることがあるとも書かれている[4]。ASパス検証については、有効性の検証や標準化は進みつつあるが開発は途上で、RPKIと同様に今後の適切な導入が望ましい位置づけだとされている[4]。今回の事件はASPAが効く型でありながら、国内の指針でも現時点では先の課題という扱いになっている。
よくある質問（FAQ）
RPKIを導入していれば安全ですか。
いいえ。今回はROAのmaxLengthが/24まで許可していたため、偽装された経路もValid判定のまま通りました。起源検証が見るのはAS_PATHの末尾とプレフィックス長だけで、その手前に誰が入り込んだかは見ません。
自社のROA設定はどこで確認できますか。
JPNICから分配を受けている場合は、JPNICのRPKIシステム（ROA登録Web）で登録内容の確認と変更ができ、経路との一致はJPNICのRPKI Validatorで確認できます[7]。なおJPNIC自体は地域インターネットレジストリ（RIR）ではなく国別インターネットレジストリ（NIR）で、日本を含むアジア太平洋地域を受け持つRIRはAPNICです[5][6]。
ASPAはすぐ導入すべきですか。
公開しているASNは2.89%にとどまり[1]、JPNICのガイドラインもASパス検証は開発が途上で今後の適切な導入が望ましい位置づけとしています[4]。まずは最大プレフィックス長の点検を先に済ませるのが現実的です。
まとめ
自社ASNを保有してプレフィックスを広告している組織がまず確かめるべきなのは、発行済みROAの最大プレフィックス長が、実際に広告している経路の長さと一致しているかである。Hetznerの/16はmaxLength 24を許可していたために、256通りの/24が事前に承認された状態にあった。一致させる作業そのものに費用はほとんどかからない一方、放置すれば正規のTLS証明書の不正取得とソフトウェア更新の改ざんにまで連鎖しうることを、この33時間が示している。ROVをどの方式で実施するか、ASPAをいつ検討に載せるかは、JPNICのガイドラインが判断の下敷きになる。RPKIの導入は前提であって、設定が実際の広告と合っているかまで含めて初めて機能する。
出典
[1] A 33-Hour BGP Hijack Passed RPKI, Fooled Let’s Encrypt, and Shipped Malware（Ipregistry Blog）[2] Anatomy of the Virtualizor BGP Hijack: Reading the Attack in Raw BGP Bytes（BGPKIT Blog）
[3] Security Incident – BGP Hijacking（Virtualizor）
[4] RPKIのROAを使ったインターネットにおける不正経路への対策ガイドライン Version 1.1（JPNIC）
[5] インターネット用語1分解説〜NIRとは〜（JPNIC）
[6] インターネット用語1分解説〜APNICとは〜（JPNIC）
[7] ROAの作成と管理の方法（JPNIC）
