Configure o ZBFW usando a correspondência de padrão de ACL FQDN na série C8300

Introdução

Este documento descreve o procedimento para configurar o ZBFW com a correspondência do padrão FQDN ACL no modo autônomo na plataforma C8300.

Pré-requisitos

Requisitos

A Cisco recomenda ter conhecimento deste tópico:

• Firewall de política baseado em zona (ZBFW)
• Roteamento e encaminhamento virtual (VRF)
• Tradução de Endereço de Rede (NAT)

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

• C8300-2N2S-6T 17.12.02

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

O Zone-Based Policy Firewall (ZBFW) é um método avançado de configuração de firewall nos dispositivos Cisco IOS® e Cisco IOS XE que permite a criação de zonas de segurança dentro da rede.

O ZBFW permite que os administradores agrupem interfaces em zonas e apliquem políticas de firewall ao tráfego que se move entre essas zonas.

As ACLs FQDN (Fully Qualified Domain Name Access Control Lists), usadas com um ZBFW nos roteadores Cisco, permitem que os administradores criem regras de firewall que correspondam ao tráfego com base nos nomes de domínio, em vez de apenas endereços IP.

Este recurso é particularmente útil ao lidar com serviços hospedados em plataformas como AWS ou Azure, onde o endereço IP associado a um serviço pode mudar com frequência.

Ele simplifica o gerenciamento das políticas de controle de acesso e melhora a flexibilidade das configurações de segurança na rede.

Configurar

Diagrama de Rede

Este documento apresenta a configuração e a verificação para ZBFW com base neste diagrama. Este é um ambiente simulado usando o BlackJumboDog como um servidor DNS.

Diagrama de Rede

Configurações

Essa é a configuração para permitir a comunicação do cliente com o servidor Web.

Etapa 1. (Opcional) Configurar o VRF

O recurso VRF (Virtual Routing and Forwarding, roteamento e encaminhamento virtual) permite criar e gerenciar várias tabelas de roteamento independentes em um único roteador. Neste exemplo, criamos um VRF chamado WebVRF e executamos o roteamento para comunicações relacionadas.

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

Etapa 2. Configurar a interface

Configure informações básicas, como membro de zona, VRF, NAT e endereços IP para as interfaces interna e externa.

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

Etapa 3. (Opcional) Configurar o NAT

Configure o NAT para interfaces internas e externas. Neste exemplo, o endereço IP origem do cliente (192.168.10.1) é convertido em 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

Etapa 4. Configurar ACL FQDN

Configure a ACL FQDN para corresponder ao tráfego de destino. Neste exemplo, use o curinga '*' na correspondência de padrão do grupo de objetos FQDN para corresponder ao FQDN de destino.

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

Etapa 5. Configurar ZBFW

Configure zone, class-map, policy-map para ZBFW. Neste exemplo, usando o mapa de parâmetros, logs são gerados quando o tráfego é permitido pelo 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

Verificar

Etapa 1. Iniciar conexão HTTP do cliente

Verifique se a comunicação HTTP do cliente com o servidor WEB foi bem-sucedida.

Conexão HTTP

Etapa 2. Confirmar cache de IP

Execute show platform hardware qfp active feature dns-snoop-agent datapath ip-cache all o comando para confirmar se o cache IP para o FQDN de destino é gerado em 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

Etapa 3. Confirmar log ZBFW

Confirme se o endereço IP (192.168.20.1) corresponde ao FQDN (.*\.test\.com) e verifique se a comunicação HTTP na etapa 1 é permitida pelo 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

Etapa 4. Confirmar captura de pacote

Confirme se a resolução DNS para o FQDN de destino e a conexão HTTP entre o Cliente e o servidor WEB foram bem-sucedidas.

Captura de pacotes no interior:

Pacotes DNS no interior

Pacotes HTTP no interior

Captura de pacote no lado (192.168.10.1 é NAT para 192.168.19.100) :

Pacotes DNS no Exterior

Pacotes HTTP no Exterior

Troubleshooting

Para solucionar problemas de comunicação relacionados ao ZBFW usando a correspondência de padrão FQDN ACL, você pode coletar os logs durante o problema e fornecê-los ao Cisco TAC. Observe que os registros para a solução de problemas dependem da natureza do problema.

Exemplo de logs a serem coletados:

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

Perguntas mais freqüentes

P: Como o valor de tempo limite do cache IP é determinado no roteador ?

R: O valor de tempo limite do cache IP é determinado pelo valor TTL (Time-To-Live, tempo de vida restante) do pacote DNS retornado do servidor DNS. Neste exemplo, ele é de 120 segundos. Quando o cache IP atinge o tempo limite, ele é automaticamente removido do roteador. Este é o detalhe da captura de pacotes.

Detalhes do pacote de resolução DNS

P: É aceitável quando o servidor DNS retorna o registro CNAME em vez do registro A?

R: Sim, não é um problema. A resolução DNS e a comunicação HTTP são prosseguidas sem problemas quando o registro CNAME é retornado pelo servidor DNS. Este é o detalhe da captura de pacotes.

Pacotes DNS no interior

Detalhes do pacote de resolução DNS

Pacotes HTTP no interior

P: Qual é o comando para transferir capturas de pacotes coletadas em um roteador C8300 para um servidor FTP?

R: Use os comandos monitor capture <capture name> export bootflash:<capture name>.pcap e copy bootflash:<capture name>.pcap ftp://<user>:<password>@<FTP IP Address> para transferir capturas de pacotes para um servidor FTP. Este é um exemplo para transferir CAPIN para um servidor FTP.

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

Referência

Entender o design do firewall de política baseado em zona