CCST: Defesa de Redes com Cisco ZBF - Segmentação LAN, DMZ e WAN
Guia comentado de política de tráfego, zone-pairs direcionais e validação por evidência
Antes de partir para as respostas, vale entender o que este conjunto de questões realmente está testando. Ele não mede se você decorou comandos da Cisco; ele mede se você consegue pensar como alguém que projeta e opera um firewall de verdade em um ambiente segmentado, com política clara, critérios de sucesso e capacidade de explicar o porquê.
O primeiro desafio é mental, não técnico: transformar o cenário da TechSolutions, com rede administrativa, rede financeira, webserver público e internet, em uma arquitetura defensável. Isso exige separar o fluxo necessário do fluxo perigoso e formalizar essa diferença em política. Se você tentar sair configurando sem método, vai se perder; o caminho certo é matriz de fluxos, zonas, zone-pairs, políticas, testes e evidências.
O segundo desafio é dominar o modelo do ZBF. Ele não é uma ACL com nome bonito. O controle deixa de ser uma lista aplicada em interface e passa a ser regra entre zonas, em direções específicas. Se você não internalizar que zone-pair é direcional e que o padrão é negar, a tendência é gerar conectividade quebrada ou buraco de segurança.
O terceiro desafio é precisão com evidência. Você precisa escrever ACLs estendidas corretas, decidir quando inspecionar e quando só passar ou negar, e provar que a política funciona com testes positivos e negativos. Em defesa de redes, “funcionou aqui” não basta; evidência é mostrar qual fluxo, em qual direção, por qual regra e com qual resultado observável em contador, log ou saída.
O quarto desafio é governança. As questões não querem apenas que você faça funcionar; querem que você justifique tecnicamente por que DMZ existe, por que deny-by-default é boa prática e por que ZBF representa melhoria estratégica. Essa passagem do operador reativo para o profissional que projeta, prova e sustenta a postura de segurança é o núcleo do módulo.
- Modelagem de arquitetura defensiva: separar LAN, DMZ e WAN para reduzir blast radius e evitar exposição acidental.
- Tradução de requisito em política: converter frases do enunciado em regras explícitas, mínimas e verificáveis.
- Alfabetização operacional em ZBF: dominar zonas, interfaces, zone-pairs, class-maps e policy-maps.
- Precisão de controle: escrever ACLs corretas e usá-las como critério de correspondência quando fizer sentido.
- Validação orientada a evidência: pensar em hipótese, teste e confirmação em vez de chute operacional.
- Comunicação técnica defensável: explicar trade-offs, justificar escolhas e sustentar a decisão para outra pessoa revisar.
Em resumo, quem resolve bem este roteiro demonstra que já começou a sair do “só configura” para o “projeta, prova e sustenta”. A ferramenta pode mudar; esse raciocínio fica.
O que a questão pede
Comparar formas de implementar firewall e justificar o modelo mais adequado para a TechSolutions.
Conceito cobrado
ZBF no roteador Cisco organiza política por relações entre zonas e reduz erro operacional.
Estrutura dos dados
Entrada: requisitos de negócio e fluxos esperados.
Saída: desenho de zonas com política justificável.
Como pensar
Parta do risco: quem precisa falar com quem, em qual direção e por qual serviço. Depois escolha o mecanismo que melhor expressa essas relações com menor privilégio.
Como validar
Se o desenho final explicar claramente WAN, DMZ, ADMIN e FIN com regras direcionais, a escolha está tecnicamente sustentada.
Tabela de Evidência
- Mapa de zonas definido com fronteiras claras.
- Fluxos permitidos e bloqueados documentados por direção.
- Justificativa de por que ZBF é superior à ACL isolada no cenário.
Variáveis-chave
zonasfluxoszone-pairsdeny-by-default
O que focar no Screenshot
No print, priorize o quadro com zonas e os fluxos permitidos por direção. Esse recorte já mostra se a arquitetura foi pensada com governança.
Como explicar
Explique em duas camadas: primeiro a necessidade de segmentação (risco), depois o mecanismo operacional (ZBF) que implementa essa segmentação com inspeção stateful.
Problema & Solução
Problema: Escolher tecnologia por hábito e não por requisito de fluxo. Solução: Começar pela matriz de tráfego e só então mapear zonas, zone-pairs e políticas.
# Matriz mínima de referência (conceitual)
WAN -> DMZ : HTTP (permitir)
WAN -> LAN : qualquer (bloquear)
ADMIN-> WAN : HTTP/HTTPS (permitir)
FIN -> WAN : HTTP/HTTPS (permitir)
ADMIN<->FIN : bloquear por padrãoO que a questão pede
Descrever como o firewall barra iniciação indevida da internet para redes internas.
Conceito cobrado
DMZ recebe o serviço público; LAN não deve aceitar sessão iniciada de fora.
Estrutura dos dados
Entrada: fluxo externo para web público.
Saída: permissão restrita ao webserver e bloqueio para LAN.
Como pensar
Separe o que é publicado (WAN->DMZ) do que é interno (WAN->LAN). O retorno de sessão deve ser permitido por estado, não por regra ampla.
Como validar
Teste positivo: site abre externamente. Teste negativo: tentativa externa para ADMIN/FIN falha.
Tabela de Evidência
- Regra explícita WAN->DMZ para HTTP/HTTPS do servidor público.
- Ausência de regra permissiva WAN->LAN.
- Logs e contadores mostrando bloqueio de tentativas indevidas.
Variáveis-chave
WAN->DMZWAN->LANstateful return
O que focar no Screenshot
Mostre o teste externo bem-sucedido para o webserver e um teste falho para IP da LAN.
Como explicar
Defenda que o perímetro existe para publicar serviço específico, não para abrir rede interna.
Problema & Solução
Problema: Liberar any-any para "fazer funcionar rápido". Solução: Permissão mínima por serviço e destino explícito na DMZ.
zone-pair security ZP_WAN_DMZ source WAN destination DMZ
service-policy type inspect PM_WAN_DMZ_HTTP
! Não criar permissão WAN->ADMIN nem WAN->FINO que a questão pede
Apontar decisões de design para equilibrar segurança e operação.
Conceito cobrado
Boa política nasce de matriz de fluxos, não de comandos isolados.
Estrutura dos dados
Entrada: topologia com LAN administrativa, LAN financeira, DMZ e internet.
Saída: desenho segmentado com critérios de inspeção e logs.
Como pensar
Defina primeiro fluxos obrigatórios, depois impacto de inspeção/log. Posicione o controle no perímetro e entre segmentos internos críticos.
Como validar
A solução deve mostrar quais fluxos passam, quais caem e como isso é comprovado com teste e contador.
Tabela de Evidência
- Matriz de fluxos documentada antes da configuração.
- Critério de inspeção apenas para tráfego relevante.
- Plano de teste positivo/negativo por direção.
Variáveis-chave
matrizlatêncialoggingzone-to-self
O que focar no Screenshot
Mostre tabela de fluxos e o resultado de ao menos dois testes (um permitido e um bloqueado).
Como explicar
Mostre que performance é consequência de política bem delimitada, não de abertura ampla.
Problema & Solução
Problema: Configurar sem priorizar fluxo e sem plano de teste. Solução: Executar ciclo: matriz -> política -> teste -> ajuste.
# Exemplo de matriz mínima
ADMIN -> WAN : tcp/80,443
FIN -> WAN : tcp/80,443
WAN -> DMZ : tcp/80 (web)
ADMIN -> FIN : drop
FIN -> ADMIN : dropO que a questão pede
Comparar limitações de ACL tradicional frente ao modelo por zonas.
Conceito cobrado
ACL = filtro pontual; ZBF = política por relação entre domínios + direção + estado, com inspeção stateful.
Estrutura dos dados
Entrada: política com múltiplos segmentos.
Saída: comparação de auditabilidade e risco operacional.
Como pensar
Pergunte onde a regra vive e como comprovar o efeito. Em ZBF, a leitura por zone-pair reduz ambiguidade.
Como validar
Se você consegue explicar uma política por direção sem percorrer ACL espalhada, o desenho está mais governável.
Tabela de Evidência
- Policy associada a zone-pair específico.
- Retorno de sessão tratado por inspeção stateful.
- Menor dependência de exceções em interfaces soltas.
Variáveis-chave
ACLclass-mappolicy-mapzone-pair
O que focar no Screenshot
Mostre blocos de zone-pair e service-policy em vez de listas extensas distribuídas por interface.
Como explicar
Explique que governança melhora quando a política é lida por relação de negócio.
Problema & Solução
Problema: Acúmulo de ACL sem contexto de direção e sem visão global. Solução: Agrupar política por zonas e manter deny-by-default como base.
class-map type inspect match-any CM_WEB
match protocol http
match protocol https
policy-map type inspect PM_ADMIN_WAN
class type inspect CM_WEB
inspect
class class-default
drop logO que a questão pede
Mostrar como o modelo por zonas melhora o controle de tráfego.
Conceito cobrado
Relações explícitas por direção evitam permissões implícitas perigosas.
Estrutura dos dados
Entrada: fluxos de publicação e navegação.
Saída: políticas por par de zonas com mínimo privilégio.
Como pensar
Cada relação precisa de justificativa operacional. O que não está na matriz deve cair em bloqueio.
Como validar
Os zone-pairs existentes devem corresponder exatamente aos fluxos necessários.
Tabela de Evidência
- Zone-pairs somente para fluxos autorizados.
- CHECK de ausência de tráfego lateral indevido.
- Regra de bloqueio padrão ativa.
Variáveis-chave
ADMINFINDMZWAN
O que focar no Screenshot
Priorize a lista de zone-pairs ativos e o resultado de comunicação entre zonas permitidas e proibidas.
Como explicar
Mostre que segmentar é limitar blast radius e facilitar auditoria.
Problema & Solução
Problema: Colocar redes de confiança distinta na mesma zona. Solução: Separar por contexto de risco e manter regras estritas entre elas.
zone security WAN
zone security DMZ
zone security ADMIN
zone security FINO que a questão pede
Explicar papel de zonas, zone-pairs, class-maps e policy-maps.
Conceito cobrado
Sem zone-pair e service-policy na direção correta, tráfego interzona não passa.
Estrutura dos dados
Entrada: fluxo entre zonas.
Saída: política aplicada no local correto com comportamento previsível.
Como pensar
Associe cada etapa a uma pergunta: quem fala com quem, o que casa, e qual ação tomar.
Como validar
O crescimento de contadores por classe durante o teste confirma que a classificação está correta.
Tabela de Evidência
- Class-map casa o tráfego esperado.
- Policy-map define inspect/pass/drop com class-default restritiva.
- Service-policy aplicada no zone-pair correto.
Variáveis-chave
class-mappolicy-mapservice-policyclass-default
O que focar no Screenshot
Mostre os contadores da política após gerar tráfego permitido e bloqueado.
Como explicar
Deixe claro que localização da policy importa tanto quanto o conteúdo da regra.
Problema & Solução
Problema: Aplicar a política na direção invertida. Solução: Revisar sempre origem->destino antes de anexar service-policy.
zone-pair security ZP_ADMIN_WAN source ADMIN destination WAN
service-policy type inspect PM_ADMIN_WANO que a questão pede
Construir ACL estendida final sem placeholders.
Conceito cobrado
Regra mínima explícita + deny final com log para rastreabilidade.
Estrutura dos dados
Entrada: rede LAN 192.168.10.0/24.
Saída: ACL estendida com duas permissões e bloqueio final.
Como pensar
Defina origem, destino e porta exata. Não deixe comportamento final implícito.
Como validar
HTTP/HTTPS devem funcionar; SSH/Telnet/Ping para internet devem falhar conforme política.
Tabela de Evidência
- Matches nas linhas 80 e 443 da ACL.
- Tentativas fora do escopo caindo no deny log.
- Comportamento consistente em múltiplos testes.
Variáveis-chave
origemportadeny log
O que focar no Screenshot
Registre contadores da ACL após testes positivos e negativos.
Como explicar
Explique por que permitir pouco simplifica operação e reduz risco.
Problema & Solução
Problema: Esquecer deny final explícito ou usar máscara incorreta. Solução: Aplicar wildcard correta e negar o restante com log.
Nota de maturidade
Para o gabarito estrito, liberar apenas HTTP/HTTPS atende ao enunciado. Em navegação real por nome, normalmente também existe consulta DNS, então vale registrar essa nuance sem mudar a resposta principal. Regra prática de wildcard: uma rede /24 como 192.168.10.0/24 vira 0.0.0.255 na ACL Cisco.
ip access-list extended ACL_LAN_WEB_ONLY
permit tcp 192.168.10.0 0.0.0.255 any eq 80
permit tcp 192.168.10.0 0.0.0.255 any eq 443
deny ip 192.168.10.0 0.0.0.255 any logO que a questão pede
Responder o que acontece entre LAN e WAN quando há zonas sem zone-pair.
Conceito cobrado
Criar zona não equivale a liberar tráfego interzona.
Estrutura dos dados
Entrada: interfaces associadas a zonas sem pares configurados.
Saída: tráfego interzona bloqueado por padrão.
Como pensar
Verifique se existe par de origem->destino e service-policy ativa. Sem isso, a expectativa correta é falha de conectividade.
Como validar
Teste de saída da LAN para WAN falha até a criação do zone-pair correspondente.
Tabela de Evidência
- Ausência de zone-pair para o fluxo testado.
- Falha reproduzível no teste de conectividade.
- Sucesso após criação do par e policy.
Variáveis-chave
zonezone-pairdireção
O que focar no Screenshot
Mostre o before/after com e sem zone-pair para o mesmo fluxo.
Como explicar
Diga explicitamente: política em ZBF é opt-in por direção.
Problema & Solução
Problema: Assumir que associar interface à zona já libera tráfego. Solução: Sempre criar zone-pair com política para cada fluxo permitido.
# Sem zone-pair ADMIN->WAN
# Resultado esperado: tráfego ADMIN para WAN bloqueado
# Após criar zone-pair + policy
# Resultado esperado: fluxo permitido passaO que a questão pede
Definir regras WAN->DMZ para HTTP e bloquear WAN->LAN.
Conceito cobrado
DMZ é zona de publicação controlada; LAN permanece não publicável.
Estrutura dos dados
Entrada: serviço web na DMZ.
Saída: acesso externo ao site e bloqueio para redes internas.
Como pensar
Permita o mínimo necessário para o destino correto e trate retorno por estado.
Como validar
Acesso externo ao webserver funciona; varredura para ADMIN/FIN não encontra serviço permitido.
Tabela de Evidência
- Zone-pair WAN->DMZ com classe HTTP.
- Sem política permissiva WAN->ADMIN/FIN.
- Teste real confirmando diferença de comportamento.
Variáveis-chave
DMZ hostHTTPWAN->LAN drop
O que focar no Screenshot
Use um teste externo para o IP da DMZ e outro para IP de LAN no mesmo relatório.
Como explicar
Aponte que publicar serviço não é publicar rede inteira.
Problema & Solução
Problema: Liberar DMZ ampla e criar pivot para a LAN. Solução: Restringir por serviço e destino e bloquear lateralização.
class-map type inspect match-any CM_HTTP_DMZ
match protocol http
policy-map type inspect PM_WAN_DMZ
class type inspect CM_HTTP_DMZ
inspect
class class-default
drop logO que a questão pede
Impedir tráfego administrativo direto para rede financeira.
Conceito cobrado
Segmentação interna vale tanto quanto perímetro para conter impacto.
Estrutura dos dados
Entrada: zonas ADMIN e FIN distintas.
Saída: bloqueio explícito de tráfego entre elas, salvo exceções justificadas.
Como pensar
Trate ADMIN->FIN e FIN->ADMIN separadamente; cada direção precisa de decisão.
Como validar
Tentativas de conexão entre segmentos devem falhar segundo a política definida.
Tabela de Evidência
- Zone-pairs internos com ação de drop.
- Teste de porta/serviço entre segmentos falhando.
- Ausência de exceções não documentadas.
Variáveis-chave
ADMIN->FINFIN->ADMINlateral movement
O que focar no Screenshot
Capture tentativa de acesso de ADMIN para FIN e resultado bloqueado.
Como explicar
Justifique em termos de containment e princípio do menor privilégio.
Problema & Solução
Problema: Confiar demais na rede interna e manter segmentos abertos. Solução: Bloquear por padrão e liberar apenas exceções auditáveis.
policy-map type inspect PM_ADMIN_FIN
class class-default
drop log
zone-pair security ZP_ADMIN_FIN source ADMIN destination FIN
service-policy type inspect PM_ADMIN_FINO que a questão pede
Explicar efeitos de associar interface a zona indevida.
Conceito cobrado
Erro de zona altera totalmente o modelo de confiança e as políticas aplicáveis.
Estrutura dos dados
Entrada: interface mapeada para zona incorreta.
Saída: comportamento inesperado de bloqueio ou exposição.
Como pensar
Quando o tráfego se comporta estranho, valide primeiro mapeamento interface->zona antes de revisar regras.
Como validar
Após corrigir a associação da interface, o tráfego deve voltar ao comportamento previsto pela matriz.
Tabela de Evidência
- Mapa interface/zone conferido em running-config.
- Desvio reproduzível antes da correção.
- Comportamento normalizado após ajuste de zona.
Variáveis-chave
zone-memberinterfacetrust boundary
O que focar no Screenshot
Mostre o trecho de configuração da interface e o teste que evidencia a diferença antes/depois.
Como explicar
Destaque que zone assignment é pré-requisito da política, não detalhe opcional.
Problema & Solução
Problema: Depurar ACL/policy sem conferir zona da interface. Solução: Verificar mapeamento de zonas como primeira etapa de troubleshooting.
interface g0/2
description LAN_ADMIN
zone-member security ADMIN
interface g0/3
description LAN_FIN
zone-member security FINO que a questão pede
Justificar o bloqueio padrão como prática de segurança sustentável.
Conceito cobrado
Menor privilégio reduz superfície e evita permissões esquecidas.
Estrutura dos dados
Entrada: conjunto de fluxos autorizados pela matriz.
Saída: tudo fora da matriz deve cair em bloqueio.
Como pensar
Assuma bloqueio como estado base e trate cada permissão como exceção justificada.
Como validar
Fluxos não autorizados devem falhar de forma consistente sem necessidade de regra específica de negação para cada um.
Tabela de Evidência
- class-default com drop/log nas policies relevantes.
- Teste de fluxo não previsto sendo bloqueado.
- Documentação de exceções realmente necessárias.
Variáveis-chave
class-defaultdropleast privilege
O que focar no Screenshot
Evidencie class-default drop e um teste de tráfego não previsto bloqueado.
Como explicar
Mostre que segurança operável depende de exceções controladas, não de permissões amplas.
Problema & Solução
Problema: Permitir por padrão e tentar negar depois. Solução: Inverter a lógica: negar por padrão e liberar só o necessário.
policy-map type inspect PM_FIN_WAN
class type inspect CM_WEB
inspect
class class-default
drop logO que a questão pede
Listar impactos de implementar firewall sem análise prévia de política e tráfego.
Conceito cobrado
Sem matriz, troubleshooting vira tentativa e erro e segurança perde rastreabilidade.
Estrutura dos dados
Entrada: cenário sem requisitos de fluxo formalizados.
Saída: risco de indisponibilidade e exposição simultâneos.
Como pensar
Todo fluxo deve ter dono, justificativa e teste. Sem isso, qualquer mudança vira risco sistêmico.
Como validar
A presença de matriz + plano de teste deve reduzir retrabalho e reduzir exceções improvisadas.
Tabela de Evidência
- Matriz ausente gera regra inconsistente.
- Testes sem critério não isolam causa raiz.
- Documentação pobre dificulta manutenção e auditoria.
Variáveis-chave
requisitofluxotesterollback
O que focar no Screenshot
Apresente matriz de fluxo e checklist de validação para comprovar método.
Como explicar
Mostre que firewall sem modelo é simultaneamente frágil para operação e segurança.
Problema & Solução
Problema: Configurar primeiro e descobrir requisito depois. Solução: Formalizar fluxo antes de tocar na configuração.
# Modelo mínimo de governança
1) Matriz de fluxos
2) Política proposta
3) Teste positivo e negativo
4) Evidência de resultado
5) Plano de rollbackO que a questão pede
Concluir por que ZBF representa evolução estratégica para a empresa.
Conceito cobrado
ZBF transforma regra dispersa em política legível por domínio de rede e direção.
Estrutura dos dados
Entrada: ambiente segmentado com necessidade de governança contínua.
Saída: arquitetura defensável e auditável no tempo.
Como pensar
Não avalie só se “funcionou hoje”; avalie se outra pessoa consegue manter e auditar amanhã.
Como validar
Uma política madura permite explicar rapidamente quem fala com quem, por qual regra e com qual evidência.
Tabela de Evidência
- Políticas agrupadas por relações de negócio.
- Segmentação que reduz blast radius.
- Facilidade de auditoria com logs e contadores por zone-pair.
Variáveis-chave
governançaauditabilidadesustentabilidade operacional
O que focar no Screenshot
Mostre visão consolidada dos zone-pairs e resultados de teste por relação crítica.
Como explicar
Conclua que o ganho estratégico está na previsibilidade operacional e não apenas na sintaxe do firewall.
Problema & Solução
Problema: Manter colcha de retalhos de ACL difícil de revisar. Solução: Adotar política por zonas com ciclo contínuo de validação por evidência.
# Resumo executivo
- Segmentação explícita LAN/DMZ/WAN
- Menor privilégio com deny-by-default
- Inspeção stateful para retorno de sessão
- Evidência por contadores e logs por zone-pairChecklist de domínio
- Consegue explicar o fluxo permitido por direção sem ambiguidades.
- Consegue justificar cada zone-pair com requisito de negócio.
- Consegue provar bloqueios e permissões com evidência de teste.
- Consegue manter deny-by-default sem quebrar fluxos necessários.
- Consegue revisar políticas sem depender de tentativa e erro.