スイッチが「ただの箱」に成り下がる瞬間：MACアドレステーブル溢れと実戦的防衛術
ネットワークエンジニアとして現場に立つと、時折「なぜかネットワークが極端に遅い」「特定のセグメントで通信が不安定になる」といった不可解な現象に遭遇することがあります。論理設計は完璧、ケーブルも問題ない。そんな時、ベテランの脳裏をよぎるのがMACアドレステーブル溢れ（MAC Table Overflow）、いわゆるMACフラッディング攻撃です。
今日は、スイッチの知性を逆手に取り、ネットワークを「ダムなハブ」へと強制退化させるこの攻撃のメカニズムと、それを未然に防ぐための実務的アプローチについて、深掘りしていきましょう。
—
1. MACアドレステーブルの「限界」が招く悲劇
スイッチは、フレームの送信元MACアドレスを学習し、どのポートからそのデバイスに到達できるかを CAM (Content Addressable Memory) テーブルに記録します。本来、このテーブルは非常に高速で効率的なスイッチングを行うための「賢い索引」です。
しかし、このテーブルには物理的な容量限界があります。攻撃者はこの限界を逆手に取ります。
攻撃のシーケンス
1. 偽装の嵐: 攻撃用ツール（macofなどが有名ですね）を使い、送信元MACアドレスをランダムに変更した大量のフレームをスイッチに送りつけます。
2. メモリの枯渇: スイッチは健気に、受信したすべての未知のMACアドレスをテーブルに書き込みます。ほどなくして、テーブルは飽和します。
3. フェイルオープン（ハブ化）: テーブルが溢れると、スイッチは新しいアドレスを学習できなくなります。設計上の仕様として、宛先不明のフレームを「全ポートにフラッディング（Broadcast）」する挙動に切り替わります。
この瞬間、本来は特定の相手にしか届かないはずのパケットが、ネットワーク上の全ノードに届くようになります。トラフィックの飽和によるパフォーマンス低下だけでなく、パケットスニッフィング（盗聴）の格好の舞台が出来上がってしまうのです。
—
2. 実践的な防御策：Port Securityの鉄則
この攻撃に対する最も強力かつ標準的な防衛策は、Cisco等のスイッチが実装している Port Security です。これを適切に設定することで、ポートごとのMACアドレス学習数に上限を設け、不正なアクセスを門前払いできます。
以下は、信頼できるアクセスポートに対する典型的な設定例です。
! ポートのモードをアクセスに固定し、Port Securityを有効化
interface GigabitEthernet0/1
switchport mode access
switchport port-security
! 学習するMACアドレスの最大数を制限（例：最大2つ）
switchport port-security maximum 2
! MACアドレスを動的に学習し、スタティック設定として保存
switchport port-security mac-address sticky
! 違反時の挙動：シャットダウン（最も安全）
switchport port-security violation shutdown実務のヒント: いきなり shutdown を適用すると、少しの誤検知で現場がパニックになります。まずは protect や restrict モードでログを監視し、ベースラインを把握してから shutdown に切り替えるのが、熟練エンジニアの流儀です。
—
3. なぜ「APIエンジニア」もこれを気にするべきか
「ネットワークはインフラ屋の仕事でしょ？」と思われるかもしれません。しかし、クラウドネイティブな環境であっても、コンテナのネットワークスタックや仮想スイッチ（vSwitch）の限界を考慮する必要があります。
例えば、Pythonを使って大量の偽装パケットを生成するようなテストコードを書く際、scapy を使うのが一般的です。
from scapy.all import Ether, IP, sendp
import random
# ランダムなMACアドレスを生成してパケットを送り続けるテスト用スクリプト
def flood_network(interface="eth0"):
while True:
# ランダムなMACを生成
src_mac = ":".join(["%02x" % random.randint(0, 255) for _ in range(6)])
packet = Ether(src=src_mac, dst="ff:ff:ff:ff:ff:ff") / IP(dst="192.168.1.255")
sendp(packet, iface=interface, verbose=False)
# 注意: このコードは検証環境以外では絶対に実行しないでくださいAPI設計者として、こうした低レイヤーの挙動を知っておくことは、「通信の秘匿性」や「DoS攻撃への耐性」をアプリケーション層からどう補完すべきかを考える重要な判断材料になります。
—
最後に：ネットワークは「性悪説」で設計せよ
ネットワーク機器は非常に優秀ですが、設計上、物理的な制限を突きつけられると非常に脆い一面を持っています。RFCでは、スイッチのこうした学習アルゴリズムや転送挙動について細かく規定されていますが、それは「正常な動作」を前提としたルールです。
現場でトラブルシューティングを行う際は、スイッチのテーブルを show mac address-table count 等で常にモニタリングし、異常な学習数がないか目を光らせてください。
完璧な防御は存在しませんが、適切な制限とログ監視があれば、攻撃の芽を早期に摘み取ることは可能です。皆さんのネットワークが、今日も安定してパケットを届け続けることを願っています。
それでは、また次回の深淵でお会いしましょう。
コメント