ネットワークの「身元」を保証せよ：IP Source Guardで防ぐなりすましパケットの脅威
ネットワークエンジニアの諸君、今日もパケットの海を泳いでいるだろうか。
インフラの現場で最も恐ろしいのは、信頼していたはずの「内側の通信」が、実は偽物だったという事態だ。特に「IPアドレスなんて、設定次第でいくらでも偽装できる」という事実は、Web API開発者やクラウドエンジニアにとっても避けて通れない現実だ。
今日は、スイッチのアクセス層で悪意ある（あるいは設定ミスの）IPなりすましを物理的に封じ込める、L2/L3の番人「IP Source Guard（IPSG）」について深掘りしていこう。
—
なぜ、IP Source Guardが必要なのか？
IPスプーフィング（なりすまし）の脅威は、単なるDoS攻撃だけではない。中間者攻撃（MITM）の踏み台や、認証をバイパスして管理ネットワークに侵入する足掛かりとして頻繁に利用される。
多くのネットワーク管理者は DHCP Snooping を有効にしているはずだが、あれはあくまで「DHCPの応答を正しく選別する」ためのものだ。IPSGは、その先へ行く。「DHCP Snoopingで学習したバインディング情報を元に、スイッチポートに流れてくる全てのIPパケットの正当性を、ハードウェアレベルで検証する」技術だ。
これがあれば、いくら端末側で ifconfig や ip addr を叩いてIPを偽装しようとしても、スイッチがそのパケットを容赦なくドロップしてくれる。
—
IPSGのメカニズム：信頼のバインディング
IPSGがパケットを許可する条件は単純明快だ。「そのポートで過去にDHCPで取得したIP/MAC/VLAN/Interfaceの組み合わせと、パケットのヘッダが完全に一致するか」、これだけである。
シーケンスを整理してみよう。
1. バインディングDBの構築: 端末がDHCPでIPを取得する際、スイッチがDHCPパケットを覗き見（Snooping）し、MACアドレスとIPアドレスのペアを「バインディングデータベース」に登録する。
2. フィルタリングの適用: IPSGが有効化されたポートでは、ハードウェア（ASIC）がそのポートを通過する全パケットのソースIPを確認する。
3. 検証と破棄: データベースに存在しないIP、あるいはポート番号と一致しないIPからのパケットは、CPUに到達する前にスイッチのハードウェアレベルで即座に破棄される。
—
実装の勘所：スイッチ設定のサンプル
現場でIPSGを有効にする際は、必ず DHCP Snooping が前提となる。Cisco CatalystやNexusでの基本的な設定手順を見てみよう。
# 1. まずDHCP Snoopingを有効化（VLAN毎に指定）
ip dhcp snooping
ip dhcp snooping vlan 10
# 2. 信頼できるポート（アップリンクなど）を設定
interface GigabitEthernet0/1
description Uplink to Core
ip dhcp snooping trust
# 3. ユーザーアクセスポートでIPSGを有効化
interface GigabitEthernet0/2
description User Workstation
# ここでソースIPとMACの両方をチェックする設定
ip verify source port-securityもし、静的IPを使用しているデバイス（サーバーやプリンタなど）がある場合は、手動でバインディングを登録する必要がある点に注意してほしい。
# 静的IPデバイスの登録（データベースを手動で補完）
ip source binding 0011.2233.4455 vlan 10 192.168.10.50 interface GigabitEthernet0/2—
開発現場からの視点：デバッグと検証
Web APIの開発者がインフラの挙動を疑うとき、最も困るのが「通信が突然消える」現象だ。IPSGが有効な環境でIPアドレスを固定で振ってしまうと、何も言わずに通信が遮断される。
もし、開発中のサーバーやIoTデバイスが「なぜか応答しない」という事態に陥ったら、curl で導通確認をする前に、まずはスイッチのログとバインディング情報を確認してほしい。
1. バインディング情報の確認
show ip source binding
# 自分のデバイスのIP/MACが正しく登録されているかを確認2. ログによるドロップ検知
スイッチ側でパケット破棄が発生している場合、コンソールには以下のようなログが出るはずだ。
%IP_SOURCE_GUARD-4-IP_ADDRESS_FILTERING_FAILED
3. API疎通確認（クライアントサイド）
もし通信経路にIPSGがあるか不明な場合、curl でヘッダー情報を追いかけつつ、タイムアウトが発生するかどうかでL2レベルのブロックかアプリケーションレベルの拒否かを切り分ける。
# 詳細な接続統計を表示して、どこで止まっているかを確認する
curl -v -I http://192.168.10.100 --connect-timeout 5—
最後に：完璧な防御など存在しない
IP Source Guardは強力だが、銀の弾丸ではない。MACアドレスまで巧妙に偽装された場合や、スイッチのバインディングテーブルを枯渇させる攻撃（DHCP飢餓攻撃）には別の対策が必要だ。
しかし、こうして「ネットワークの入り口」を厳格に管理する姿勢こそが、大規模なインフラを運用するエンジニアの矜持だ。「なんとなく繋がっている」状態を卒業し、「このパケットはここを通る資格がある」と断言できる環境を作ろう。
もし現場で不可解な通信断に遭遇したら、まずはスイッチのポート統計を見ろ。パケットは嘘をつかない。それが、先人たちが教えてくれたネットワークトラブルシューティングの第一歩だ。
健闘を祈る。
コメント