【現場発】ARPの裏側とARPキャッシュポイズニングの恐怖：Webエンジニアが知るべき「レイヤー2」の罠
こんにちは。ネットワークの配線地獄からクラウドのVPC設計まで、数々の修羅場をくぐり抜けてきたシニアネットワークエンジニアだ。
普段、Web APIの設計やモダンなフロントエンド開発に没頭している君たちは、ついつい「IPアドレス」や「TLSハンドシェイク」、「HTTPヘッダー」といったレイヤー3以上の世界ばかりに目が行きがちじゃないか？ 「フロントエンドから fetch でAPIを叩いて、JSONを取るだけなら、下位レイヤーのことはインフラチームに任せておけばいい」――そう思っていないかい？
だが、ちょっと待ってほしい。
どれほどセキュアなJWT（JSON Web Token）を使い、どれほど厳格にCORSを設定しようとも、その足元である「データリンク層」が揺るがされていれば、通信の全貌は一瞬で敵の手に渡る。
今回は、IPアドレスとMACアドレスを繋ぐ裏方の主役「ARP（Address Resolution Protocol）」のリアルな挙動と、それが引き起こす最悪の脅威「ARPキャッシュポイズニング」のメカニズムを、実務の現場感覚で徹底的に解説しよう。
—
1. ARPとは何か？ なぜ「MACアドレス」が必要なのか
私たちが普段何気なく使っているIPアドレス（IPv4）は、いわばインターネット上の「住所」だ。東京の本社からロサンゼルスのサーバーへパケットを届けるためには、このIPアドレスがなくてはならない。
しかし、実際の物理的なネットワーク機器（スイッチングハブやNIC）は、IPアドレスなんてものは理解していない。彼らが理解するのは、世界に唯一無二のハードウェア識別子であるMACアドレス（物理アドレス）だけだ。
ここでWebエンジニアによくある誤解を解いておこう。
「パケットはIPアドレスだけで宛先に向かって進む」というのは半分正しくて半分間違いだ。ルーターを越えてルーティングされる際、IPヘッダーの宛先IPアドレスは原則として最後まで変わらない。しかし、イーサネットフレームとして次のノード（ルーターや端末）へ実際に送り出すとき、フレームの宛先には「次の宛先のMACアドレス」が必ず上書きされる。
つまり、どれだけ遠くのIPを指定しても、目の前の物理的なネットワーク上で「このIPを持つやつは、どのMACアドレスの機器だ？」を特定できなければ、パケットは1歩も先へ進めないのだ。その翻訳作業を行うのが、他なら入らぬ ARP というプロトコルである。
—
2. ARPリクエストとARPリプライの通信フロー
では、実際にローカルネットワーク内でパケットがどうやり取りされているのか、具体的なシナリオで見てみよう。
いま、君のPC（IP: 192.168.1.10 / MAC: AA:AA:AA:AA:AA:AA）から、同じセグメントにあるデータベースサーバー（IP: 192.168.1.100）へアクセスしようとしているとする。しかし、君のPCのARPキャッシュ（対応表）には、まだ 192.168.1.100 のMACアドレスが登録されていない。
このとき、舞台裏では次のようなドラマが繰り広げられている。
① ARPリクエスト（ブロードキャスト）の送信
君のPCは、セグメント全体の全端末に向けて、大声でこう叫ぶ。
> 「おい、誰か 192.168.1.100 ってIPを使っている奴はいないか！？ もしいたら、お前のMACアドレスを俺（AA:AA:AA:AA:AA:AA）に教えてくれ！」
これが ARPリクエスト だ。
このイーサネットフレームの宛先MACアドレスには、ネットワーク上の全員が必ず受け取る特殊なブロードキャストアドレス FF:FF:FF:FF:FF:FF が指定される。
② ARPリプライ（ユニキャスト）の返答
セグメント内のすべての機器（プリンター、スマホ、他のPC）はこのブロードキャストを受信するが、IPアドレスが自分のものではないため、静かにパケットを破棄する。
しかし、ターゲットであるデータベースサーバー（MAC: BB:BB:BB:BB:BB:BB）だけは、「お、俺のことだな」と気づき、君のPCへ直接こう返信する。
> 「俺が 192.168.1.100 だよ。俺のMACアドレスは BB:BB:BB:BB:BB:BB だ。覚えとけよ」
これが ARPリプライ だ。こちらは誰彼構わず叫ぶのではなく、君のPCのMACアドレス宛に直接（ユニキャストで）送られる。
このやり取りが完了した瞬間、君のPCのOS内にあるARPキャッシュテーブルに、次のようなデータが書き込まれる。
# WindowsやLinuxで `arp -a` を叩いたときのイメージ
Interface: 192.168.1.10 --- 0x2
Internet Address Physical Address Type
192.168.1.100 bb-bb-bb-bb-bb-bb dynamicこれでようやく、TCPのコネクション確立（SYN/ACK）やHTTPリクエストの送信へと進むことができるのだ。
—
3. ARPの致命的な設計欠陥：ステートレスと「性善説」
さて、ここからが本題だ。
お気づきの方もいるかもしれないが、ARPというプロトコルには「認証」の概念が一切ない。
ARPには「ステートフルなセッション確認」や「リクエストに対する正当な返答であるかの暗号学的検証」が存在しない。つまり、「俺は頼まれてないけど、教えちゃうぜ！」という突然のARPリプライ（Unsolicited ARP）が飛んできても、OSは疑うことなくそれを信用し、ARPキャッシュを上書きしてしまうのである。
これが、ARPキャッシュポイズニング（ARPスプーフィング） の原理だ。
中間者攻撃（MITM）のシナリオ
攻撃者（IP: 192.168.1.666 / MAC: CC:CC:CC:CC:CC:CC）がローカルネットワーク内に潜り込んでいるとする。
攻撃者は、標的のPCとデフォルトゲートウェイ（ルーター）に対して、次のような偽のARPメッセージを大量に送りつける（嘘をつき続ける）。
1. ルーターに対して: 「192.168.1.10（標的PC）のMACアドレスは CC:CC:CC:CC:CC:CC（攻撃者）に変更されたぞ」と嘘をつく。
2. 標的PCに対して: 「192.168.1.1（ルーター）のMACアドレスは CC:CC:CC:CC:CC:CC（攻撃者）に変更されたぞ」と嘘をつく。
結果どうなるか？
標的PCが外の世界（インターネットや社内APIサーバー）へ送ろうとしたすべてのパケットは、ルーターではなく攻撃者のPCへと吸い寄せられることになる。攻撃者はパケットを盗み見（スニッフィング）した上で、何食わぬ顔で本来のルーターへ転送（フォワーディング）するため、標的のユーザーは攻撃を受けていることに気づきにくい。
これが、近代セキュリティにおいても依然として脅威であり続ける中間者攻撃（MITM）の恐ろしい実態だ。
—
4. 実務での検証・デバッグ手法とコード例
では、インフラエンジニアやセキュリティ担当者は、このARPの挙動をどのように確認し、トラブルシューティングや検証を行っているのだろうか。現場で使える実践的なコマンドやスクリプトを見ていこう。
① ターミナルでのARPキャッシュ確認・操作
まずは自分のマシンのARPテーブルを覗いてみよう。LinuxやmacOS、Windows共通で使えるコマンドだ。
# Linux / macOS でのARPキャッシュ確認
arp -an
# Windows (PowerShell / コマンドプロンプト) での確認
arp -aもし、ネットワークの不調やルーターの交換などでARPキャッシュがおかしくなり、通信が途絶えた場合は、手動でキャッシュをクリア（フラッシュ）する必要がある。
# 【Linux】特定インターフェースのARPキャッシュをクリア
sudo ip neigh flush dev eth0
# 【Windows (管理者権限)】ARPキャッシュのエントリを削除
arp -d *※現場で「突然特定のサーバーとだけ通信できなくなったが、pingは通る（あるいは通らない）」という障害にぶぶつかった時、このARPキャッシュの破損やスタティック設定の競合が原因だったりすることは、実務では本当によくある話だ。
② Pythonによる簡易ARPスキャナーの実装（ネットワーク調査用）
インフラの資産管理やセグメント内の死活監視・MACアドレス調査において、Pythonの scapy ライブラリを用いたARPスキャンは定番のテクニックだ。
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
"""
実務インフラ用: 指定したサブネット内の活発なホストのIPとMACアドレスをARPで列挙するスクリプト
※実行には root 権限（sudo）と scapy ライブラリが必要です。
"""
from scapy.all import ARP, Ether, srp
def scan_network(target_ip_range):
print(f"[*] ネットワークスキャンを開始します: {target_ip_range}")
# ARPリクエストパケットの作成
# pdst にはスキャン対象のIPレンジ（例: "192.168.1.0/24"）を指定
arp_request = ARP(pdst=target_ip_range)
# イーサネットのブロードキャストフレーム（FF:FF:FF:FF:FF:FF）で包む
broadcast = Ether(dst="ff:ff:ff:ff:ff:ff")
# 2つを結合してパケットを組み立てる
packet = broadcast / arp_request
# パケットをレイヤー2で送受信（srp = Send/Receive Layer 2 packets）
# timeout=2秒で応答を待つ
answered_list, unanswered = srp(packet, timeout=2, verbose=False)
print("-" * 50)
print("IP アドレス\t\t\tMAC アドレス")
print("-" * 50)
# 応答があった端末のリストをループして表示
for sent, received in answered_list:
print(f"{received.psrc}\t\t{received.hwsrc}")
print("-" * 50)
print(f"[*] スキャン完了。合計 {len(answered_list)} 台のデバイスを検出しました。")
if __name__ == "__main__":
# 例として自宅やオフィスのローカルセグメントを指定
target_range = "192.168.1.0/24"
scan_network(target_range)このようなスクリプトは、社内LANやクラウドのVPC内での不正端末（Rogue Device）の検知や、IPアドレスの重複（IPスプーフィングの予兆）を調査するインシデントレスポンスの現場で重宝されている。
—
5. ゼロトラスト時代のARPポイズニング対策
「じゃあ、ローカルネットワークの通信なんて常に盗聴のリスクと隣り合わせなのか？」と絶望するのはまだ早い。エンタープライズの現場や堅牢なインフラ設計では、次のようなレイヤー2レベルのセキュリティ機能（ハードウェアの機能）を有効化して、このARPの脆弱性を封じ込めている。
1. DAI (Dynamic ARP Inspection)
Ciscoなどのレイヤー3スイッチや高機能スイッチに備わっている機能。DHCPスヌーピング等のデータベースと連携し、正当なIPとMACの対応関係以外のARPリプライを自動的に検知して破棄（ドロップ）する。現代のセキュアなオフィスネットワークの必須要件だ。
2. スタティックARPエントリー（静的登録）
サーバーや重要なネットワーク機器において、ARPキャッシュを動的に学習させず、手動で固定（スタティック）する方法。小規模なシステムや絶対に改ざんされたくないルーターのアップリンクなどで有効だが、運用コスト（MACアドレス変更時のメンテ）が高くなるデメリットがある。
3. エンドポイントでの検知・EDRの導入
端末側でARPテーブルの急激な変化（同じIPに対してMACアドレスが頻繁に変わる現象）を監視するセキュリティソフトウェア（EDRやホスト型IDS）を導入し、攻撃の兆候をアラートとして上げる。
—
まとめ
今回は、普段私たちが何気なく使っているIP通信の土台を支える「ARP」のメカニズムと、その歴史的背景ゆえの致命的な脆弱性について解説した。
- ARPは、IPアドレスからMACアドレスを引くための「性善説」に基づいたプロトコルである。
- 認証がないため、偽のARPリプライを送りつけられることで簡単にARPキャッシュが書き換えられ、中間者攻撃（MITM）の踏み台にされる。
- WebやAPIのセキュリティだけでなく、インフラエンジニアはレイヤー2の挙動（DAIやスイッチの設定）まで目を光らせる必要がある。
アプリケーションのコードを書くときも、インフラを構築するときも、「今、パケットが物理層やデータリンク層でどう流れているのか」を頭の中でイメージできるかどうかが、一流のエンジニアとそうでないエンジニアを分ける分かれ道だ。
さあ、次のデプロイやネットワーク設計の際には、ぜひこの「足元の泥臭い世界」にも思いを馳せてみてほしい。トラブルシューティングの引き出しが、確実に一段と深くなるはずだ。
コメント