FQDN ACL のパターンマッチを用いた ZBFW の設定例と動作確認

jianzh3 · ‎2024-03-08

はじめに
構成
設定例
1. VRF 設定（オプション）
2. Interface 設定
3. NAT 設定（オプション）
4. FQDN ACL 設定
5. ZBFW設定
動作確認例
トラブルシューティング
よくある質問
Q: ルーター側に生成された ip-cache のタイムアウト値はどのように決まりますか
Q: DNSサーバからレスポンスしたDNSレコードは Aレコードではなく、CNAMEの場合でも問題ないですか
Q: ルーター上に収集されたパケットキャプチャをFTPに転送するコマンドは何ですか
参考情報

はじめに

ZBFW (Zone-Based Policy Firewall) は、CiscoのIOSやIOS-XE上で動作するファイアウォールの機能の一つです。FQDN ACLをZBFWで利用する場合は、ネットワークにアクセスしようとするトラフィックをFQDNベースで制御することができます。これは、IPアドレスではなくドメイン名を使用してアクセス制御ポリシーを設定するということです。FQDN ACLを使うことで、動的に変化するIPアドレスを持つホスト（例えば、クラウドサービス）へのアクセス管理が容易になります。

このドキュメントでは、C8300 の Autonomous モードで NATと「Virtual Routing and Forwarding」(VRF)により処理されるトラフィックに対し、FQDN ACL のパターンマッチを用いた ZBFW による制御に関する設定例と動作確認例について、紹介します。
本ドキュメントでは、C8300 (2N2S-6T) 17.12.02 のソフトウェアバージョンを利用して確認しております。

構成

本ドキュメントは、以下の構成で、設定・動作確認例を紹介します。
（DNSサーバーについて、他社製品の BlackJumboDog を利用し、シミュレーターします。）

設定例

C8300 (2N2S-6T) 側で最小限の設定を実施します。

1. VRF 設定（オプション）

VRF (Virtual Routing and Forwarding) 機能は、単一のルーター内で複数の独立したルーティングテーブルを作成して管理することができる機能です。本例は WebVRF という VRF を作成し、関連通信のルーティングを行います。

vrf definition WebVRF
rd 65010:10
!
address-family ipv4
route-target export 65010:10
route-target import 65010:10
exit-address-family
!
address-family ipv6
route-target export 65010:10
route-target import 65010:10
exit-address-family

ip route vrf WebVRF 8.8.8.8 255.255.255.255 GigabitEthernet0/0/3 192.168.99.10
ip route vrf WebVRF 192.168.10.0 255.255.255.0 Port-channel1.2001  192.168.1.253
ip route vrf WebVRF 192.168.20.0 255.255.255.0 GigabitEthernet0/0/3 192.168.99.10

2. Interface 設定

NAT の Inside と Outside Interface に対し、zone-member、VRF、IPなどの基本情報を設定します。

interface GigabitEthernet0/0/1
 no ip address
 negotiation auto
 lacp rate fast
 channel-group 1 mode active

interface GigabitEthernet0/0/2
 no ip address
 negotiation auto
 lacp rate fast
 channel-group 1 mode active

interface Port-channel1
 no ip address
 no negotiation auto

interface Port-channel1.2001
 encapsulation dot1Q 2001
 vrf forwarding WebVRF
 ip address 192.168.1.1 255.255.255.0
 ip broadcast-address 192.168.1.255
 no ip redirects
 no ip proxy-arp
 ip nat inside
 zone-member security zone_client


interface GigabitEthernet0/0/3
 vrf forwarding WebVRF
 ip address 192.168.99.1 255.255.255.0
 ip nat outside
 zone-member security zone_internet
 speed 1000
 no negotiation auto

3. NAT 設定（オプション）

本例は Client からの送信元IP（192.168.10.1）を 192.168.99.100 に変換されます。

ip access-list standard nat_source
 10 permit 192.168.10.0 0.0.0.255

ip nat pool natpool 192.168.99.100  192.168.99.100 prefix-length 24
ip nat inside source list nat_source pool natpool vrf WebVRF overload

4. FQDN ACL 設定

