ARPという「性善説」の終焉：ダイナミックARPインスペクション（DAI）が守るL2の要塞
ネットワークエンジニアの端くれであれば、ARP（Address Resolution Protocol）のあまりにも無邪気な挙動に、一度や二度は冷や汗をかかされた経験があるはずだ。
IPv4のパケットをL2のイーサネットフレームにカプセル化する際、私たちは必ず「このIPアドレスを持つ端末のMACアドレスは何か？」とブロードキャストで問いかける。そして、返ってきたARPリプライを、何の疑いも持たずにARPキャッシュへと刻み込む。
RFC 826で規定されたこのプロトコルには、状態の検証や認証という概念が最初から欠落している。
「答えた者勝ち」「言った者勝ち」の圧倒的な性善説の上に成り立っているこの仕組みこそが、現代のローカルエリアネットワーク（LAN）における最大の脆弱性、すなわちARPスプーフィング（ARPキャッシュポイズニング）の温床となっている。
今回は、この原始的かつ致命的な攻撃ベクトルに対し、L2スイッチのASICレベルで鉄槌を下すセキュリティ機構ダイナミックARPインスペクション（DAI：Dynamic ARP Inspection）の深淵に迫る。パケットがスイッチのポートを通過する瞬間、内部で何が起きているのか。そのメカニズムと現場で使える実践的なアーキテクチャを紐解いていこう。
—
1. なぜARPスプーフィングは脅威なのか：中間者攻撃のメカニズム
DAIの解説に入る前に、敵を知るためにARPスプーフィングがネットワークに何をもたらすのかをパケットレベルで再確認しておこう。
攻撃者（仮にIP: 192.168.1.100, MAC: de:ad:be:ef:01:02とする）は、標的の端末とデフォルトゲートウェイ（ルーター）に対し、巧妙に偽装した無心のARPリプライ（Gratuitous ARP含む）を送りつける。
「192.168.1.1（ルーター）のMACアドレスは、私のMACアドレス (de:ad:be:ef:01:02) だ」と、嘘の情報を周囲のARPキャッシュに上書きし続けるのだ。
この毒殺が完了すると、何が起きるか。
標的端末からインターネットへ向かうすべてのトラフィックは、本物のルーターではなく、攻撃者のNICへと吸い込まれていく。攻撃者はパケットを密かにキャプチャ（WiresharkなどでTLSハンドシェイク前の平文を漁ったり、SSL/TLSストリッピングを行ったり）した上で、何食わぬ顔して本来のルーターへと転送する。これが中間者攻撃（MitM：Man-in-the-Middle Attack）の古典的かつ最も確実な手口だ。
OSI参照モデルのレイヤー2において、スイッチは流れてくるイーサネットフレームの送信元MACアドレスを学習し、宛先MACアドレスに基づいてフォワーディングを行う。しかし、ARPパケットの中身（ペイロード）にある「IPアドレスとMACアドレスの対応関係」までは、通常のL2スイッチは関知しない。
フレームのL2ヘッダーが正しければ、スイッチはそれを疑うことなく転送してしまう。この「L2の転送能力」と「L3の論理アドレス」の間の乖離を突くのがARPスプーフィングの本質である。
—
2. ダイナミックARPインスペクション（DAI）の内部挙動：信頼の源泉としてのDHCPスヌーピング
この泥沼のような信頼関係を断ち切るために登場したのがDAIだ。
DAIは単体で機能するわけではない。その信頼の根幹を支えているのは、DHCPスヌーピング（DHCP Snooping）によって動的に生成・維持されるDHCPスヌーピングデータベース（Binding Database）である。
DHCPスヌーピングバインディングの確立
スイッチのポートを trust（信頼ポート：アップリンクやDHCPサーバー側）と untrust（不信ポート：一般端末側）に厳格に分類することからすべてが始まる。
untrust ポートを流れるDHCPトランザクション（DORAプロセス）をスイッチのCPU/ASICがスヌーピングし、以下の情報をデータベースにバインドする。
- クライアントのIPアドレス
- クライアントのMACアドレス
- リース期間
- 対応するスイッチのポート番号とVLAN ID
DAIのパケット検証パイプライン
DAIが有効化されたVLANにおいて、untrust ポートで受信されたすべてのARPパケット（リクエストおよびリプライ）は、そのまま転送されることはない。スイッチのハードウェア（またはソフトウェアフォワーディングパス）によって、以下の厳密なチェックを受ける。
1. IPアドレスの妥当性検証（Invalid IP Check）:
ARPパケット内のSender IPアドレス（送信元IP）が、0.0.0.0や255.255.255.255、あるいはマルチキャストアドレス、そしてルーターのIPアドレスなどの不正な値になっていないかを検証する。
2. データベースとの突き合わせ（Binding Database Lookup）:
ARPパケットに含まれる「送信元MACアドレス」と「送信元IPアドレス」のペアが、DHCPスヌーピングデータベースに存在するエントリーと完全に一致するかを確認する。
3. MACアドレスの整合性検証（Ethernet Header vs ARP Payload）:
イーサネットヘッダーの送信元MACアドレスと、ARPパケット内部のSender MACアドレスが一致しているかを検証する。MACスプーフィングを伴う偽装ARPパケットを弾くために極めて重要なチェックだ。
これらすべての検証をクリアしたARPパケットだけが正常に転送され、一つでも条件から外れたパケットは即座にドロップ（破棄）される。さらに、設定によってはポートを err-disable 状態に落とし、攻撃者の接続を物理的・論理的に隔離することが可能だ。
—
3. 実践：Cisco CatalystスイッチにおけるDAIの実装とチューニング
理論を理解したところで、実際のエンタープライズ環境におけるコンフィギュレーションを見ていこう。
以下の設定例は、Cisco IOSベースのスイッチにおける堅牢なDAIの実装手順である。静的IPアドレスを使用するサーバーやプリンターが存在する環境への配慮も含めている。
! =====================================================================
! 1. DHCPスヌーピングの全体有効化と対象VLANの指定
! =====================================================================
ip dhcp snooping
ip dhcp snooping vlan 10,20,30
! =====================================================================
! 2. アップリンクポートおよびDHCPサーバー接続ポートの信頼設定
! =====================================================================
interface GigabitEthernet0/1
description === Uplink to Core Router / DHCP Server ===
ip dhcp snooping trust
ip arp inspection trust
!
! =====================================================================
! 3. 一般エンドユーザー接続ポートの信頼解除（デフォルトでuntrustだが明示的に指定）
! =====================================================================
interface range GigabitEthernet0/2 - 24
description === Access Ports for End-Users ===
no ip dhcp snooping trust
no ip arp inspection trust
!
! =====================================================================
! 4. DAIのVLAN単位での有効化
! =====================================================================
ip arp inspection vlan 10,20,30
! =====================================================================
! 5. 静的IP環境のためのARPACL（ARP Access Control List）の定義
! ※DHCPを使わないプリンターやサーバーなどの正当な通信を救済する
! =====================================================================
arp access-list STATIC_SERVERS_ACL
permit ip host 192.168.10.10 mac host 0011.2233.4455
permit ip host 192.168.10.11 mac host 0011.2233.4466
! =====================================================================
! 6. 定義したARPACLをDAIの検証プロセスに適用（ログ記録も有効化）
! =====================================================================
ip arp inspection filter STATIC_SERVERS_ACL vlan 10 static実運用における落とし穴とチューニングの極意
上記のコンフィグを適用する際、現場のエンジニアが直面しがちな「ハマりポイント」がある。
- ARPパケットのレートリミット（Rate Limiting）:
DAIは受信したARPパケットをデータベースと照合するため、CPUやASICに一定の負荷がかかる。攻撃者が大量の偽装ARPパケットを送りつける「ARP洪水攻撃（ARP Flooding）」を受けた場合、スイッチのコントロールプレーンが枯渇し、正当な通信まで巻き込んでルーティングやスイッチングが麻痺する恐れがある。これを防ぐために、必ずポートごとのレートリミットをかけること。
interface range GigabitEthernet0/2 - 24
ip arp inspection limit rate 15 burst interval 1 これにより、1秒あたり15パケットを超えるARPリクエスト/リプライを送信したポートは自動的に err-disable に遷移し、ネットワーク全体の崩壊を防ぐことができる。
- 静的IP端末の救済:
オフィスフロアに固定IPのネットワークプリンターや管理用PCが混ざっている場合、DHCPスヌーピングデータベースに情報が載らないため、DAIを有効にした瞬間にそれらの通信が断たれる。上記のコンフィグで示したように、必ず arp access-list を用いて例外を定義し、static キーワードでフィルタにバインドする必要がある。
—
4. パフォーマンスへの影響とアーキテクチャの最適化
「セキュリティを厳格にするとパフォーマンスが落ちる」というジレンマは、ネットワークの世界でも常につきまとう。DAIの導入がデータプレーンおよびコントロールプレーンに与える影響を評価しておこう。
ASICベースのフォワーディングとハードウェア処理
現代のミドルレンジ以上のエンタープライズスイッチ（Cisco Catalyst 9000シリーズやCatalyst 3850/4500など）では、DAIのパケット検証はCPUではなくASIC（Application-Specific Integrated Circuit）またはTCAM（Ternary Content-Addressable Memory）のハードウェアレベルで処理される。
したがって、リニースピード（Wire-speed）に近いスループットを維持したままARPパケットのインスペクションが可能であり、一般的なL2スイッチングのレイテンシに対して数マイクロ秒以下のオーバヘッドしか付加しない。
ただし、ハードウェアのTCAMリソースやCPUへのバーストトラフィック耐性には物理的な限界がある。
特に、VLAN間ルーティングを行う環境や、仮想化基盤（VMware ESXiのvSwitchなどから大量の仮想マシンが同時にARPをブロードキャストする環境）では、前述した ip arp inspection limit のチューニングを怠ると、思わぬパケットドロップやCPU使用率の跳ね上がりを招くため、事前のトラフィックプロファイリングが不可欠である。
—
5. まとめ：レイヤー2の要塞化に向けて
ネットワークセキュリティの歴史は、「境界防御」の瓦解と「ゼロトラスト」の台頭の歴史でもある。
外部からのファイアウォールやIDS/IPS、エンドポイントのEDRにどれほどの巨費を投じようとも、足元であるレイヤー2セグメントがARPスプーフィングに対して無防備であれば、内部犯行や踏み台にされた1台のPCによって、すべての通信の機密性は音もなく崩り去る。
ダイナミックARPインスペクション（DAI）は、DHCPスヌーピングという「動的な信頼の土台」と組み合わせることで、L2におけるARPの脆弱性を根底から封じ込める強力なソリューションだ。
「動くのが当たり前」として放置されてきたプロトコルの暗部に対し、エンジニアの手で厳格な検問所を設けること。それこそが、堅牢なインフラストラクチャを構築するための第一歩なのである。
コメント