Configurazione di ZBFW con la corrispondenza del modello ACL FQDN nella serie C8300

Introduzione

Questo documento descrive la procedura per configurare ZBFW con un modello ACL FQDN corrispondente in modalità autonoma sulla piattaforma C830.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza di questo argomento:

• Zone-Based Policy Firewall (ZBFW)
• VRF (Virtual Routing and Forwarding)
• NAT (Network Address Translation)

Componenti usati

Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:

• C8300-2N2S-6T 17.12.02

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

Zone-Based Policy Firewall (ZBFW) è un metodo avanzato di configurazione del firewall sui dispositivi Cisco IOS® e Cisco IOS XE che consente di creare aree di sicurezza all'interno della rete.

ZBFW consente agli amministratori di raggruppare le interfacce in zone e di applicare policy firewall al traffico che si sposta tra le zone.

Gli ACL FQDN (Fully Qualified Domain Name Access Control Lists), utilizzati con un ZBFW nei router Cisco, consentono agli amministratori di creare regole del firewall che corrispondono al traffico in base ai nomi di dominio anziché ai soli indirizzi IP.

Questa funzionalità è particolarmente utile quando si tratta di servizi ospitati in piattaforme quali AWS o Azure, in cui l'indirizzo IP associato a un servizio può cambiare frequentemente.

Semplifica la gestione delle policy di controllo dell'accesso e migliora la flessibilità delle configurazioni di sicurezza all'interno della rete.

Configurazione

Esempio di rete

Questo documento introduce la configurazione e la verifica di ZBFW in base a questo diagramma. Si tratta di un ambiente simulato che utilizza BlackJumboDog come server DNS.

Esempio di rete

Configurazioni

Questa è la configurazione per consentire la comunicazione dal client al server Web.

Passaggio 1. (Facoltativo) Configurare VRF

La funzione VRF (Virtual Routing and Forwarding) consente di creare e gestire più tabelle di routing indipendenti all'interno di un singolo router. In questo esempio viene creato un VRF denominato WebVRF e viene eseguito il routing delle comunicazioni correlate.

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

Passaggio 2. Configura interfaccia

Configurare le informazioni di base, ad esempio i membri della zona, il VRF, il NAT e gli indirizzi IP, per le interfacce interne ed esterne.

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

Passaggio 3. (Facoltativo) Configurare NAT

Configurare NAT per le interfacce interne ed esterne. Nell'esempio, l'indirizzo IP di origine del client (192.168.10.1) viene convertito in 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

Passaggio 4. Configura ACL FQDN

Configurare l'ACL FQDN in modo che corrisponda al traffico di destinazione. In questo esempio, utilizzare il carattere jolly '*' nel pattern corrispondente del gruppo di oggetti FQDN in modo che corrisponda all'FQDN di destinazione.

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

Passaggio 5. Configurazione ZBFW

Configurare la zona, la mappa delle classi e la mappa dei criteri per ZBFW. In questo esempio, utilizzando una mappa dei parametri, vengono generati log quando il traffico è autorizzato da 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

Verifica

Passaggio 1. Avvia connessione HTTP dal client

Verificare che la comunicazione HTTP tra il client e il server WEB abbia esito positivo.

Connessione HTTP

Passaggio 2. Conferma cache IP

Eseguire show platform hardware qfp active feature dns-snoop-agent datapath ip-cache all il comando per verificare che la cache IP per l'FQDN di destinazione sia generata in C8300-2N2S-6T.

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

Passaggio 3. Conferma registro ZBFW

Verificare che l'indirizzo IP (192.168.20.1) corrisponda al nome di dominio completo (.*\.test\.com) e che la comunicazione HTTP al passaggio 1 sia consentita da 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

Passaggio 4. Conferma acquisizione pacchetto

Confermare che la risoluzione DNS per l'FQDN di destinazione e la connessione HTTP tra il client e il server WEB abbiano esito positivo.

Acquisizione pacchetto all'interno:

Pacchetti DNS all'interno

Pacchetti HTTP in interno

Packet Capture in Onside (192.168.10.1 è NAT to 192.168.19.100):

Pacchetti DNS esterni

Pacchetti HTTP esterni

Risoluzione dei problemi

Per risolvere i problemi di comunicazione relativi a ZBFW con la corrispondenza del modello ACL FQDN, è possibile raccogliere i log durante il problema e fornirli a Cisco TAC. I registri per la risoluzione dei problemi dipendono dalla natura del problema.

Esempio di registri da raccogliere:

!!!! before reproduction
!! Confirm the IP cache
show platform hardware qfp active feature dns-snoop-agent datapath ip-cache all

!! Enable 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

!! Enable debug-level system logs and ZBFW debug logs
debug platform packet-trace drop
debug acl cca event
debug acl cca error
debug ip domain detail
!! Start to debug
debug platform condition start

!! Enable packet capture on the target interface (both sides) and start the capture
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

!! (Optional) Clear the DNS cache on the client
ipconfig/flushdns
ipconfig /displaydns

!! Run the show command before reproduction
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

!!!! Reproduce the issue - start

!! During the reproductionof the issue, run show commands at every 10 seconds
!! Skip show ip dns-snoop all command if it is not supported on the specific router
show ip dns-snoop all
show platform hardware qfp active feature dns-snoop-agent datapath ip-cache all

!!!! After reproduction
!! Stop the debugging logs and packet capture
debug platform condition stop
monitor capture CAPIN stop
monitor capture CAPOUT stop

!! Run the show commands
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

Domande frequenti

D: Come viene determinato il valore di timeout della cache IP sul router?

R. Il valore di timeout della cache IP è determinato dal valore TTL (Time-To-Live) del pacchetto DNS restituito dal server DNS. Nell'esempio, questo valore è 120 secondi. Quando la cache IP scade, viene rimossa automaticamente dal router. Questo è il dettaglio dell'acquisizione dei pacchetti.

Dettagli pacchetto risoluzione DNS

D: È accettabile quando il server DNS restituisce un record CNAME anziché A?

A: Sì, non è un problema. La risoluzione DNS e la comunicazione HTTP vengono eseguite senza problemi quando il record CNAME viene restituito dal server DNS. Questo è il dettaglio dell'acquisizione dei pacchetti.

Pacchetti DNS all'interno

Dettagli pacchetto risoluzione DNS

Pacchetti HTTP in interno

D: Qual è il comando per trasferire le acquisizioni dei pacchetti raccolte su un router C8300 a un server FTP?

R: Utilizzare i comandi monitor capture <capture name> export bootflash:<capture name>.pcap ecopy bootflash:<capture name>.pcap ftp://<user>:<password>@<FTP IP Address> per trasferire le acquisizioni dei pacchetti su un server FTP. Questo è un esempio di trasferimento di CAPIN su un server FTP.

monitor capture CAPIN export bootflash:CAPIN.pcap
copy bootflash:CAPIN.pcap ftp://<user>:<password>@<FTP IP Address>

Riferimento

Informazioni sulla progettazione del firewall per i criteri basati sulle aree