世界中のインターネットトラフィックの大部分は、1989年に誕生したルーティングプロトコルであるBGPに今なお依存しています。BGPは当初、相互に信頼し合うことを前提に設計されました。そのため、悪意のあるなしにかかわらず、どの事業者でもGoogleやCloudflareのIPプレフィックスを自らが保有しているかのように経路広告できてしまいます。
その結果、トラフィックは瞬時に誤った方向へ引き込まれてしまいます。2008年には、パキスタンテレコムが誤って単一の/24プレフィックスを広告したことが原因で、世界規模で約2時間にわたりYouTubeがダウンする事態が発生しました。このような深刻な脅威を防止するために登場したのが、RPKIと経路オリジン検証(Route Origin Validation – ROV)を組み合わせたソリューションです。
実環境における3つのBGPルーティング保護手法
ネットワークエンジニアはこれまで、プレフィックスのなりすましを防ぐために様々なアプローチを試みてきました。
- 1. プレフィックスリストとIRR(Internet Routing Registry)による静的フィルタリング
RADbやRIPEといったIRRデータベースに基づき、各ピアやトランジットから受信を許可するプレフィックスの一覧を定義します。 - 2. ルーティングパスの電子署名(BGPsec)
経路上の各ルーターがAS-Path属性に対して電子署名を行います。受信側ルーターは署名を検証することで、パケットが通過するホップごとの正当性を確認します。 - 3. RPKIとオリジン検証(RPKI – ROV)の組み合わせ
IPプレフィックスの保有者が、APNICやJPNICなどの地域インターネットレジストリ(RIR/NIR)を介してROA(Route Origin Authorization:経路オリジン認証)に電子署名を発行します。エッジルーターは自組織内のRPKIバリデータサーバーから検証済みリストを取得し、経路を広報している自律システム(AS)が正当であるかを照合します。
各ソリューションのメリット・デメリット比較
各アプローチには、セキュリティ強度と運用コストの間で明確なトレードオフが存在します。
1. プレフィックスリストとIRRフィルタ
- メリット: ほぼすべてのルーターが標準で対応しており、追加のミドルウェアを導入する必要がありません。
- デメリット: IRRデータベースには古いゴミデータが多く含まれており、更新頻度も遅れがちです。対向事業者がネットワーク帯域を拡張したりサブネットを細分化した際には手動で更新しなければならず、フィルタの修正を怠ると即座に通信断につながります。
2. BGPsec
- メリット: AS-Pathチェーン全体の全ホップを包括的に保護できます。
- デメリット: ルーター側で継続的な暗号処理が求められます。CPU負荷が極めて高く、現行の多くのネットワーク機器では処理能力が追いつかないため、商用本番環境での導入はほとんど進んでいません。
3. RPKIとROVの組み合わせ
- メリット: 設定ミスやOrigin ASのなりすまし攻撃を根本から防止します。ルーターが直接インターネットへ接続して数十万件の証明書をダウンロードする必要がなく、バリデータが検証・処理済みのクリーンなデータのみを受け取ります。
- デメリット: 途中のASを改ざんする高度なAS-Pathスプーフィング攻撃までは防ぐことができません。それでもなお、現時点で即座に導入可能な最も現実的かつ強力な防御策です。
なぜLinux上にRoutinatorを構築すべきなのか?
エッジルーターに負荷の高い証明書検証処理を担わせるのではなく、専用のLinuxサーバーを1台用意してバリデータとして動作させるのが標準的なアーキテクチャです。このサーバーが各インターネットレジストリから証明書を同期し、Cisco、Juniper、FRRoutingなどのルーターに対してRTR(RPKI-to-Router)プロトコル経由で検証結果を配信します。
NLnet LabsがRust言語で開発しているRoutinatorは、以下の優れた特徴から現在最も広く利用されているバリデータです。
- 高パフォーマンス: リソース消費が非常に少なく、世界中の50万件以上のROAレコードを処理しても消費メモリはわずか1.5GB〜2GB程度です。
- 充実した統合機能: Web UI、Prometheus metricsエンドポイント、RFC 6810/8210準拠のRTRデーモンを標準でサポートしています。
- 簡単なセットアップ: NLnet LabsがDebianおよびUbuntu向けに公式パッケージリポジトリを提供しています。
APNICやJPNICなどのポータルでROAを登録する際は、プレフィックス(Prefix)とMaxLengthを正確に設定する必要があります。MaxLengthを誤って指定すると、対向ルーター側でInvalid判定とみなされ、正当なトラフィックごと破棄されてしまう恐れがあります。IP範囲、ブロードキャストアドレス、利用可能ホスト数を素早く計算したい場合は、toolcraft.app/ja/tools/developer/ip-subnet-calculator などのツールを活用できます。事前に/24ブロックを/25や/26に正確に分割しておくことで、ROAにおけるサブネット長の設定ミスを未然に防ぐことができます。
Ubuntu/Debian環境でのRoutinator導入手順
ステップ1: Routinatorのインストール
NLnet Labsのリポジトリを追加し、パッケージをインストールします。
# 必要な依存ツールのインストール
sudo apt update && sudo apt install -y curl gnupg lsb-release
# NLnet LabsのGPGキーを追加
curl -fsSL https://packages.nlnetlabs.nl/aptkey.asc | sudo gpg --dearmor -o /usr/share/keyrings/nlnetlabs-archive-keyring.gpg
# パッケージリポジトリをソースリストに追加
echo "deb [signed-by=/usr/share/keyrings/nlnetlabs-archive-keyring.gpg] https://packages.nlnetlabs.nl/linux/ubuntu $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/nlnetlabs.list
# パッケージリストの更新とインストール
sudo apt update
sudo apt install -y routinator
ステップ2: TALsデータの初期化
Routinatorは、世界5つのRIR(AFRINIC、APNIC、ARIN、LACNIC、RIPE NCC)からTrust Anchor Locator(TAL)ファイルを読み込む必要があります。なお、ARINのみ利用規約への同意が求められます。
# routinatorユーザー権限で初期化コマンドを実行
sudo -u routinator routinator init --accept-arin-rpa
ステップ3: サービスの設定
/etc/routinator/routinator.conf にあるメイン設定ファイルを開きます。
sudo nano /etc/routinator/routinator.conf
ルーター接続用のRTRポート(3323)とステータス監視用のHTTPポート(8323)を設定します。
# ルーター接続用RTRサービスポート
rtr-listen = ["0.0.0.0:3323"]
# Web UIおよびPrometheus metrics用ポート
http-listen = ["0.0.0.0:8323"]
# RIRからのデータ更新間隔(秒)
refresh = 600
ファイルを保存し、サービスを有効化して起動します。
sudo systemctl enable --now routinator
sudo systemctl status routinator
ステップ4: 同期状況の確認とプレフィックスの検証
初回起動時、RoutinatorがrsyncおよびRRDP経由で全ROA証明書をダウンロードするまでに約5〜15分かかります。以下のコマンドで進行状況を確認できます。
journalctl -u routinator -f
データの同期完了後、ターミナル上で特定のIPプレフィックスとASNの組み合わせをテストしてみます。
# Google (AS15169) の 8.8.8.0/24 経路を検証
routinator validate --asn 15169 --prefix 8.8.8.0/24
検証結果として以下の3つのステータスのいずれかが返されます。
- Valid: IPプレフィックスおよびOrigin ASNが正当なROAと完全に一致しています。
- Invalid: 該当プレフィックスのROAは存在するものの、異なるASNから広報されているか、サブネット長が許可されたMaxLengthを超えています。この経路は直ちに破棄(ドロップ)すべきです。
- NotFound: 該当プレフィックスに対するROAが登録されていません。通信障害を避けるため、ルーターは通常の経路としてルーティングを継続します。
ステップ5: エッジルーターでのRTR連携設定(FRRoutingの例)
FRRoutingを実行しているルーターにRoutinatorサーバーのIPを登録し、ROV機能を有効化します。
router bgp 65001
rpki
rpki polling_period 300
rpki cache 192.168.10.50 3323 preference 1
exit
!
route-map BGP-IN deny 10
match rpki invalid
!
route-map BGP-IN permit 20
上記の設定により、ルーターはinvalidと判定された経路を自動的に拒否します。これにより、自ネットワークが偽装された不正なBGP経路へトラフィックを誤転送してしまうリスクを排除できます。