FQDN オブジェクトグループのパターンマッチで「*」を利用し、宛先のFQDN（abc.test.com）をマッチするように設定します。

object-group network src_net 
 192.168.10.0 255.255.255.0

object-group fqdn dst_test_fqdn
 pattern .*\.test\.com

object-group network dst_dns 
 host 8.8.8.8

ip access-list extended Client-WebServer
 1 permit ip object-group src_net object-group dst_dns
 5 permit ip object-group src_net fqdn-group dst_test_fqdn

5. ZBFW設定

parameter-map の定義により、トラフィックが ZBFW により許可された場合でも ZBFW ログを出力させます。

zone security zone_client
zone security zone_internet

parameter-map type inspect inspect_log
 audit-trail on

class-map type inspect match-any Client-WebServer-Class
 match access-group name Client-WebServer

policy-map type inspect Client-WebServer-Policy
 class type inspect Client-WebServer-Class
  inspect inspect_log
 class class-default
  drop log

zone-pair security Client-WebServer-Pair source zone_client destination zone_internet
service-policy type inspect Client-WebServer-Policy

動作確認例

1. Client から、WEBサーバー「abc.test.com」にアクセスし、正常にHTTP通信ができたことを確認します。

2. C8300 (2N2S-6T) の CLI で対象 FQDN の ip-cache が生成されたことを確認します。

コマンド：show platform hardware qfp active feature dns-snoop-agent datapath ip-cache all
実行例：

02A7382#show platform hardware qfp active feature dns-snoop-agent datapath ip-cache all
IP Address                         Client(s)  Expire    RegexId    Dirty  VRF ID      Match
------------------------------------------------------------------------------------------------------
192.168.20.1                            0x1  117     0xdbccd400   0x00   0x0         .*\.test\.com

3. C8300 (2N2S-6T) 側のログで、IPアドレス（192.168.20.1）とFQDN（.*\.test\.com）のマッチングを確認でき、「1.」のHTTP通信がZBFWにより、許可されたことを確認します。

*Mar  7 11:08:23.018: %IOSXE-6-PLATFORM: R0/0: cpp_cp: QFP:0.0 Thread:003 TS:00000551336606461468 %FW-6-SESS_AUDIT_TRAIL_START: (target:class)-(Client-WebServer-Pair:Client-WebServer-Class):Start http session: initiator (192.168.10.1:51468) -- responder (192.168.20.1(.*\.test\.com):80) from Port-channel1.2001

*Mar  7 11:08:24.566: %IOSXE-6-PLATFORM: R0/0: cpp_cp: QFP:0.0 Thread:002 TS:00000551338150591101 %FW-6-SESS_AUDIT_TRAIL: (target:class)-(Client-WebServer-Pair:Client-WebServer-Class):Stop http session: initiator (192.168.10.1:51468) sent 943 bytes -- responder (192.168.20.1:80) sent 101288 bytes, from Port-channel1.2001

4. パケットキャプチャには、abc.test.com に対する DNS 解析が成功した後、Client と WEB サーバー間のHTTP通信が正常に行われたことを確認できます。

Inside側のパケットキャプチャ：

DNS解析：

HTTP通信：

Outside側のパケットキャプチャ（送信元の192.168.10.1が192.168.99.100に変更された）：

DNS解析：

HTTP通信：

トラブルシューティング

FQDN ACL のパターンマッチを用いた ZBFW に関する通信問題をトラブルシューティングのため、Cisco TACより事象発生時の関連情報の取得をお願いさせて頂く事があります。
取得依頼がありました場合、以下コマンドなどの実行結果のログ、並びに、生成されたパケットキャプチャ（.pcapファイル）の収集・提供をお願いいたします。なお、取得するコマンドはトラブル内容により変わることがあります。

取得ログ例：

!!!! 事前準備

!! ルーター上で対象FQDNのip-cacheが存在しないことを確認します。
show platform hardware qfp active feature dns-snoop-agent datapath ip-cache all

!! packet-traceを有効します。
debug platform packet-trace packet 8192 fia-trace
debug platform packet-trace copy packet both
debug platform condition ipv4 access-list Client-WebServer both
debug platform condition feature fw dataplane submode all level verbose

