ちらりんブログ ロゴ ちらりんブログ
STUDY · NETWORK GUIDE

4-4 L2 セキュリティ — Port-Security / DHCP Snooping / DAI

L2 で成立する攻撃を止める Port-Security・DHCP Snooping・DAI の 3 つの防御を扱う。DHCP Snooping の binding table が DAI の入力になる縦の連鎖を主役に、CML 実機 (iosvl2) の show 出力で検証する。

1. 前節の振り返りと本節の内容

前節 4-3 802.1X では、スイッチのアクセスポートに接続した端末を、ネットワークへ通す前に RADIUS サーバで認証する IEEE 802.1X を扱いました。802.1X が解く問題は「正規の端末だけを通す」ことであり、認証を通った端末にポートを開き、資格情報を持たない端末をポートで止める仕組みでした。

本節で扱う L2 セキュリティ機能 は、同じ L2 の防御でも視点が逆です。802.1X が「正しい端末を通す (認証)」のに対し、本節の Port-Security / DHCP Snooping / DAI (Dynamic ARP Inspection) は「不正なフレームそのものを止める (フィルタ)」機能群です。端末が正規かどうかを問う前に、フレームの内容 (送信元 MAC の数・DHCP の応答方向・ARP の中身) を見て、L2 で成立する攻撃を入口で破棄します。802.1X が認証で守る穴と、本節のフィルタで守る穴は別であり、両者は補完関係にあります。

本節では、L2 の代表的な 3 つの攻撃を起点に、それぞれを止める防御機能を順に見ます。MAC フラッディング・MAC なりすましには Port-Security、不正な DHCP サーバ (Rogue DHCP) には DHCP Snooping、ARP スプーフィング (中間者攻撃) には DAI を対応させます。とりわけ、DHCP Snooping が作る台帳 (binding table) が DAI の入力になる 縦の連鎖 を主役に据えます。CML 上の iosvl2 で、Port-Security の violation shutdown と復旧、DHCP Snooping の信頼境界と binding table、DAI の有効化と ARP 突合の様子を実機の show 出力で検証します。

2. L2 が無防備な理由 — CAM 自動学習・DHCP・ARP の性善説

L2 のスイッチが提供する基本機能の多くは、接続される端末を信頼する前提 (性善説) で設計されています。この前提が、L2 を攻撃の土壌にしています。攻撃の中身に入る前に、なぜ L2 が無防備になりがちなのかを 3 点で整理します。

第一に、スイッチの CAM (Content Addressable Memory) テーブルは、流れてきたフレームの送信元 MAC アドレスを無条件に学習 します (2-2 スイッチングの仕組み で扱いました)。誰が送ってきた MAC かを問わず学習するため、攻撃者が偽の送信元 MAC を大量に送りつけると CAM テーブルが溢れ、スイッチが学習済みエントリを保持できなくなります。この状態のスイッチは宛先 MAC が分からないフレームを全ポートへ転送 (フラッディング) するため、攻撃者は本来自分宛でないフレームまで受信できます。これが MAC フラッディング攻撃 です。また、正規端末の MAC を騙る MAC なりすまし も、CAM が送信元を検証しないことに付け込みます。

第二に、DHCP (Dynamic Host Configuration Protocol) は、応答するサーバの正当性を端末が検証しません。端末は受け取った応答 (DHCPOFFER) の中から 1 台のサーバを選んで DHCPREQUEST を送り、そのサーバが返す DHCPACK で IP・デフォルトゲートウェイ・DNS が確定しますが、応答元が正規のサーバかどうかは確かめません。多くの実装では先に届いた応答を採用するため、攻撃者が偽の DHCP サーバ (Rogue DHCP) をアクセスポートに繋ぎ、本物より早く応答すれば、その偽のサーバが選ばれて偽の設定が確定し、端末のデフォルトゲートウェイを攻撃者の IP に書き換えられます。デフォルトゲートウェイは宛先がサブネット外にある通信の次ホップなので、以降その端末の外部ネットワーク宛の通信が攻撃者を経由するようになり、中間者攻撃 (Man-in-the-Middle) の足場になります。

第三に、ARP (Address Resolution Protocol) は、応答の真偽を確かめる仕組みを持ちません。ARP は「この IP アドレスの MAC は何か」を問い合わせ、返ってきた応答を無条件に ARP テーブルへ書き込みます。攻撃者が「デフォルトゲートウェイの IP は自分の MAC だ」という偽の ARP 応答 (Gratuitous ARP) を送れば、端末の ARP テーブルが汚染され、ゲートウェイ宛の通信が攻撃者へ流れます。これが ARP スプーフィング です。

