Cisco ZBFW の仕組みと設定手順｜ゾーンと Self Zone のポイント

はじめに

Cisco ルータには、Zone-Based Firewall（ZBFW） と呼ばれるステートフルファイアウォール機能が搭載されています。これを利用することで、ルータ単体で ASA や Firepower（FTD）と同等のセッション管理付きアクセス制御 が実現できます。

従来の ACL（アクセスコントロールリスト）はパケット単位で許可・拒否を判定する ステートレス な仕組みのため、行き通信を許可するだけでは戻り通信が通らず、双方向の許可ルールを個別に書く必要がありました。ZBFW はパケットの状態（セッション）を記憶する ステートフルインスペクション をルータ上で実現し、「行きを許可すれば戻りは自動で許可される」 設定が可能になります。

ZBFW は CBAC（Context-Based Access Control） と呼ばれた旧 IOS Firewall 機能の後継として、IOS 12.4(6)T 以降で導入されました。現在の IOS XE では CBAC は非サポート であり、ZBFW がルータ内蔵ファイアウォール機能の標準的な選択肢です。

なお、ステートフルインスペクションの仕組みについては、関連記事『FortiGate UTM 機能の仕組みと IPS 誤検知のリスクと対処』もあわせてご参照ください。

ZBFW（Zone-Based Firewall）の基本概念

ZBFW を理解する上で最も重要なのが、機能名にもなっている 「ゾーン（Zone）」 という考え方です。

ゾーン（Zone）とは

従来のファイアウォール（ACL）は 物理インターフェイス（Gi0/0 など）単位 でルールを決めていましたが、ZBFW ではインターフェイスを論理的なグループである 「セキュリティゾーン」 に割り当てて管理します。

インターフェイスがどのゾーンに属するかを決めることで、「Gi0/0 から Gi0/1 へ」ではなく 「INSIDE から OUTSIDE へ」 という、より直感的で管理しやすいポリシー適用が可能になります。

参考: Cisco IOS XE 17.x – Zone-Based Policy Firewalls
“A zone is a group of interfaces having similar functions or features. They help you specify where a Cisco IOS XE firewall should be applied.”
（ゾーンは類似の機能・特性を持つインターフェイスのグループであり、Cisco IOS XE ファイアウォールをどこに適用するかを指定するために使われます）
https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/sec-vpn/b-security-vpn/m_sec-zone-pol-fw-xe.html

デフォルトの動作

ZBFW を理解する上で最も重要なポイントは、ゾーンを作成しインターフェイスを割り当てた瞬間、ゾーン間の通信はデフォルトですべて遮断される ことです。

通信させたいゾーンの組み合わせ（ゾーンペア）に対して 明示的に許可ポリシーを設定しない限り、一切通信できなくなります。これにより、ホワイトリスト形式のセキュリティ制御を実現します。

ステートフルインスペクション

ZBFW で通信を許可する場合、単に pass（通過）させるのではなく、通常は inspect（検査）アクションを指定します。これによりルータが通信のセッション状態を記憶し、戻り通信（Reply）を自動的に許可 します。ACL のように行きと帰りの両方を書く必要がなく、設定行数が大幅に削減されます。

設定の全体像（3 つの構成要素）

ZBFW の設定は CPL（Class-map／Policy-map／Zone-pair）と呼ばれる 3 階層構造 で構成されます。コマンドを入力する前に、それぞれの役割と関係性を理解しておくことが推奨されます。

Class-map（クラスマップ）

• 役割: 「対象を識別する」（通信の分類）
• 内容: どのトラフィックをポリシー対象にするかを定義する
• 設定方法: ACL（IP アドレスで指定）、プロトコル（HTTP など）、NBAR、SGT などの条件で通信を分類・抽出する

ZBFW 専用のクラスマップは class-map type inspect で宣言します。

Policy-map（ポリシーマップ）

• 役割: 「アクションを定義する」
• 内容: Class-map で識別した通信に対してどのような処理を行うかを定義する

主なアクションは以下の 3 種類です。

Zone-pair（ゾーンペア）

• 役割: 「適用方向を決める」
• 内容: 作成した Policy-map を、具体的なゾーン間の通信に適用する
• 設定方法: Source（送信元）ゾーンと Destination（宛先）ゾーンの組み合わせを指定し、そこにポリシーを紐付ける