!! debugレベルのシステムログ、及び、zbfw debugログを有効し、debugを開始します。
debug platform packet-trace drop
debug acl cca event
debug acl cca error
debug ip domain detail
debug platform condition start

!! 対象Interface（両側）のパケットキャプチャを同時に有効し、開始します。
monitor capture CAPIN interface Port-channel1.2001 both
monitor capture CAPIN match ipv4 any any
monitor capture CAPIN buffer size 32
monitor capture CAPIN start

monitor capture CAPOUT interface g0/0/3 both
monitor capture CAPOUT match ipv4 any any
monitor capture CAPOUT buffer size 32
monitor capture CAPOUT start

!! （オプション）対象Windows端末にてDNSキャッシュをクリアします。
ipconfig/flushdns
ipconfig /displaydns

!! show commandを実行します。
show platform hardware qfp active feature firewall drop all
show policy-map type inspect zone-pair Client-WebServer-Pair sessions
show platform packet-trace statistics
show platform packet-trace summary
show logging process cpp_cp internal start last boot
show platform hardware qfp active feature dns-snoop-agent client hw-pattern-list
show platform hardware qfp active feature dns-snoop-agent client info
show platform hardware qfp active feature dns-snoop-agent datapath stats
show ip dns-snoop all
show platform hardware qfp active feature dns-snoop-agent datapath ip-cache all
show platform software access-list F0 summary

!!!! 事象再現
!! 事象を再現し、時刻を記録します。

!! 事象再現中、大体10秒ごとに、下記のコマンドを実施します。
!! ルーターの種類により、show ip dns-snoop allがサポートされない場合、show ip dns-snoop all をスキップしてください。
show ip dns-snoop all
show platform hardware qfp active feature dns-snoop-agent datapath ip-cache all

!! 事象再現完了（時刻を記録する)

!! debugログやパケットキャプチャを停止します。
debug platform condition stop

monitor capture CAPIN stop
monitor capture CAPOUT stop

!! 再度、show commandを実行します。
show platform hardware qfp active feature firewall drop all
show policy-map type inspect zone-pair Client-WebServer-Pair sessions
show platform packet-trace statistics
show platform packet-trace summary
show logging process cpp_cp internal start last boot
show platform hardware qfp active feature dns-snoop-agent client hw-pattern-list
show platform hardware qfp active feature dns-snoop-agent client info
show platform hardware qfp active feature dns-snoop-agent datapath stats
show ip dns-snoop all
show platform hardware qfp active feature dns-snoop-agent datapath ip-cache all
show platform software access-list F0 summary

show platform packet-trace packet all decode
show running-config

よくある質問

Q: ルーター側に生成された ip-cache のタイムアウト値はどのように決まりますか

A: ip-cache のタイムアウト値はDNSサーバから返したDNSパケットのTTL値となります。本例の場合、120秒となります。ip-cache がタイムアウトになると、自動的にルーター上から削除されます。以下は、「動作確認例」でDNSサーバーから返したDNSレコードのパケットキャプチャの詳細です。

Q: DNSサーバからレスポンスしたDNSレコードは Aレコードではなく、CNAMEの場合でも問題ないですか

A: はい、問題ありません。以下は、DNSサーバからCNAMEの解析結果を返した際のパケットキャプチャであり、DNS解析やHTTP通信が問題なく行います。

DNS解析：

DNSレスポンスの詳細：

HTTP通信：

Q: ルーター上に収集されたパケットキャプチャをFTPに転送するコマンドは何ですか

A: 上記、「取得ログ例」で設定した「CAPIN」のキャプチャファイルについて、以下のコマンドによりFTPサーバーに転送できます。
monitor capture CAPIN export bootflash:CAPIN.pcap
copy bootflash:CAPIN.pcap ftp://<user>:<password>@<FTP IP Address>

参考情報

IOS-XE : EPC(Embedded Packet Capture)を使用したパケットキャプチャ方法
 Cisco Secure Firewall (FTD) - how to
Firepower System and FTDトラブルシューティング
 ファイアウォールトラブルシューティング