L3 のファイアウォールや IDS (Intrusion Detection System) が検査できるのはセグメントをまたぐ通信だけで、同一 VLAN 内で完結するこれらの攻撃は L3 機器を通りません。L2 で発生する攻撃は、L2 のスイッチ自身が止める必要があります。以降、攻撃ごとに対応する防御機能を順に整理します。

3. Port-Security — 許可 MAC を制限する

Port-Security は、アクセスポートで学習する MAC アドレスの個数と種類 を制限する機能です。§2 で述べた CAM の無条件学習に制約を課し、想定外の端末が接続された瞬間に対処します。1 つのアクセスポートに繋がる端末は通常 1 台、IP 電話を経由する構成でも 2 台が上限であり、それを超える MAC が現れたら「想定外の機器が接続された」と判断する、というのが基本発想です。これにより MAC フラッディングや MAC なりすましを入口で抑えます。

Port-Security では、許可する MAC を学習・指定する方法が 3 つに分かれます。違いは以下のとおりです。

  • 静的 (static) — 許可する MAC を switchport port-security mac-address <MAC> で 管理者が明示指定 する方法。後述する実機の show では Type が SecureConfigured と表示されます。
  • sticky — switchport port-security mac-address sticky を設定すると、ポートが最初に学習した MAC を running-config へ動的に書き込む 方法。show では Type が SecureSticky と表示されます。sticky を使わず動的学習だけにすると、再起動後に許可 MAC が消えるため、運用では sticky か静的指定を併用します。ただし sticky で running-config に書かれた MAC も、copy running-config startup-config (write memory) で設定を保存しなければ再起動で失われます。再起動をまたいで許可 MAC を維持するには、sticky 学習後に設定を保存します。
  • 最大数 (maximum) — switchport port-security maximum N で、そのポートで学習を許す MAC 数の上限を指定します (既定 1)。

さらに、上限を超える MAC (許可外 MAC) が現れたときの動作を violation mode で選びます。

  • shutdown (既定) — ポートを err-disabled 状態に落とし、以後そのポートの通信を完全に遮断します。最も厳格な動作で、syslog も出力します。
  • restrict — 違反フレームを破棄しつつ、ポートは up のまま維持し、違反カウンタの加算と syslog を行います。
  • protect — 違反フレームを破棄するだけで、カウンタ加算も syslog 出力もしません。

Port-Security の設定は、アクセスポートに対して以下の形で投入します。

cisco 
interface GigabitEthernet0/1
 switchport mode access
 switchport access vlan 10
 switchport port-security
 switchport port-security maximum 1
 switchport port-security violation shutdown
 switchport port-security mac-address 5254.0000.0011

switchport port-security で機能を有効化し、maximum 1 で 1 つの MAC だけを許可、violation shutdown で違反時にポートを落とす設定です。最後の行で許可する MAC を静的に固定しています。sticky にする場合は最終行を switchport port-security mac-address sticky に置き換えます。本節の検証では、Gi0/1 を静的指定、対照として Gi0/2 を sticky にしています。

4. ラボトポロジ

本節の検証で使うトポロジを示します。SW1 (iosvl2) 1 台が入口で、Port-Security・DHCP Snooping・DAI の 3 つの防御を張ります。

4-4 L2 セキュリティ ラボトポロジ。SW1 (iosvl2) が 1 台で 3 つの防御を張る防御点。Gi0/1 が R1 (DHCP サーバ) 方向、Gi0/2 が端末方向。Port-Security の検証時は許可 MAC を PC1 に固定し、DHCP Snooping / DAI の検証時は Gi0/1 を trust・端末側を untrust とする信頼境界として使う。この図は 3 機能の配置を 1 枚に束ねた概念図であり、実機の Port-Security 検証と DHCP Snooping / DAI 検証は別々のラボで、ポート割当・MAC アドレスは検証ごとに異なる

ここで注意すべき点があります。この静止図は 3 つの機能の配置を 1 枚に束ねた 概念図 であり、実際の検証は機能ごとに別のラボで行っています。検証ごとにポート割当と MAC アドレスが異なるため、混同しないよう各検証の構成を以下に分けて示します。

  • Port-Security 検証時 — SW1 の Gi0/1 に正規端末 PC1 (MAC 5254.0000.0011) を静的指定で許可し、Gi0/2 に PC2 (MAC 5254.0000.0022) を sticky で許可します。違反は、許可外の攻撃端末 PC3 (MAC 5254.0000.0033) が Gi0/1 に現れたときに発火します。
  • DHCP Snooping / DAI 検証時 — SW1 の Gi0/1 を DHCP サーバ R1 への上流ポートとして trust、Gi0/2 を正規端末 PC1 (MAC 5254.0000.00aa / IP 192.168.10.50) へのアクセスポートとして untrust にします。

以降、§5・§6 で Port-Security 検証時の構成を、§7 以降で DHCP Snooping / DAI 検証時の構成を扱います。