ゾーンペアは 通信の開始方向を表す ため、INSIDE → OUTSIDE と OUTSIDE → INSIDE は別のゾーンペアとして扱われます。

実践設定例: Inside から Outside への通信許可

実際にルータに設定を投入する手順をステップごとに解説します。

シナリオ

! 1. セキュリティゾーンの定義
configure terminal
zone security INSIDE
zone security OUTSIDE
!
! 2. インターフェイスへの割り当て
interface GigabitEthernet0/0
 zone-member security INSIDE
!
interface GigabitEthernet0/1
 zone-member security OUTSIDE

! 1. 通信対象を特定する ACL の作成
ip access-list extended ACL-INSIDE-TO-OUTSIDE
 permit ip 192.168.1.0 0.0.0.255 any
!
! 2. クラスマップの作成（ACL を紐付け）
class-map type inspect match-all CM-INSIDE-TO-OUTSIDE
 match access-group name ACL-INSIDE-TO-OUTSIDE

policy-map type inspect PM-INSIDE-TO-OUTSIDE
 ! 定義したクラスにアクションを指定
 class type inspect CM-INSIDE-TO-OUTSIDE
  inspect
 !
 ! それ以外の通信は破棄（ログも取得）
 class class-default
  drop log

zone-pair security ZP-IN-TO-OUT source INSIDE destination OUTSIDE
 service-policy type inspect PM-INSIDE-TO-OUTSIDE

Self Zone（自分自身ゾーン）の扱い

ZBFW を運用する上で 最も重要かつ見落とされやすいのが Self Zone です。Self Zone はルータ自身の制御プレーン宛ての通信や、ルータ自身が送信する通信を表す特別なゾーンで、SSH／Telnet 管理アクセス、ICMP（Ping）応答、ルーティングプロトコル、NTP、SNMP、PPPoE などの通信が該当します。

参考: Cisco – Configure Zone-Based Firewall (ZBFW) co-located with Cisco Unified Border Element
“The SELF zone includes other traffic to/from the router such as ICMP, SSH, NTP, DNS, etc.”
（Self Zone には ICMP・SSH・NTP・DNS などのルータに対する／から発生する通信が含まれます）
https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/220378-configure-zone-based-firewall-zbfw-co.html

Self Zone のデフォルト動作

Self Zone は 明示的に設定しなくても自動的に存在する ゾーンで、デフォルトでは以下のように動作します。

Self Zone を含むゾーンペアを作成しポリシーを attach した時点で初めて制限が効きます。何も設定しなければ管理通信は素通しのままですが、制限を追加する際に管理元 IP の許可ポリシーを書き忘れると、ルータへの全アクセスが遮断されるリスクがあります。

リモート管理を失わないための設計

OUTSIDE → INSIDE のゾーンペアだけを設定して運用する構成では、リモート SSH 管理は素通し状態のまま残ります。セキュリティ上は望ましくないため、Self Zone を制限する場合は以下のパターンを参考にしてください。

! 管理元 IP を許可する ACL
ip access-list extended ACL-MGMT-ALLOW
 permit tcp host 203.0.113.10 any eq 22       ! SSH 元 IP
 permit udp host 203.0.113.10 any eq 161      ! SNMP
 permit icmp host 203.0.113.10 any            ! Ping
!
! Self Zone 用クラスマップ（L4 のみ指定）
class-map type inspect match-all CM-MGMT-ALLOW
 match access-group name ACL-MGMT-ALLOW
!
! Self Zone 用ポリシーマップ
policy-map type inspect PM-OUTSIDE-TO-SELF
 class type inspect CM-MGMT-ALLOW
  inspect
 class class-default
  drop log
!
! OUTSIDE から Self Zone へのゾーンペア
zone-pair security ZP-OUT-TO-SELF source OUTSIDE destination self
 service-policy type inspect PM-OUTSIDE-TO-SELF

この設定により、OUTSIDE 側からルータ自身への通信は管理元 IP からのみ許可される ホワイトリスト型の制御になります。その他の Self Zone 関連通信（INSIDE → Self 等）は明示的なゾーンペアがないためデフォルト動作（許可）のまま残ります。

Self Zone の制約事項

Self Zone は通常のゾーンと比べて、いくつかの構造的制約があります。

