L2の深淵：MACアドレステーブル溢れ（CAMテーブル枯渇）が引き起こす「ハブ化」の悪夢
ネットワークエンジニアの端くれであれば、一度は耳にしたことがあるだろう。「スイッチがハブ化する」という、現代のネットワークにおいて最も忌むべき事態の一つだ。L2スイッチの心臓部であるCAM（Content Addressable Memory）テーブルが枯渇し、スイッチがインテリジェントな転送を諦めて「全ポートへのフラッディング」という原始的な挙動に回帰する現象である。
今日は、この古典的かつ破壊的な「MACフラッディング攻撃」を、パケットレベルの挙動と、それを防ぐためのアーキテクチャ設計の観点から深掘りしていきたい。
—
1. CAMテーブルの物理的限界と「ハブ化」のメカニズム
スイッチのASIC上で動作するCAMテーブルは、有限のリソースだ。ここには MACアドレス と 物理ポート、そして VLAN ID が紐付けられ、ハードウェアベースでの高速なスイッチングを支えている。
攻撃者が行うことは単純だ。数万、数十万のランダムな送信元MACアドレスを持つイーサネットフレームを、短時間にスイッチへ向けて大量に送りつける。スイッチは律儀に、届いたすべての未知のMACアドレスをCAMテーブルに登録しようと試みる。
- 枯渇の瞬間: テーブルが満杯になると、新しいエントリを学習できなくなる。
- 未知の宛先: 正当な通信の宛先MACアドレスがテーブルに存在しない場合、スイッチは該当フレームを「未知のユニキャスト（Unknown Unicast）」と判断し、すべてのポート（VLAN内）に転送する。
結果として、ネットワーク内はブロードキャストストームに近い状態となり、パケットの盗聴（Sniffing）が容易になるだけでなく、全セグメントで無駄なトラフィックが氾濫し、ネットワークパフォーマンスは崩壊する。
—
2. 実践的防御：Port Securityの限界と最適解
この攻撃を防ぐ最も基本的な防御策は Port Security だ。特定の物理ポートで学習できるMACアドレスの数に上限を設け、違反が発生した際に shutdown させるのが定石だ。
CiscoにおけるPort Securityの基本設定例
interface GigabitEthernet0/1
# 特定のポートで学習できるMACアドレス数を最大2に制限
switchport port-security maximum 2
# 違反発生時にはポートを即時シャットダウン
switchport port-security violation shutdown
# スティッキー学習により現在のMACを静的エントリとして書き込む
switchport port-security mac-address stickyしかし、大規模なデータセンター環境でこれらを全ポートに適用するのは運用負荷が高い。本来は、信頼できない末端ポート（アクセスポート）には物理的な制限をかけ、上位レイヤーでは 802.1X 認証を強制するのが現代のインフラ設計の鉄則だ。
—
3. L2だけではない：TCP/IPスタックへの影響とパフォーマンスチューニング
MACフラッディングが引き起こす「ハブ化」は、単なるトラフィック増加に留まらない。エンドホストのTCPスタックにも甚大な負荷を与える。
ネットワーク輻輳とTCPバッファの関係
パケットがフラッディングされると、NICには本来不要なパケットが大量に到着する。Linuxカーネルはこれらを softirq で処理するため、CPU負荷が急増し、結果として正当なパケットの TCPセグメント の処理が遅延する。
ここで重要なのが、TCPウィンドウサイズ と バッファチューニング だ。ネットワークの遅延（RTT）が不安定な状況下で、デフォルトのバッファサイズ（sysctl で設定）が大きすぎると、再送制御が追い付かず、スループットが劇的に低下する。
# /etc/sysctl.conf での設定例
# TCP受信ウィンドウの最大値を制限し、輻輳時のメモリ枯渇を防ぐ
net.ipv4.tcp_rmem = 4096 87380 4194304
# TCPの輻輳制御アルゴリズムをBBRに変更（高遅延・パケットロスに強い）
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr—
4. セキュリティアーキテクトとしての視点
MACフラッディングのような原始的な攻撃が今なお有効である理由は、多くの組織が「内側は安全」という古いパラダイムに縛られているからだ。
1. VLANによる境界分離: 攻撃の影響を最小限に留めるため、マイクロセグメンテーションを実施し、L2ドメインを極小化する。
2. レートリミットの活用: Storm Control を設定し、特定のトラフィック量を超えた瞬間に破棄する設定をデフォルトとする。
3. モニタリング: SNMPやTelemetryを用いて、CAMテーブルの使用率をリアルタイムで監視する。使用率が80%を超えた時点でアラートを飛ばす運用は、もはや必須だ。
結論：プロトコルの美学を守るために
ネットワークの速度は レイテンシ と スループット のバランスで決まる。しかし、その土台となるL2層が堅牢でなければ、いくら上層の TLS 1.3 でハンドシェイクを最適化し、RTT を0に近づけたとしても、すべては砂上の楼閣だ。
MACアドレステーブルという小さなメモリ領域を守ることは、ネットワーク全体の「正当な通信」を守ることと同義である。現場のエンジニア諸君には、是非ともパケットキャプチャを日常的に行い、自身のスイッチがどのようなテーブル更新を行っているのか、その息遣いを感じ取ってほしい。
プロトコルの深淵を覗くとき、そこには必ずエンジニアの哲学が宿っているはずだ。
コメント