機能を有効化した直後、まだ違反が起きていない状態の Port-Security 全体を show port-security で確認します。

snippet 
SW1#show port-security
Secure Port  MaxSecureAddr  CurrentAddr  SecurityViolation  Security Action
                (Count)       (Count)          (Count)
---------------------------------------------------------------------------
      Gi0/1              1            1                  0         Shutdown
      Gi0/2              1            1                  0         Shutdown
---------------------------------------------------------------------------

Gi0/1・Gi0/2 とも、許可できる MAC の上限 (MaxSecureAddr) が 1、現在学習済みの MAC (CurrentAddr) が 1、違反回数 (SecurityViolation) が 0 です。Security Action が Shutdown で、上限を超えた MAC が現れたらポートを落とす設定であることが分かります。両ポートとも違反回数が 0 で、正規端末だけが接続された正常な状態です。

許可された MAC が静的か sticky かは、show port-security address の Type 列で区別できます。

snippet 
SW1#show port-security address
               Secure Mac Address Table
-----------------------------------------------------------------------------
Vlan    Mac Address       Type                          Ports   Remaining Age
                                                                   (mins)    
----    -----------       ----                          -----   -------------
  10    5254.0000.0011    SecureConfigured              Gi0/1        -
  10    5254.0000.0022    SecureSticky                  Gi0/2        -
-----------------------------------------------------------------------------

Gi0/1 の MAC 5254.0000.0011 は Type が SecureConfigured で、管理者が静的に指定した許可 MAC です (§3)。Gi0/2 の MAC 5254.0000.0022 は Type が SecureSticky で、ポートが学習して running-config に書き込んだ sticky の許可 MAC です。同じ Port-Security でも、許可 MAC を「明示指定したもの」と「学習させたもの」が Type 列で見分けられます。

5. Port-Security 違反の実機検証 — Secure-shutdown への遷移

許可外の MAC が現れたときに、Port-Security がポートを落とす様子を確認します。Gi0/1 は許可 MAC を PC1 (5254.0000.0011) に固定し、maximum 1・violation shutdown を設定してあります。ここに、許可されていない攻撃端末 PC3 (5254.0000.0033) の MAC が現れると、上限 1 を超えるため違反が発火します。

Port-Security 違反の流れ。許可 MAC = PC1 (5254.0000.0011) を固定した Gi0/1 (max 1 / violation shutdown) に、2 個目の MAC (攻撃端末 5254.0000.0033) が現れる → 上限超過で violation shutdown が発火しポートが Secure-shutdown / err-disabled に落ちる → 違反元の MAC (Last Source) と違反回数 (Count) を記録し、カウンタは累積する → 原因 (許可外の端末) を除去してから手動または errdisable recovery で復旧する

違反が起きた後、show port-security interface で Gi0/1 の状態を確認します。

snippet 
SW1#show port-security interface GigabitEthernet0/1
Port Security              : Enabled
Port Status                : Secure-shutdown
Violation Mode             : Shutdown
Aging Time                 : 0 mins
Aging Type                 : Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses      : 1
Total MAC Addresses        : 1
Configured MAC Addresses   : 1
Sticky MAC Addresses       : 0
Last Source Address:Vlan   : 5254.0000.0033:10
Security Violation Count   : 1

注目箇所は Port Status : Secure-shutdown で、違反によりポートが遮断状態に落ちたことを示します。Maximum MAC Addresses : 1 の上限に対し、許可外の MAC が現れたため違反が成立しました。Last Source Address:Vlan : 5254.0000.0033:10 が、違反を引き起こした送信元 MAC とその VLAN で、攻撃端末 PC3 の MAC 5254.0000.0033 が VLAN 10 で違反元として記録されています。Security Violation Count : 1 が違反回数で、1 回目の違反が計上されています。

ポートが err-disabled に落ちたことは、インターフェースの状態一覧でも確認できます。

snippet 
SW1#show interfaces status err-disabled