参考: Cisco IOS XE 17.x – Zone-Based Policy Firewalls
“Stateful inspection support for multicast traffic is not supported between any zones, including the self zone.”
（マルチキャストトラフィックのステートフル検査は、Self Zone を含むあらゆるゾーン間でサポートされません）
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_zbf/configuration/xe-17/sec-data-zbf-xe-17-book/m_sec-zone-pol-fw-xe.html

CUBE や PVDM 等の特殊インターフェイス

Cisco Unified Border Element（CUBE）の音声処理用ハードウェア（PVDM）や、サービスエンジン（Service-Engine X/Y/Z）は Self Zone には属さない ため、ZBFW を有効化した環境では明示的にゾーン割当を行う必要があります。

interface Service-Engine0/4/0
 zone-member security INSIDE

CUBE 環境でこの割当を忘れると、音声通話のメディアパスが ZBFW でドロップされるため、設計時の確認が推奨されます。

動作確認コマンド

設定完了後、ZBFW が正しく機能しているかを確認します。

ゾーンとゾーンペアの構成確認

まず構成自体が正しく投入されているかを確認します。

! ゾーン一覧と所属インターフェイス
show zone security

! ゾーンペアと適用ポリシー
show zone-pair security

! ZBFW 設定全体（パラメータマップ含む）
show policy-firewall config

セッション情報の確認

現在確立されているセッションを表示するコマンドです。社内 PC からインターネットへ通信を行いながら実行します。

Router# show policy-map type inspect zone-pair sessions

policy exists on zp INSIDE-TO-OUTSIDE
 Zone-pair: ZP-IN-TO-OUT

  Service-policy inspect : PM-INSIDE-TO-OUTSIDE

    Class-map: CM-INSIDE-TO-OUTSIDE (match-all)
      Match: access-group name ACL-INSIDE-TO-OUTSIDE
      Inspect
        Number of Established Sessions = 1
        Established Sessions
          Session 81E48480 (192.168.1.10:54321)=>(8.8.8.8:53) icmp SIS_OPEN

Established Sessions にセッションが表示されていれば、行きの通信が検査され、戻り通信枠が確保されています。ここが 0 のまま通信が通らない場合は、ACL の設定やゾーン割当（zone-member）の誤りを確認します。

ハードウェア処理層でのドロップ確認（IOS XE）

Cisco IOS XE のルータ（ASR1K／ISR4K／Catalyst 8000 系）では、パケット処理が QFP（QuantumFlow Processor） でハードウェア化されています。従来の debug 系コマンドではドロップを追跡しきれないため、QFP の統計情報を直接確認するコマンドが用意されています。

! QFP のドロップ統計
show platform hardware qfp active statistics drop

! パケット単位のトレース（事前に conditional debug の設定が必要）
show platform packet-trace summary
show platform packet-trace packet <num>
show platform packet-trace packet <num> decode

参考: Cisco – ZBFW for IOS-XE Configuration Troubleshoot Guide
https://www.cisco.com/c/en/us/support/docs/security/ios-firewall/117721-technote-iosfirewall-00.html

show platform packet-trace packet <num> の出力では、ZBFW でドロップされたパケットについて Feature: ZBFW、Action: Drop、Reason: <理由>、Zone-pair name、Class-map name まで具体的に表示されるため、原因の特定に有効です。

ドロップパケットのログ取得（運用向け）

ZBFW でドロップされたパケットを継続的にログとして残したい場合、グローバルなパラメータマップを設定します。

parameter-map type inspect-global
 log dropped-packets

これにより、drop アクションで遮断されたパケットの情報が syslog に出力されるようになり、運用時のトラブルシュートが容易になります。

よくあるハマりポイントと運用時の注意点

ZBFW の設定や運用で踏みやすい代表的な落とし穴を整理します。

NAT NVI との非互換

ルータの NAT 設定方式には以下の 2 種類がありますが、NAT NVI（Network Virtualization Interface）と ZBFW は併用できないという既知の問題（Cisco Bug ID: CSCsh12490）があります。

NAT NVI 環境で ZBFW を使う場合は、通常の inside／outside 方式の NAT 設定への切り替えが必要です。

同一インターフェイスは 1 ゾーンにしか所属できない

