2025年11月18日

RARPという技術はどのように成立していますか？

質問

RARPという技術はどのように成立していますか？
またどのように使いますか？
セキュリティの穴になることはありませんか？

解答

概要 — RARP（Reverse ARP）とは

RARP（Reverse ARP）は、物理アドレス（MACアドレス）から対応するIPアドレスを取得するための古いプロトコルです。ARP が「IP → MAC」を解くための仕組みであるのに対し、RARP は「MAC → IP」を解くことを目的としています。主にディスクレス端末（自分で保存された設定がない端末）がブート時に自分のIPを知るために使われました。

仕組み（動作の流れ）

ブロードキャスト要求
- 起動した端末（まだIPを持たない）が自分のMACアドレスを含む RARP リクエストをブロードキャストで送る。
RARPサーバが応答
- ネットワーク上の RARP サーバ（あらかじめ MAC → IP の対応表を持っている）がそのリクエストを受け取り、対応するIPアドレスを含む RARP リプライを返す。
端末がIPを設定
- 端末は返ってきたIPを自分のIPとして設定し、以降は通常のIP通信を開始する。

実装面では ARP と非常に似たパケットフォーマットを使い、専用のオペコード／フレーム種別で区別します（実装依存の細かな値は省略します）。

どのように使われたか（利用例）

ディスクレスワークステーションのブート時：ローカルに設定ファイルが無い端末が自分のIPを取得するため。
古いネットワーク機器の起動：ネットワークブートや初期設定を行う前段階で使用。

しかし現在は以下の理由でほとんど使われません：

RARP はIP以外の設定（ゲートウェイ、サブネットマスク、DHCPオプション等）を渡せない。
認証・管理・柔軟性が乏しいため、より高機能な BOOTP / DHCP に置き換えられました。実際の現場では DHCP（PXEブート含む）が事実上の標準です。

セキュリティ上の問題点（穴になる点）

RARP 自体は設計が古く、ほとんどセキュリティ機構を持ちません。主な脆弱性は次の通りです。

MACアドレスの偽装（スプーフィング）に弱い
攻撃者が任意のMACでRARPリクエストを送れば、不正にIPを割り当てられる／既存端末とIPが競合する可能性がある。
認証なし
RARPサーバはリクエスト元の正当性を検証しないため、偽のサーバが応答すれば端末はそれを受け入れてしまう（なりすまし／MITMの入口になる）。
情報の限定性
RARPはIPしか渡さないため、追加のネットワーク設定やアクセス制御をその場で確実に反映できない。
トラフィックは未保護
平文でブロードキャストされるので傍受や改ざんが容易。

これらにより、RARPをそのまま使うとネットワーク上の認証回路やIP管理に対する攻撃面が増えます。

現代の実務での扱い（推奨事項）

原則使わない
- 新しい環境では RARP を使わず、DHCP（PXEを含む）を導入する。DHCPは多くのオプションを渡せる上、管理・ログ・制御がしやすい。
もしどうしても古いRARPを使う場合の対策
- ネットワークを分離（VLAN）してRARPトラフィックを限定する。
- ネットワーク機器側でポートセキュリティ（MACバインディング）を有効にし、許可されたMACのみ通信許可。
- RARPサーバは信頼できる管理ドメイン内に置き、アクセスを制限する。
現代的な防御策（DHCP環境でも有効）
- DHCP Snooping：不正なDHCPサーバからの応答を防止。
- Dynamic ARP Inspection (DAI)：ARPのなりすましを検出・防止。
- 802.1X（ポート認証）：端末が認証されるまでネットワークアクセスを制限。
- IP/MACバインディング や 静的割当の管理：資産管理台帳と突き合わせて運用。

まとめ（結論）

RARP は 「MAC→IP」解決のための古典的プロトコルで、ディスクレス端末のブート時などに使われてきたが、機能の少なさとセキュリティ欠如により 現在はほぼ廃れている。
実運用では DHCP（およびBOOTP/PXE）を用いるのが標準。
RARP を使う／残す場合は ネットワークの分離・ポートセキュリティ・認証機構の併用 で攻撃面を低減する必要がある。