Port      Name               Status       Reason               Err-disabled Vlans
Gi0/1     PC1 (static-mac, v err-disabled psecure-violation

Gi0/1 の Status が err-disabled、Reason が psecure-violation (Port-Security 違反) で、Port-Security の違反によってポートが err-disabled になったことが分かります。err-disabled はポートを管理的に無効化した状態で、原因を取り除いて復旧操作をしない限り通信は再開しません。

violation shutdown は syslog も出力します。

snippet 
SW1#show logging | include psecure
*Jun  9 14:48:30.507: %PM-4-ERR_DISABLE: psecure-violation error detected on Gi0/1, putting Gi0/1 in err-disable state

%PM-4-ERR_DISABLE: psecure-violation error detected on Gi0/1 で、Port-Security 違反 (psecure-violation) を検知して Gi0/1 を err-disable 状態に置いたことがログに残ります。違反は管理者に通知され、不正な接続が記録として追跡できます。violation mode を restrict や protect にした場合はポートを落とさず違反フレームだけを破棄しますが、shutdown はポート全体を遮断する最も厳格なモードです。

6. 違反からの復旧 — 手動 / errdisable recovery

err-disabled に落ちたポートを復旧する方法は 2 つあります。手動復旧 と errdisable recovery による自動復旧 です。どちらの場合も、復旧の前に「違反を起こした原因 (許可外の端末) を取り除く」ことが前提です。原因を残したまま復旧すると、再び違反が発火して同じ状態に戻ります。

手動復旧は、対象ポートで shutdown の後に no shutdown を実行し、ポートを再投入します。許可外の端末を取り外してから手動復旧すると、ポートが正常な状態に戻ります。復旧後の show port-security interface は以下のようになります。

snippet 
SW1#show port-security interface GigabitEthernet0/1
Port Security              : Enabled
Port Status                : Secure-up
Violation Mode             : Shutdown
...
Last Source Address:Vlan   : 0000.0000.0000:0
Security Violation Count   : 1

注目すべきは 2 点です。第一に、Port Status : Secure-up で、§5 の Secure-shutdown から正常稼働状態へ戻っています。第二に、Last Source Address:Vlan : 0000.0000.0000:0 で、§5 で記録されていた違反元 MAC (5254.0000.0033:10) がクリアされ、最後の違反送信元の記録が消えています。一方で Security Violation Count : 1 は §5 と同じ 1 のままで、違反回数のカウンタは累積 します。Last Source は復旧でクリアされるのに対し、Violation Count はポートが過去に何回違反したかの履歴として残り続けます。この累積カウンタを監視すれば、復旧後も繰り返し違反が起きるポートを発見できます。

もう 1 つの復旧手段が errdisable recovery です。これは、err-disabled に落ちたポートを一定時間後に自動で再投入する機能で、errdisable recovery cause psecure-violation と errdisable recovery interval <秒> で有効化します。設定後の状態を show errdisable recovery で確認します。

snippet 
SW1#show errdisable recovery
...
psecure-violation            Enabled
...
Timer interval: 300 seconds

Interfaces that will be enabled at the next timeout:

Interface       Errdisable reason       Time left(sec)
---------       -----------------       --------------
Gi0/1          psecure-violation          254

psecure-violation Enabled で、Port-Security 違反に対する自動復旧が有効になっています。Timer interval: 300 seconds が再投入までの間隔で、最下部の一覧に Gi0/1 が psecure-violation を理由として挙がり、Time left(sec) 254 であと 254 秒で自動的に再有効化される予定だと分かります。指定した時間が経過すると、スイッチが自動でポートを復旧します。

自動復旧が実行されると、その旨が syslog に記録されます。

snippet 
SW1#show logging | include ERR_RECOVER
*Jun  9 14:05:07.207: %PM-4-ERR_RECOVER: Attempting to recover from psecure-violation err-disable state on Gi0/1

%PM-4-ERR_RECOVER: Attempting to recover from psecure-violation err-disable state on Gi0/1 で、Port-Security 違反による err-disable 状態から Gi0/1 を復旧しようとしていることがログに残ります。errdisable recovery は運用の手間を減らしますが、原因が残っていれば自動復旧と再違反を繰り返す 点に注意が必要です。タイマー経過で再投入されたポートに許可外の端末がまだ繋がっていれば、再び違反して err-disabled に戻ります。自動復旧はあくまで一時的な不調からの自動回復を意図したもので、攻撃が継続している間は §5 の違反検知ログと §6 の累積カウンタで原因を特定し、原因を除いてから復旧させるのが原則です。

7. DHCP Snooping — 不正 DHCP サーバを止める

ここからは別のラボに移り、DHCP Snooping と DAI を扱います。DHCP Snooping (DHCP スヌーピング) は、スイッチが流れる DHCP メッセージの中身を覗き見て、偽の DHCP サーバ (Rogue DHCP) から来た Offer / ACK を遮断する 機能です。§2 で述べた「端末がサーバの正当性を検証しない」という DHCP の弱点を、スイッチが代わりに塞ぎます。

DHCP Snooping の核心は 信頼境界 (trust / untrust) の設計です。ポートを 2 種類に分けます。

  • trust (信頼ポート) — 正規の DHCP サーバが繋がっている方向のポート。DHCP の全メッセージ (サーバ応答である Offer / ACK を含む) を通します。
  • untrust (非信頼ポート) — 端末が繋がっているアクセスポート。サーバ応答 (Offer / ACK) が untrust ポートから来たら破棄 します。端末が出す要求 (Discover / Request) は通します。

正規 DHCP サーバへの上流ポートだけを trust にし、端末側を untrust のままにしておくと、untrust 側 (端末側) に繋がれた偽 DHCP サーバが返す Offer / ACK は破棄されます。端末側にサーバが居るのは異常だ、という設計判断を trust 境界で表現します。設定は VLAN 単位で有効化し、上流ポートにだけ trust を投入します。

cisco 
ip dhcp snooping
ip dhcp snooping vlan 10
!
interface GigabitEthernet0/1
 description Uplink to DHCP server
 ip dhcp snooping trust

ip dhcp snooping vlan 10 で VLAN 10 上の DHCP メッセージを監視対象にし、正規 DHCP サーバ R1 への上流ポート Gi0/1 にだけ ip dhcp snooping trust を投入します。端末側の Gi0/2 は既定の untrust のままでよく、明示設定は不要です。

DHCP Snooping のもう 1 つの役割が binding table の構築 です。untrust ポートを流れる DHCP のやり取りを観測し、サーバが IP を確定する DHCPACK のタイミングで (IP, MAC, ポート, VLAN, リース時間) の対応関係を記録します。この台帳が、次の §9 で扱う DAI の入力になります。DHCP Snooping は「偽 DHCP を止める」と同時に「誰がどの IP を正規に得たか」を記録する役を兼ね、その記録が ARP 検査の根拠データになる、という縦の繋がりを持ちます。

8. DHCP Snooping の実機検証

DHCP Snooping の動作を iosvl2 で確認します。構成は §4 の「DHCP Snooping / DAI 検証時」のとおりで、R1 (csr1000v) を VLAN 10 セグメント (192.168.10.0/24) の DHCP サーバ、SW1 の Gi0/1 を R1 への上流ポート (trust)、Gi0/2 を端末 PC1 へのアクセスポート (untrust) としています。

まず機能の有効状態と trust 一覧を show ip dhcp snooping で確認します。

snippet 
SW1#show ip dhcp snooping
Switch DHCP snooping is enabled
Switch DHCP gleaning is disabled
DHCP snooping is configured on following VLANs:
10
DHCP snooping is operational on following VLANs:
10
...
Interface                  Trusted    Allow option    Rate limit (pps)
-----------------------    -------    ------------    ----------------   
GigabitEthernet0/1         yes        yes             unlimited

Switch DHCP snooping is enabled で機能が有効、DHCP snooping is operational on following VLANs: 10 で VLAN 10 上で実際に動作中であることが分かります。configured と operational が両方 VLAN 10 を挙げているのが、設定されているだけでなく稼働している状態です。末尾の trust 一覧には GigabitEthernet0/1 が Trusted: yes で現れ、ここが正規 DHCP サーバへの上流ポート (trust 境界) であることを示します。これに対し、一覧に出てこない Gi0/2 (PC1 側) は既定の untrust のままで、明示設定が不要であることが裏付けられます。

次に binding table を show ip dhcp snooping binding で確認します。

snippet 
SW1#show ip dhcp snooping binding
MacAddress          IpAddress        Lease(sec)  Type           VLAN  Interface
------------------  ---------------  ----------  -------------  ----  --------------------
52:54:00:00:00:AA   192.168.10.50    86130       dhcp-snooping   10    GigabitEthernet0/2
Total number of bindings: 1

(MAC 52:54:00:00:00:AA, IP 192.168.10.50) が VLAN 10・Gi0/2 のエントリとして登録されています。Type 列が dhcp-snooping で、この binding が DHCP メッセージの観測 (または同等の静的投入) によって作られたものであることを示します。この 1 行が、次節の DAI が「正規の IP↔MAC 対応」を判断する根拠データになります。

なお、本ラボの binding は検証の都合で 静的に投入 したものです。binding を実際の DHCP のやり取りで自然に育てるには端末側が DHCP Discover を送出する必要がありますが、検証端末 PC1 (Alpine Linux) は非特権実行で raw socket を開けず、DHCP クライアントを起動できません。そこで binding table の見え方を示すために手動投入していますが、Type は dhcp-snooping のまま であり、本番環境で DHCP のやり取りから自動生成されるエントリと同じ形式の台帳を見せられます。

統計情報も確認します。

snippet 
SW1#show ip dhcp snooping statistics
 Packets Forwarded                                     = 75
 Packets Dropped                                       = 0
 Packets Dropped From untrusted ports                  = 0

trust 境界を越えて転送された DHCP パケットが 75、破棄が 0 です。untrust ポートから偽の Offer / ACK が流れてくれば Packets Dropped From untrusted ports が増えますが、本ラボでは偽 DHCP サーバを実際に注入していないため 0 のままです。これは「機能が有効で、不正な DHCP 応答が来ていない正常系」を示す状態であり、本節では偽 DHCP の注入による drop の実発生は撮っていません (理由は §12 で補足します)。trust 境界が設定され、binding table が形成され、untrust からの drop カウンタが 0 で待機している、という有効な状態を主証跡とします。

9. DAI — ARP スプーフィングを止める

DAI (Dynamic ARP Inspection) は、untrust ポートを流れる ARP メッセージの中身を検査し、偽装された ARP を破棄する 機能です。§2 で述べた「ARP が応答の真偽を確かめない」という弱点を塞ぎ、ARP スプーフィングによる中間者攻撃を止めます。

DAI の核心は、何を正しい ARP とみなすかの判断材料が DHCP Snooping の binding table である点です。DAI は untrust ポートから ARP メッセージを受け取ると、その ARP が主張する (送信元 IP アドレス, 送信元 MAC アドレス) の組を binding table と突き合わせます。binding に一致する組であれば正規の ARP として転送 (permit) し、binding に存在しない組であれば偽装とみなして破棄 (drop) します。§8 で DHCP Snooping が作った「この MAC はこの IP を正規に得た」という台帳が、DAI の検査基準になる、という縦の連鎖がここで効きます。

DAI も DHCP Snooping と同じく trust / untrust の境界 を持ちます。正規 DHCP サーバ・上流スイッチへの方向を trust にして ARP 検査を免除し、端末側の untrust ポートを通る ARP だけを binding table と突合します。trust ポートを通る ARP は検査せずに通すため、DHCP Snooping の trust 境界と整合するよう設計します。設定は VLAN 単位で有効化します。

cisco 
ip arp inspection vlan 10
!
interface GigabitEthernet0/1
 ip arp inspection trust

ip arp inspection vlan 10 で VLAN 10 上の ARP 検査を有効化し、上流ポート Gi0/1 を ip arp inspection trust にして検査を免除します。端末側の Gi0/2 は既定の untrusted のままで、ここを通る ARP が binding table と突き合わせられます。binding に存在しない端末を救済したい場合は、ip arp inspection filter <ARP ACL 名> vlan <VLAN> で静的な ARP ACL を併用します。

10. DAI の実機検証

DAI の動作を iosvl2 で確認します。構成は §8 の DHCP Snooping と同じラボで、§8 で形成した binding table を DAI の入力として使います。SW1 で ip arp inspection vlan 10 を有効化し、上流ポート Gi0/1 を trust、端末側 Gi0/2 を untrusted としてあります。

まず DAI の有効状態を show ip arp inspection vlan で確認します。

snippet 
SW1#show ip arp inspection vlan 10

Source Mac Validation      : Disabled
Destination Mac Validation : Disabled
IP Address Validation      : Disabled

 Vlan     Configuration    Operation   ACL Match          Static ACL
 ----     -------------    ---------   ---------          ----------
   10     Enabled          Active      DAI-PC1            No

VLAN 10 の Configuration が Enabled、Operation が Active で、DAI が設定され実際に稼働しています。ACL Match 列に DAI-PC1 とあり、binding table に加えて静的な ARP ACL (DAI-PC1) も検査に併用されています。Static ACL : No は、ACL に一致しなかった ARP を「静的 ACL だけで拒否する (DHCP binding を見ない)」モードにはしていないことを示し、binding table を主たる判断材料とするフォールバック動作になっています。冒頭の 3 つの Validation (Source Mac / Destination Mac / IP Address) はいずれも Disabled で、追加の検証オプションを有効化していない基本構成です。

trust 境界はインターフェース単位で確認します。

snippet 
SW1#show ip arp inspection interfaces

 Interface        Trust State     Rate (pps)    Burst Interval
 ---------------  -----------     ----------    --------------
 Gi0/0            Untrusted               15                 1
 Gi0/1            Trusted               None               N/A
 Gi0/2            Untrusted               15                 1

Gi0/1 Trusted で、R1 (DHCP サーバ) への上流ポートが trust に設定され、ここを通る ARP は検査が免除されます。一方 Gi0/2 Untrusted で、端末 PC1 への アクセスポートは untrusted であり、ここを通る ARP が binding table と突き合わせられます。untrust ポートには Rate (pps) 15 のレート制限がかかり、ARP を大量に送りつける攻撃 (DoS) も抑えられます。ここで注目すべき点は、§8 の DHCP Snooping の trust 境界 (Gi0/1 = trust) と DAI の trust 境界が一致するよう揃えられている設計です。

検査の実績は統計で確認します。

snippet 
SW1#show ip arp inspection statistics vlan 10

 Vlan      Forwarded        Dropped     DHCP Drops      ACL Drops
 ----      ---------        -------     ----------      ---------
   10             15              0              0              0

 Vlan   DHCP Permits    ACL Permits  Probe Permits   Source MAC Failures
 ----   ------------    -----------  -------------   -------------------
   10              0             15              0                     0

VLAN 10 で Forwarded 15 の ARP が転送され、Dropped 0 で破棄はゼロです。下段の ACL Permits 15 が、ARP ACL (DAI-PC1) との突合で許可された数で、正規端末 PC1 の ARP が許可されたことを示します。DHCP Permits 0 は、本ラボの ARP が ARP ACL 側で先にヒットしたため DHCP binding 経由の permit が計上されていないことによります。偽装 ARP を注入すれば binding にも ACL にも一致せず Dropped が増えますが、本ラボでは偽 ARP を注入していないため Dropped 0 の正常系です。DAI が Active で trust 境界が張られ、正規 ARP を permit (Forwarded) し、untrust の ARP を binding/ACL と突合する準備が整っている、という有効な状態を主証跡とします。

突合に使われる ARP ACL の中身も確認できます。

snippet 
SW1#show arp access-list
ARP access list DAI-PC1
    permit ip host 192.168.10.50 mac host 5254.0000.00aa

ARP ACL DAI-PC1 は permit ip host 192.168.10.50 mac host 5254.0000.00aa という 1 行で、「IP 192.168.10.50 を主張する ARP は MAC 5254.0000.00aa でなければ許可しない」という対応を固定しています。これは §8 の binding table のエントリ (MAC 52:54:00:00:00:AA, IP 192.168.10.50) と同じ対応であり、攻撃端末が「192.168.10.50 は自分の MAC だ」と偽の ARP を送っても、MAC が 5254.0000.00aa でない限り破棄されます。binding table と ARP ACL が同じ IP↔MAC 対応を表現し、ARP スプーフィングを止める根拠になっています。

11. DHCP Snooping → DAI の連鎖

ここまで Port-Security・DHCP Snooping・DAI を順に見てきましたが、本節で最も重要なのは DHCP Snooping と DAI が縦に連鎖する 構造です。3 機能のうち、DHCP Snooping と DAI は独立した別機能ではなく、前者の出力 (binding table) が後者の入力になる依存関係でつながっています。

DHCP Snooping → DAI の縦の連鎖。①trust 境界を引く (trust = 正規サーバ方向 Gi0/1 / untrust = 端末方向) → ②untrust から来た Rogue DHCP のサーバ応答を drop し、正規 DHCP のやり取りから binding table を形成する (binding table = 「この MAC はこの IP」の台帳) → ③DAI が binding table を入力に、untrust ポートを通る ARP の IP↔MAC を突合し、binding に一致する ARP は permit、binding に無い偽装 ARP は破棄する。DHCP Snooping が作った台帳が DAI の検査基準になる

連鎖を段階で整理します。

  1. trust 境界を引く — DHCP Snooping で、正規 DHCP サーバへの上流ポート (Gi0/1) を trust、端末側 (Gi0/2) を untrust にします (§7・§8)。DAI も同じ境界を引き、Gi0/1 を trust、Gi0/2 を untrusted にします (§9・§10)。2 つの機能が同じ trust 境界を共有することが連鎖の前提です。
  2. binding table を形成する — DHCP Snooping が untrust ポートを流れる DHCP のやり取りを観測し、(IP, MAC, ポート, VLAN) の対応を binding table に記録します (§8)。untrust 側に繋がれた Rogue DHCP のサーバ応答はこの段階で破棄され、台帳には正規の対応だけが残ります。
  3. binding table を DAI が使う — DAI が untrust ポートを通る ARP を受け取り、その ARP が主張する (送信元 IP, 送信元 MAC) を binding table と突き合わせます (§10)。一致すれば permit、一致しなければ偽装として drop します。

この連鎖があるため、DAI は DHCP Snooping を前提とします。DHCP Snooping を有効化せず binding table が空のままで DAI だけを有効化すると、untrust ポートを通るすべての ARP が「binding に存在しない」と判定され、正規端末の ARP まで破棄されてしまいます。DHCP を使わず固定 IP で運用する端末がある場合は、§9 で触れた ARP ACL (static ACL) を併用して、binding table に無い正規端末を救済します。本ラボの ARP ACL DAI-PC1 (§10) は、その救済を静的に表現した例です。

設計上の要点は、DHCP Snooping と DAI の trust 境界を一致させる ことです。両者の trust ポートがずれると、片方では信頼している方向を他方が検査するという矛盾が生じ、正規通信が落ちたり検査の穴が空いたりします。「正規サーバ・上流が trust、端末側が untrust」という同じ境界を 2 つの機能で共有するのが、L2 セキュリティの設計の勘所です。

12. Storm Control と落とし穴・補足

本ラボで確認した教科書の記述と実機挙動の対応、検証範囲の制約、設計上の注意点を記録します。

  1. Storm Control は本ラボの iosvl2 で実機確認できない — Storm Control は、ブロードキャスト・マルチキャスト・未知ユニキャストのトラフィックが一定の閾値を超えたときにフレームを破棄し、ブロードキャストストーム (L2 ループや異常端末による帯域の食い潰し) を抑える機能です。閾値を帯域の割合や pps で指定します。ただし本ラボの iosvl2 では show storm-control が % Invalid input を返し、機能そのものが非対応でした。そのため Storm Control は概念の説明に留め、実機 show は本節では提示していません。Storm Control に対応する実機 (Catalyst 等) では、storm-control broadcast level <%> のように設定し、show storm-control で抑制状況を確認できます。

  2. drop の実発生は撮っていない (正常系の show を主証跡にした) — DHCP Snooping の Packets Dropped From untrusted ports (§8) と DAI の Dropped (§10) は、本ラボではいずれも 0 です。これは、偽 DHCP サーバや偽装 ARP を実際に注入する攻撃を仕掛けていないためです。検証端末 (Alpine Linux) が非特権実行で raw socket を開けず、不正な DHCP / ARP パケットを生成できなかったことによります。そのため本節では「機能が有効化され、trust 境界が張られ、binding table が形成され、drop カウンタが 0 で待機している正常系の show」を主証跡としました。攻撃を注入すれば、これらの Dropped カウンタが加算され、不正フレームが破棄される様子が確認できます。

  3. binding は静的投入だが Type は同じ — §8 の binding table は、検証の都合で静的に投入したものです (端末が DHCP を自然に出せないため)。ただし投入後の Type は dhcp-snooping であり、本番環境で DHCP のやり取りから自動生成されるエントリと同じ table を見せられます。DAI の入力としての binding table の役割は、自動生成でも静的投入でも変わりません。

  4. DAI は DHCP Snooping を前提とする — DAI の判断材料は DHCP Snooping の binding table です (§11)。DHCP Snooping を有効化せずに DAI だけを有効化すると binding table が空になり、untrust ポートのすべての ARP が破棄されて正規端末まで通信不能になります。DAI を導入する際は、先に DHCP Snooping で binding table を育てるか、固定 IP の端末には ARP ACL を用意します。

  5. trust 境界の一致が設計の勘所 — DHCP Snooping と DAI は同じ trust / untrust 境界を共有します (§11)。「正規サーバ・上流方向が trust、端末側が untrust」という境界を 2 機能で一致させないと、正規通信が落ちる、または検査の穴が空きます。L2 セキュリティを設計するときは、まず信頼できる方向 (上流) と信頼できない方向 (端末側) を決め、その境界を Port-Security の許可範囲・DHCP Snooping の trust・DAI の trust で揃えます。

  6. violation mode は要件で使い分ける — Port-Security の violation mode は shutdown / restrict / protect の 3 つです (§3)。shutdown はポート全体を遮断し syslog も出すため、不正接続を確実に検知・追跡したい場合に向きます。restrict はポートを落とさず違反フレームだけ破棄して syslog を出すため、可用性を保ちつつ違反を記録したい場合に使います。protect はカウンタも syslog も出さず、運用での追跡性が乏しいため通常は推奨されません。検知・追跡を重視するなら shutdown または restrict を選びます。

13. 次節

本節では、L2 で成立する 3 つの攻撃を起点に、それを止める防御機能を扱いました。MAC フラッディング・なりすましには Port-Security が許可 MAC を制限し、違反時に violation shutdown でポートを err-disabled に落とすこと、Rogue DHCP には DHCP Snooping が trust 境界で偽のサーバ応答を破棄し binding table を作ること、ARP スプーフィングには DAI がその binding table を入力に untrust の ARP を突合して偽装を破棄することを、iosvl2 の show 出力で確認しました。とりわけ、DHCP Snooping が作る binding table が DAI の検査基準になる 縦の連鎖 と、2 機能の trust 境界を一致させる設計の勘所を整理しました。前節 4-3 の 802.1X が「正規端末を認証で通す」のに対し、本節は「不正なフレームをフィルタで止める」補完関係にあることも示しました。

ここまでの 4-1 ACL から 4-4 L2 セキュリティまでは、ポート・MAC・DHCP・ARP といった「個々の要素」を制御する仕組みでした。次節 4-5 Zone-Based Firewall では、インターフェースを ゾーン (zone) という単位でまとめ、ゾーン間を流れる通信をステートフルに検査するファイアウォール機能を扱います。ACL が「許可・拒否のルールを 1 本ずつ書く」のに対し、Zone-Based Firewall がどのようにゾーンの単位で通信ポリシーを表現するかを見ていきます。