zone-member security コマンドは 1 つのインターフェイスに対して 1 ゾーンしか指定できません。サブインターフェイスや VLAN 単位で別ゾーンに分けたい場合は、論理インターフェイスを分割する設計が必要です。

ゾーンペアの片方向性

ゾーンペアは送信元と宛先を指定する 片方向の概念 です。INSIDE → OUTSIDE のゾーンペアを作成しても、OUTSIDE → INSIDE の通信が自動で許可されることはありません。戻り通信は inspect アクションで自動許可されますが、これは「行きのセッションに紐付いた戻り通信」のみが対象です。両方向で通信を開始させたい場合は、両方向のゾーンペアを個別に作成します。

ゾーン割当時の通信断

zone-member security コマンドを投入した瞬間、そのインターフェイスを通る既存通信が一時的に遮断されます。リモート作業中の場合は、コンソール経由での作業、または事前に Self Zone のポリシーを設計しておくことが推奨されます。

Policy-map 内のクラス順序は変更不可

policy-map type inspect 配下のクラスは設定した順序で評価されますが、後から順序を変更することはできません。順序を変更したい場合はポリシーマップを一度削除して再作成する必要があります。設計時にクラスの優先順位を確定させておくことが重要です。

ZBFW Session Reclassification（IOS XE 17.6.1 以降）

IOS XE 17.6.1 以降では ZBFW Session Reclassification 機能により、ポリシー変更が既存セッションに反映されるようになりました。

参考: Cisco IOS XE 17.x – Zone-Based Policy Firewalls
“From Cisco IOS XE 17.6.1, you can configure ZBFW Session Reclassification.”
（Cisco IOS XE 17.6.1 から ZBFW Session Reclassification を設定できます）
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_zbf/configuration/xe-17/sec-data-zbf-xe-17-book/m_sec-zone-pol-fw-xe.html

なお、この機能は HA 構成では非対応 である点にも注意が必要です。

Cisco SD-WAN（Catalyst SD-WAN）における ZBFW

Cisco SD-WAN（Catalyst SD-WAN）環境では、ZBFW は VPN（VRF）間の通信制御 として使われ、データプレーンのフィルタリングを担います。スタンドアロン IOS XE の ZBFW とコマンド体系が異なり、show sdwan zbfw zonepair-statistics ／ show sdwan zonebfwdp sessions などの専用コマンドが用意されています。SD-WAN 環境での ZBFW 設定は SD-WAN Manager（旧 vManage）の GUI ウィザードで行うのが基本です。

対応機種とライセンス要件

ZBFW は Cisco IOS／IOS XE の幅広いプラットフォームで利用可能ですが、機種によって必要なライセンスが異なります。

対応機種

ライセンス要件

Catalyst 8000 シリーズへの移行が進む現在、DNA Essentials ライセンスがあれば ZBFW を利用できる構成が標準的 です。導入前には必ず Cisco Feature Navigator（https://cfnng.cisco.com/）で対象機器・対象 IOS バージョンの対応状況を確認することが推奨されます。

なお、Cisco ルータでは ZBFW と並行して IPsec VPN 機能も同じセキュリティライセンスで利用可能です。VTI を使った IPsec VPN の構築手順については、関連記事『Cisco VTI を使った IPsec VPN の設定例｜IKEv2 と GRE 不要構成』を参照してください。

まとめ

本記事では、Cisco IOS XE における Zone-Based Firewall（ZBFW）の仕組みと設定手順を解説しました。

• ZBFW は CBAC の後継 として、Cisco ルータでステートフルファイアウォールを実現する機能
• 設定は Class-map（識別）→ Policy-map（アクション）→ Zone-pair（適用方向） の 3 階層構造
• ゾーン間のデフォルトはすべて遮断、許可したい通信のみホワイトリスト形式で設定する
• Self Zone はルータ自身の通信を表す特殊ゾーンで、リモート管理を失わない設計が運用上の重点
• L7 検査・マルチキャスト・police アクションなど Self Zone 固有の制約を把握しておく
• IOS XE 17.6.1 以降では Session Reclassification でポリシー変更が既存セッションに反映される
• 対応機種・必要ライセンス（Catalyst 8000 系は DNA Essentials）を導入前に確認する

以上、最後までお読みいただきありがとうございました。