Referência de Configuração do NGFW — TLSStress.Art Modo DUT¶

Para quem é este documento: o engenheiro de redes responsável por configurar o firewall sendo testado (o Device Under Test — DUT). Este documento contém cada VLAN, endereço IP, rota e política TLS que o NGFW deve ter configurados antes que o test-bed possa gerar tráfego.

Autor: André Luiz Gallon — agallon@Cisco.com | Versão: v3.6.0

Status do escopo (pós-congelamento de escopo 2026-05-10) — Ver ARCHITECTURE.md para os 37 MÓDULOs canônicos + 7 Test Kinds + arquitetura de safety DOM/CPOS/PIE-PA. ADRs 0014, 0019-0025 cobrem adições pós-Freeze.

Índice¶

Como o Test-Bed Funciona
Conectividade Física
Referência Completa de VLANs e IPs
Configuração de Interfaces do NGFW
Tabela de Roteamento
PKI — As Duas CAs
Política de Inspeção TLS
Exemplos de Configuração por Fabricante
Cisco FTD (FMC)
Cisco FTD (FDM)
Cisco ASA
FortiGate
Palo Alto PAN-OS
Check Point
Verificação
Solução de Problemas

1. Como o Test-Bed Funciona¶

O TLSStress.Art posiciona o NGFW no meio de todo o tráfego HTTPS entre usuários simulados (agentes) e sites simulados (personas). O NGFW deve realizar inspeção TLS em cada conexão — e é exatamente isso que está sendo medido.

┌─────────────────────────────────────────────────────────────────┐
│              TLSStress.Art (Ubuntu + k3s)                   │
│                                                                 │
│  Agentes browser-engine (VLAN 20 — 172.16.x.x)                     │
│  Agentes synthetic-load         (VLAN 30 — 172.17.x.x)                     │
└───────────────────────────┬─────────────────────────────────────┘
                            │  TLS Leg 1
                            │  Agentes → NGFW
                            │  NGFW apresenta cert assinado pela sua CA
                            │  Agentes confiam na ngfw-ca (instalada no cluster)
                            ▼
              ┌─────────────────────────┐
              │   NGFW (Device Under    │  ◄── Isto é o que está sendo testado
              │        Test)            │
              │                         │
              │  Motor de Inspeção TLS  │
              │  Descriptografar →      │
              │  Inspecionar →          │
              │  Re-criptografar        │
              └─────────────┬───────────┘
                            │  TLS Leg 2
                            │  NGFW → Webservers das personas
                            │  Certs das personas assinados pela persona-ca
                            │  NGFW confia na persona-ca (instalada no NGFW)
                            ▼
┌─────────────────────────────────────────────────────────────────┐
│           20 Webservers de Personas (Caddy + Kubernetes)        │
│                                                                 │
│  shop        VLAN 101 — 10.1.1.0/27                            │
│  news        VLAN 102 — 10.1.2.0/27                            │
│  ...         ...                                               │
│  har-media   VLAN 120 — 10.1.20.0/27                           │
└─────────────────────────────────────────────────────────────────┘

Dois legs TLS — dois relacionamentos de confiança de certificados distintos:

Leg	Direção	Quem apresenta o cert	Quem deve confiar	Como
Leg 1	Agente → NGFW	NGFW (cert de forward-proxy)	Agentes (browser-engine + synthetic-load)	`ngfw-ca.crt` instalado no cluster Kubernetes
Leg 2	NGFW → Webservers das personas	Webserver da persona (Caddy)	NGFW	`persona-ca.pem` instalado no trust store do NGFW

2. Conectividade Física¶

Cabeamento¶

Servidor Ubuntu (test-bed)
  eth1 (trunk 802.1q) ──────────► Porta trunk do Nexus 9000
                                        │
                                   Trunk VLAN
                                   (todas as VLANs)
                                        │
                               ┌────────┴────────┐
                               │   Nexus 9000    │
                               └────────┬────────┘
                                        │
                             ┌──────────┴──────────┐
                             │   Porta(s) access   │
                             │   para interfaces   │
                             │   de dados do NGFW  │
                             └──────────┬──────────┘
                                        │
                                   ┌────┴────┐
                                   │  NGFW   │
                                   │  (DUT)  │
                                   └─────────┘

Requisitos do Nexus 9000¶

O Nexus 9000 deve ser configurado com as seguintes VLANs e trunk:

vlan 20,30,99,101-120,200-209

interface <trunk-para-ubuntu>
  switchport mode trunk
  switchport trunk allowed vlan 20,30,99,101-120,200-209

interface <para-inside-ngfw>           ! porta NGFW lado agentes
  switchport mode trunk
  switchport trunk allowed vlan 20,30

interface <para-outside-ngfw>          ! porta NGFW lado webservers (Personas Sintéticas + Clonadas)
  switchport mode trunk
  switchport trunk allowed vlan 101-120,200-209

interface <para-mgmt-ngfw>             ! porta de gerência do NGFW (opcional)
  switchport mode access
  switchport access vlan 99

Nota sobre VLAN 10 (removida na v3.7.0): a antiga camada de webserver Caddy único do modo Docker, que rodava na VLAN 10 / 10.20.30.0/24, foi removida. Kubernetes é a única fonte de verdade para webservers DUT — 20 Personas Sintéticas nas VLANs 101–120 + 10 slots de Personas Clonadas nas VLANs 200–209.

3. Referência Completa de VLANs e IPs¶

3.0 Mapeamento de Zonas de Segurança do NGFW (v4.3, travado 2026-05-09)¶

O NGFW tem 8 interfaces (ou sub-interfaces num trunk) distribuídas em 3 zonas:

Zona	VLANs	O que carrega
TRUST / INSIDE	20, 30, 2900	LANs corporativas dos agentes (browser-engine + synthetic-load) + agente de stress de plano de controle (MAC + ARP/NDP)
UNTRUST / OUTSIDE	1982, 2001, 2809, 4338	Endpoints de roteamento/peer VyOS (OSPF, ISP/edge, BGP, MÓDULO SDWAN/CoR-N.Art modo `local` — termo legado "VPN-REMOTE")
MGMT	99	Gerência — SNMP only

VLANs que NÃO terminam no NGFW:

VLAN	Razão
40 (`cloner-isp`)	Cloner egressa direto para Internet pública — bypassa o NGFW
101–120 (Personas Sintéticas)	Personas vivem ATRÁS do pod VyOS-ISP (um `/24` de país por VLAN); o NGFW só vê o enlace edge (VLAN 2001) — VyOS-ISP roteia daí para cada país
200–209 (Personas Clonadas)	Em deprecação — clonadas migram pros `/24`s de país junto com as Sintéticas

⚠️ As seções 3.3 e 4.2 abaixo descrevem a topologia LEGACY v3.x onde personas terminavam em sub-interfaces do NGFW (uma por VLAN 101–120, com gateway NGFW 10.1.x.1). Em v4.3, personas vivem atrás do VyOS-ISP e o NGFW só tem a única interface outside VLAN 2001 para todo o tráfego de personas. Veja docs/ARCHITECTURE.md "DUT network segments" para a topologia corrigida. Migração rastreada separadamente (Personas v4.3 IP migration option B).

3.1 VLANs dos Agentes (Inside — em direção ao NGFW)¶

Estas são as sub-redes onde os agentes de teste residem. O NGFW é o gateway padrão dos agentes.

VLAN	Finalidade	Sub-rede	IP da Interface NGFW	Faixa de IPs dos agentes	Protocolo
20	Agentes browser engine (navegador real)	`172.16.0.0/16`	`172.16.0.1`	`172.16.1.0 – 172.16.255.254`	HTTPS (TCP 443)
30	Agentes synthetic-load engine (carga HTTP)	`172.17.0.0/16`	`172.17.0.1`	`172.17.1.0 – 172.17.255.254`	HTTPS (TCP 443)

Os agentes browser engine geram HTTPS com comportamento real de navegador, com handshake TLS completo e execução de JavaScript. Os agentes synthetic-load engine geram carga HTTP/2 e HTTP/3 em alta escala.

3.2 VLAN de Gerência¶

VLAN	Finalidade	Sub-rede	IP do Nexus 9000	IP de gerência do NGFW	Faixa do pod SNMP
99	Monitoramento SNMP	`192.168.90.0/24`	`192.168.90.2`	`192.168.90.3`	`192.168.90.10 – .49`

O pod SNMP Exporter coleta contadores de CPU, memória e interfaces tanto do Nexus 9000 quanto do NGFW para correlacionar a carga de tráfego com o desempenho do hardware.

3.3 VLANs das Personas (Outside — em direção aos webservers Caddy)¶

Cada persona roda em seu próprio namespace Kubernetes com uma VLAN dedicada, sub-rede /27, certificado TLS e nome DNS. O NGFW é o gateway para conexões de entrada vindas do lado dos agentes.

VLAN	Persona	Sub-rede	IP da Interface NGFW	IP(s) do Webserver	Nome DNS	Tipo de site
101	shop	`10.1.1.0/27`	`10.1.1.1`	`10.1.1.2`	`shop.persona.internal`	E-Commerce (Saleor)
102	news	`10.1.2.0/27`	`10.1.2.1`	`10.1.2.2`	`news.persona.internal`	Portal de Notícias
103	blog	`10.1.3.0/27`	`10.1.3.1`	`10.1.3.2`	`blog.persona.internal`	Blog
104	docs	`10.1.4.0/27`	`10.1.4.1`	`10.1.4.2`	`docs.persona.internal`	Documentação Técnica
105	gallery	`10.1.5.0/27`	`10.1.5.1`	`10.1.5.2`	`gallery.persona.internal`	Galeria de Imagens
106	stream	`10.1.6.0/27`	`10.1.6.1`	`10.1.6.2`	`stream.persona.internal`	Streaming de Vídeo HLS
107	download	`10.1.7.0/27`	`10.1.7.1`	`10.1.7.2`	`download.persona.internal`	Hospedagem de Arquivos
108	edu	`10.1.8.0/27`	`10.1.8.1`	`10.1.8.2`	`edu.persona.internal`	Plataforma de Aprendizado
109	gov	`10.1.9.0/27`	`10.1.9.1`	`10.1.9.2`	`gov.persona.internal`	Portal Governamental
110	cdn	`10.1.10.0/27`	`10.1.10.1`	`10.1.10.2`	`cdn.persona.internal`	CDN de Assets
111	api-rest	`10.1.11.0/27`	`10.1.11.1`	`10.1.11.2`	`api-rest.persona.internal`	API REST
112	api-graphql	`10.1.12.0/27`	`10.1.12.1`	`10.1.12.2`	`api-graphql.persona.internal`	API GraphQL
113	chat	`10.1.13.0/27`	`10.1.13.1`	`10.1.13.2`	`chat.persona.internal`	Chat / Mensagens
114	webhook	`10.1.14.0/27`	`10.1.14.1`	`10.1.14.2`	`webhook.persona.internal`	Webhooks
115	telemetry	`10.1.15.0/27`	`10.1.15.1`	`10.1.15.2`	`telemetry.persona.internal`	Analytics / Telemetria
116	ads	`10.1.16.0/27`	`10.1.16.1`	`10.1.16.2`	`ads.persona.internal`	Rede de Anúncios
117	har-saas	`10.1.17.0/27`	`10.1.17.1`	`10.1.17.2`	`har-saas.persona.internal`	SaaS Corporativo (replay HAR)
118	har-social	`10.1.18.0/27`	`10.1.18.1`	`10.1.18.2`	`har-social.persona.internal`	Rede Social (replay HAR)
119	har-webmail	`10.1.19.0/27`	`10.1.19.1`	`10.1.19.2`	`har-webmail.persona.internal`	Webmail (replay HAR)
120	har-media	`10.1.20.0/27`	`10.1.20.1`	`10.1.20.2`	`har-media.persona.internal`	Streaming de Mídia (replay HAR)

IPs dos webservers: cada pod de persona recebe o primeiro IP disponível em sua faixa (.2). Se houver mais de uma réplica, IPs adicionais (.3, .4 …) são atribuídos. O certificado TLS cobre toda a faixa .2–.30. O NGFW conecta-se diretamente ao IP do webserver (validação via IP SAN).

3.4 Resumo — todas as sub-redes¶

VLAN	Sub-rede	Função	IP da interface NGFW
20	`172.16.0.0/16`	Agentes browser engine	`172.16.0.1`
30	`172.17.0.0/16`	Agentes synthetic-load engine	`172.17.0.1`
99	`192.168.90.0/24`	Gerência SNMP	`192.168.90.3`
101	`10.1.1.0/27`	shop	`10.1.1.1`
102	`10.1.2.0/27`	news	`10.1.2.1`
103	`10.1.3.0/27`	blog	`10.1.3.1`
104	`10.1.4.0/27`	docs	`10.1.4.1`
105	`10.1.5.0/27`	gallery	`10.1.5.1`
106	`10.1.6.0/27`	stream	`10.1.6.1`
107	`10.1.7.0/27`	download	`10.1.7.1`
108	`10.1.8.0/27`	edu	`10.1.8.1`
109	`10.1.9.0/27`	gov	`10.1.9.1`
110	`10.1.10.0/27`	cdn	`10.1.10.1`
111	`10.1.11.0/27`	api-rest	`10.1.11.1`
112	`10.1.12.0/27`	api-graphql	`10.1.12.1`
113	`10.1.13.0/27`	chat	`10.1.13.1`
114	`10.1.14.0/27`	webhook	`10.1.14.1`
115	`10.1.15.0/27`	telemetry	`10.1.15.1`
116	`10.1.16.0/27`	ads	`10.1.16.1`
117	`10.1.17.0/27`	har-saas	`10.1.17.1`
118	`10.1.18.0/27`	har-social	`10.1.18.1`
119	`10.1.19.0/27`	har-webmail	`10.1.19.1`
120	`10.1.20.0/27`	har-media	`10.1.20.1`

4. Configuração de Interfaces do NGFW¶

4.1 Interfaces necessárias¶

O NGFW deve ter no mínimo duas interfaces físicas (ou uma trunk):

Interface	Conectada a	Carrega VLANs	Direção
Inside (lado dos agentes)	Nexus 9000	20, 30	Agentes → NGFW
Outside (lado dos servidores)	Nexus 9000	101–120	NGFW → Webservers das personas
Management (opcional)	Nexus 9000	99	Apenas monitoramento SNMP

4.2 IPs das subinterfaces a configurar¶

Para cada VLAN, o NGFW precisa de uma subinterface com o IP de gateway listado na seção 3. Exemplo para uma interface inside com suporte a trunk:

# Interface inside — voltada para os agentes
VLAN 20  → IP 172.16.0.1/16   (gateway dos agentes browser-engine)
VLAN 30  → IP 172.17.0.1/16   (gateway dos agentes synthetic-load)

# Interface outside — voltada para os webservers
VLAN 101 → IP 10.1.1.1/27    (gateway de shop)
VLAN 102 → IP 10.1.2.1/27    (gateway de news)
VLAN 103 → IP 10.1.3.1/27    (gateway de blog)
VLAN 104 → IP 10.1.4.1/27    (gateway de docs)
VLAN 105 → IP 10.1.5.1/27    (gateway de gallery)
VLAN 106 → IP 10.1.6.1/27    (gateway de stream)
VLAN 107 → IP 10.1.7.1/27    (gateway de download)
VLAN 108 → IP 10.1.8.1/27    (gateway de edu)
VLAN 109 → IP 10.1.9.1/27    (gateway de gov)
VLAN 110 → IP 10.1.10.1/27   (gateway de cdn)
VLAN 111 → IP 10.1.11.1/27   (gateway de api-rest)
VLAN 112 → IP 10.1.12.1/27   (gateway de api-graphql)
VLAN 113 → IP 10.1.13.1/27   (gateway de chat)
VLAN 114 → IP 10.1.14.1/27   (gateway de webhook)
VLAN 115 → IP 10.1.15.1/27   (gateway de telemetry)
VLAN 116 → IP 10.1.16.1/27   (gateway de ads)
VLAN 117 → IP 10.1.17.1/27   (gateway de har-saas)
VLAN 118 → IP 10.1.18.1/27   (gateway de har-social)
VLAN 119 → IP 10.1.19.1/27   (gateway de har-webmail)
VLAN 120 → IP 10.1.20.1/27   (gateway de har-media)

# Interface de gerência
VLAN 99  → IP 192.168.90.3/24 (monitoramento SNMP)

4.3 Zonas de segurança¶

Crie duas zonas de segurança no NGFW:

Nome da zona	Interfaces	Nível de confiança
`agents`	VLAN 20, VLAN 30	Menor (clientes — origem de tráfego não confiável)
`personas`	VLANs 101–120	Maior (servidores — tráfego a ser inspecionado)

5. Tabela de Roteamento¶

O NGFW deve ser capaz de rotear tráfego entre as sub-redes dos agentes e das personas. Como ele é o gateway de todas as sub-redes, as rotas conectadas cobrem o encaminhamento local. Nenhuma rota estática é estritamente necessária, a menos que o NGFW precise de um gateway padrão para gerência.

Destino	Próximo salto	Interface	Finalidade
`172.16.0.0/16`	diretamente conectado	Inside.20	Agentes browser engine
`172.17.0.0/16`	diretamente conectado	Inside.30	Agentes synthetic-load engine
`10.1.1.0/27` – `10.1.20.0/27`	diretamente conectado	Outside.101–120	Webservers das personas
`192.168.90.0/24`	diretamente conectado	Mgmt.99	Gerência SNMP
`0.0.0.0/0`	GW da rede de gerência	Management	Acesso à internet para atualizações (opcional)

Roteamento baseado em política: alguns NGFWs aplicam decisões de roteamento por regra de política de segurança. Certifique-se de que sua política de acesso permite tráfego da zona agents para a zona personas nas portas TCP 443 (e UDP 443 para HTTP/3 / QUIC).

6. PKI — As Duas CAs¶

Esta é a parte mais crítica da configuração do NGFW. Existem duas CAs completamente diferentes, cada uma usada para um leg TLS distinto.

6.1 CA para o Leg 2 — `persona-ca` (importar NO NGFW)¶

O que é: a CA interna usada pelo cert-manager no cluster Kubernetes para assinar os certificados TLS de todas as personas Caddy (20 Synthetic + 10 Cloned slots).

Por que o NGFW precisa dela: no Leg 2 (NGFW → webserver), o NGFW atua como cliente TLS e deve validar o certificado do servidor apresentado pelo Caddy. Se o NGFW não confiar na persona-ca, rejeitará a conexão com erro de validação de certificado.

Como exportar do cluster:

# No servidor Ubuntu (após executar k8s-dut-up.sh ou k8s-install.sh)
kubectl get secret persona-ca -n web-agents \
  -o jsonpath='{.data.ca\.crt}' | base64 -d > persona-ca.pem

# Verificar o certificado
openssl x509 -in persona-ca.pem -text -noout | grep -E "Subject:|Issuer:|Not After"

Saída esperada:

Subject: O=Web Agent Cluster, OU=DUT Lab, CN=Persona CA
Issuer:  O=Web Agent Cluster, OU=DUT Lab, CN=Persona CA
Not After: <data ~10 anos após a criação do cluster>

Onde importar no NGFW: consulte a seção 8 para instruções específicas por fabricante. Em geral: trusted CA store / trusted CAs para inspeção SSL.

6.2 CA para o Leg 1 — `ngfw-ca` (exportar DO NGFW, instalar no cluster)¶

O que é: a CA que o NGFW usa para assinar os certificados de forward-proxy que apresenta aos agentes durante o Leg 1. É a CA de interceptação própria do NGFW.

Por que o cluster precisa dela: os agentes browser engine (Node.js) e synthetic-load engine (Go) validam o certificado do servidor em cada conexão HTTPS. Se não confiarem na CA do NGFW, todas as conexões falharão com CERT_AUTHORITY_INVALID ou similar.

Como exportar de cada fabricante:

Fabricante	Onde encontrar	Formato de exportação
Cisco FTD (FMC)	Objects → PKI → CA Certificates → selecione a CA de interceptação → Export	PEM
Cisco FTD (FDM)	Policies → SSL → Trusted CA → exportar	PEM
Cisco ASA	`crypto ca export <trustpoint> certificate`	PEM (copiar do terminal)
FortiGate	Security Profiles → SSL/SSH Inspection → CA Certificate → Download	PEM
Palo Alto	Device → Certificate Management → Certificates → selecione o cert de forward-trust → Export	PEM
Check Point	SmartConsole → Gateways → HTTPS Inspection → CA Certificate → Export	PEM ou Base64
Huawei USG	System → PKI → CA Certificate → Export	PEM
Meraki MX	Security & SD-WAN → Content Filtering → SSL Inspection → Download CA Certificate	PEM

Como instalar no cluster:

# Substitua pelo caminho real do arquivo PEM exportado
kubectl create configmap ngfw-ca \
  -n web-agents \
  --from-file=ngfw-ca.crt=./ngfw-ca.pem \
  --dry-run=client -o yaml | kubectl apply -f -

# Verificar se foi aplicado
kubectl get configmap ngfw-ca -n web-agents -o yaml | grep 'ngfw-ca.crt' -A 3

# Reiniciar os agentes para carregar a nova CA
kubectl rollout restart deployment/web-agent  -n web-agents
kubectl rollout restart deployment/k6-agent   -n web-agents
kubectl rollout status  deployment/web-agent  -n web-agents
kubectl rollout status  deployment/k6-agent   -n web-agents

7. Política de Inspeção TLS¶

7.1 O que inspecionar¶

Configure a política de inspeção TLS para descriptografar e inspecionar todo o tráfego HTTPS entre as sub-redes dos agentes e das personas:

Origem	Destino	Porta	Ação
`172.16.0.0/16` (browser engine)	`10.1.0.0/16` (todas as personas)	TCP 443	Descriptografar e Inspecionar
`172.17.0.0/16` (synthetic-load engine)	`10.1.0.0/16` (todas as personas)	TCP 443	Descriptografar e Inspecionar
`172.16.0.0/16` (browser engine)	`10.1.0.0/16` (todas as personas)	UDP 443	Descriptografar e Inspecionar (QUIC/HTTP3)
`172.17.0.0/16` (synthetic-load engine)	`10.1.0.0/16` (todas as personas)	UDP 443	Descriptografar e Inspecionar (QUIC/HTTP3)

7.2 Versões TLS¶

Os webservers Caddy suportam TLS 1.2 e TLS 1.3. Configure o NGFW para inspecionar ambos:

Mínimo: TLS 1.2
Máximo: TLS 1.3
Desabilitar: TLS 1.1, TLS 1.0, SSL 3.0

7.3 Conjuntos de cifras¶

O Caddy usa exclusivamente cipher suites ECDHE+AEAD (certificados ECDSA). Certifique-se de que sua política de inspeção não faça downgrade para cifras RSA ou CBC:

TLS_AES_256_GCM_SHA384          (TLS 1.3)
TLS_AES_128_GCM_SHA256          (TLS 1.3)
TLS_CHACHA20_POLY1305_SHA256    (TLS 1.3)
ECDHE-ECDSA-AES256-GCM-SHA384  (TLS 1.2)
ECDHE-ECDSA-AES128-GCM-SHA256  (TLS 1.2)
ECDHE-ECDSA-CHACHA20-POLY1305  (TLS 1.2)

7.4 HTTP/3 (QUIC) — nota importante¶

O agente k6 pode gerar HTTP/3 (QUIC via UDP 443). A inspeção TLS de HTTP/3 é mais difícil para NGFWs e é uma das principais métricas sendo medidas. Consulte a documentação do seu fabricante para suporte à inspeção QUIC:

Se inspeção QUIC é suportada: habilite e inclua UDP 443 na política de inspeção.
Se inspeção QUIC não é suportada (ou você quer medir apenas HTTP/2): adicione uma regra para bloquear ou resetar UDP 443, forçando os agentes a fazer fallback para HTTP/2 via TCP. Este é um cenário de teste válido — mede o impacto de forçar clientes capazes de QUIC a fazer downgrade.

7.5 Validação de certificado no Leg 2¶

O NGFW deve validar o certificado do servidor durante o Leg 2 (NGFW → Caddy). Certifique-se de que:

Validação do certificado do servidor: habilitada (não ignorada)
Trust store: inclui persona-ca.pem (veja a seção 6.1)
Revogação de certificado: CRL/OCSP pode ser desabilitado — este é um laboratório sem infraestrutura de revogação

8. Exemplos de Configuração por Fabricante¶

8.1 Cisco FTD — Firepower Management Center¶

Passo 1: Importar persona-ca (confiar nos certs dos webservers das personas)¶

Objects → PKI → Trusted CAs → Add Trusted CA
Nome: Persona-CA
Carregar persona-ca.pem
Clicar em Save

Passo 2: Exportar ngfw-ca (para que os agentes confiem no NGFW)¶

Objects → PKI → CA Certificates → selecione sua CA de interceptação
Clicar em Export → baixar PEM
Instalar no cluster: kubectl create configmap ngfw-ca -n web-agents --from-file=ngfw-ca.crt=<arquivo>.pem

Passo 3: Criar Política SSL¶

Policies → SSL → New Policy
Nome: DUT-TLS-Inspection
Adicionar regra:
Action: Decrypt — Resign
Source Zones: agents
Destination Zones: personas
Destination Ports: TCP 443, UDP 443
Resign CA: selecionar sua CA de interceptação
Default Action: Do Not Decrypt (passar demais tráfegos sem inspeção)

Passo 4: Criar regra na Política de Controle de Acesso¶

Policies → Access Control → sua política
Adicionar regra acima do padrão:
Source Networks: 172.16.0.0/16, 172.17.0.0/16
Destination Networks: 10.1.0.0/16
Destination Ports: TCP 443, UDP 443
SSL Policy: DUT-TLS-Inspection
Action: Allow (com inspeção)
Intrusion Policy: vincule se quiser métricas de IPS durante o teste
Fazer deploy para o sensor FTD

Passo 5: Configurar interfaces¶

# No FMC: Devices → Device Management → selecione seu FTD → Interfaces
# Configure subinterfaces nas interfaces físicas:

Interface inside (trunk):
  Subinterface 20: VLAN 20, IP 172.16.0.1/16, Security Zone: agents
  Subinterface 30: VLAN 30, IP 172.17.0.1/16, Security Zone: agents

Interface outside (trunk):
  Subinterface 101: VLAN 101, IP 10.1.1.1/27,  Security Zone: personas
  Subinterface 102: VLAN 102, IP 10.1.2.1/27,  Security Zone: personas
  ...
  Subinterface 120: VLAN 120, IP 10.1.20.1/27, Security Zone: personas

Interface de gerência:
  Subinterface 99: VLAN 99, IP 192.168.90.3/24  (fora de banda, SNMP)

8.2 Cisco FTD — Firepower Device Manager¶

Importar persona-ca¶

Objects → Certificates → Trusted CA → Add
Nome: Persona-CA, carregar persona-ca.pem

Exportar ngfw-ca¶

Policies → SSL → Trusted CA → exportar sua CA de interceptação

Criar Política de Descriptografia SSL¶

Policies → SSL Decryption → Add Rule
Origem: 172.16.0.0/16, 172.17.0.0/16
Destino: 10.1.0.0/16
Porta: HTTPS (443/tcp)
Ação: Decrypt — Resign com sua CA de interceptação

8.3 Cisco ASA¶

ASA com FirePOWER Services (módulo SFR) ou ASA com inspeção SSL do AnyConnect:

# Importar persona-ca como CA confiável
crypto ca authenticate DUT-ROOT-CA

# Colar o conteúdo PEM quando solicitado (conteúdo de persona-ca.pem)

# Criar crypto map ou política de inspeção SSL direcionando:
#   src 172.16.0.0 255.255.0.0 e 172.17.0.0 255.255.0.0
#   dst 10.1.0.0 255.255.0.0
#   porta 443

# Criar subinterfaces para as VLANs dos agentes
interface GigabitEthernet0/0.20
 encapsulation dot1Q 20
 ip address 172.16.0.1 255.255.0.0
 nameif agents-pw
 security-level 50

interface GigabitEthernet0/0.30
 encapsulation dot1Q 30
 ip address 172.17.0.1 255.255.0.0
 nameif agents-k6
 security-level 50

# Criar subinterfaces para VLANs das personas (repetir para 101-120)
interface GigabitEthernet0/1.101
 encapsulation dot1Q 101
 ip address 10.1.1.1 255.255.255.224
 nameif persona-shop
 security-level 0

# ... repetir para VLANs 102-120 ...

# Habilitar inspeção SSL via módulo FirePOWER ou ASA CX

8.4 FortiGate¶

Criar VLANs e IPs das interfaces¶

# Na CLI:
config system interface
  edit "inside.20"
    set vdom "root"
    set ip 172.16.0.1 255.255.0.0
    set allowaccess ping
    set type vlan
    set interface "port1"
    set vlanid 20
    set role lan
  next
  edit "inside.30"
    set vdom "root"
    set ip 172.17.0.1 255.255.0.0
    set type vlan
    set interface "port1"
    set vlanid 30
    set role lan
  next
  edit "outside.101"
    set vdom "root"
    set ip 10.1.1.1 255.255.255.224
    set type vlan
    set interface "port2"
    set vlanid 101
    set role wan
  next
  # ... repetir para VLANs 102-120 ...
end

Importar persona-ca¶

# GUI: Security Profiles → SSL/SSH Inspection → Criar/Editar perfil
# Em "CA Certificate": importar persona-ca.pem

# Ou via CLI:
config vpn certificate ca
  edit "Persona-CA"
    set ca "<persona-ca codificado em base64>"
  next
end

Exportar ngfw-ca¶

# GUI: Security Profiles → SSL/SSH Inspection → selecione seu perfil
#       → CA Certificate → Download
# Isso baixa a CA de interceptação do FortiGate em formato PEM.

Criar Perfil de Inspeção SSL/SSH¶

# GUI: Security Profiles → SSL/SSH Inspection → Create New
config firewall ssl-ssh-profile
  edit "DUT-Inspection"
    set comment "TLSStress.Art modo DUT"
    config https
      set ports 443
      set status deep-inspection
      set proxy-after-tcp-handshake enable
    end
    config ssl
      set inspect-all deep-inspection
    end
    set caname "Persona-CA"
  next
end

Criar política de firewall¶

config firewall policy
  edit 100
    set name "DUT-agentes-para-personas"
    set srcintf "inside.20" "inside.30"
    set dstintf "outside.101" "outside.102" ... "outside.120"
    set srcaddr "172.16.0.0/16" "172.17.0.0/16"
    set dstaddr "10.1.0.0/16"
    set action accept
    set schedule "always"
    set service "HTTPS"
    set ssl-ssh-profile "DUT-Inspection"
    set utm-status enable
    set logtraffic all
  next
end

8.5 Palo Alto PAN-OS¶

Importar persona-ca¶

# GUI: Device → Certificate Management → Certificates → Import
# Nome: Persona-CA
# Arquivo: persona-ca.pem
# Marcar como: "Trusted Root CA"

# Ou via CLI:
scp import certificate from <usuario@host:/caminho/persona-ca.pem>
> certificate-name Persona-CA
> category trusted-root-CA

Exportar ngfw-ca¶

# GUI: Device → Certificate Management → Certificates →
#       selecione seu certificado de forward-trust → Export Certificate
# Formato: Base64 Encoded Certificate (PEM)

Criar interfaces¶

# GUI: Network → Interfaces → Ethernet → Add Sub-Interface

# Interface inside (em direção aos agentes)
Ethernet1/1.20:  IP 172.16.0.1/16, VLAN 20, Zone: agents
Ethernet1/1.30:  IP 172.17.0.1/16, VLAN 30, Zone: agents

# Interface outside (em direção às personas)
Ethernet1/2.101: IP 10.1.1.1/27,   VLAN 101, Zone: personas
Ethernet1/2.102: IP 10.1.2.1/27,   VLAN 102, Zone: personas
# ... repetir para 103-120 ...

Criar Perfil de Descriptografia¶

# GUI: Objects → Decryption Profile → Add
# Nome: DUT-Decrypt-Profile
# SSL Forward Proxy:
#   Forward Trust Certificate: <sua CA de interceptação>
#   Forward Untrust Certificate: <sua CA de não-confiança>
# Server Certificate Verification:
#   Block sessions with expired certificates: yes
#   Block sessions with untrusted issuers: yes (com persona-ca como confiável)

Criar Política de Descriptografia¶

# GUI: Policies → Decryption → Add
# Nome: DUT-Decrypt-All
# Source Zone: agents
# Destination Zone: personas
# Source Address: 172.16.0.0/16, 172.17.0.0/16
# Destination Address: 10.1.0.0/16
# Service: application-default (ou crie serviço HTTPS para 443/tcp + 443/udp)
# Type: SSL Forward Proxy
# Profile: DUT-Decrypt-Profile

Criar Política de Segurança¶

# GUI: Policies → Security → Add
# Nome: agents-para-personas
# Source Zone: agents
# Destination Zone: personas
# Application: ssl, web-browsing
# Service: application-default
# Action: Allow
# Profile Group: vincule seu perfil de ameaça/URL

8.6 Check Point¶

Importar persona-ca¶

# SmartConsole → Objects → New → Certificate Authority → Trusted CA
# Nome: Persona-CA
# Carregar: persona-ca.pem

Exportar ngfw-ca¶

# SmartConsole → Gateways & Servers → clique duplo no seu gateway
# → HTTPS Inspection → CA Certificate → Export
# Salvar como PEM

Configurar Inspeção HTTPS¶

# SmartConsole → Security Policies → HTTPS Inspection → Policy
# Adicionar regra:
# Nome: DUT-Inspection
# Source: Group(172.16.0.0/16, 172.17.0.0/16)
# Destination: Group(10.1.1.0/27 - 10.1.20.0/27)
# Services: HTTPS (443)
# Site Category: Any
# Action: Inspect
# Track: Log

# Em Blade Control → SSL Inspection → Trusted CA:
# Adicionar Persona-CA ao trust store

Configurar interfaces¶

# SmartConsole → Gateways → Interfaces → Add VLAN
# Criar subinterfaces para cada VLAN (20, 30, 101-120)
# Atribuir IPs conforme a seção 3 acima

9. Verificação¶

9.1 Verificar conectividade a partir do cluster¶

# SSH em um dos pods de agente
kubectl exec -it -n web-agents deployment/web-agent -- sh

# Testar se o gateway NGFW está acessível
ping -c 3 172.16.0.1        # Gateway VLAN 20 (browser-engine)
ping -c 3 172.17.0.1        # Gateway VLAN 30 (K6, a partir do pod K6)

# Testar HTTPS para uma persona (deve funcionar se a inspeção TLS estiver ativa)
curl -v https://shop.persona.internal/ --max-time 5
# Esperado: HTTP 200, certificado emitido pela CA do NGFW

9.2 Verificar se a inspeção TLS está ativa¶

# A partir de um pod de agente, inspecionar a cadeia de certificados apresentada pelo NGFW
echo | openssl s_client -connect shop.persona.internal:443 -servername shop.persona.internal 2>/dev/null \
  | openssl x509 -noout -issuer -subject

# Saída esperada (certificado emitido pelo NGFW, não pela persona-ca):
# issuer=CN=<nome da CA de interceptação do NGFW>
# subject=CN=shop.persona.internal   (re-assinado pelo NGFW)

9.3 Verificar monitoramento SNMP¶

# A partir do pod SNMP, testar conectividade com o NGFW
kubectl exec -it -n web-agents deployment/snmp-exporter -- sh
snmpwalk -v2c -c <community> 192.168.90.3 1.3.6.1.2.1.1.1.0

# Esperado: sysDescr do NGFW

9.4 Verificar Leg 2 TLS (NGFW confia no cert do webserver)¶

Verifique os logs do NGFW em busca de erros TLS no leg de saída. Se houver falhas de validação de certificado em direção a 10.1.x.x, a persona-ca não foi importada corretamente.

# No cluster: confirmar a cadeia de certificados do webserver
echo | openssl s_client -connect 10.1.1.2:443 2>/dev/null \
  | openssl x509 -noout -issuer -subject

# Esperado (antes da interceptação pelo NGFW — direto do servidor Ubuntu):
# issuer=CN=Persona CA
# subject=CN=shop.persona.internal

10. Solução de Problemas¶

Sintoma	Causa provável	Solução
Agentes recebem `CERT_AUTHORITY_INVALID`	`ngfw-ca` não instalada no cluster ou agentes não reiniciados	Re-executar `kubectl create configmap ngfw-ca ...` e `kubectl rollout restart deployment/web-agent`
NGFW mostra erro de validação de cert no Leg 2	`persona-ca` não importada no trust store do NGFW	Exportar `persona-ca.pem` do cluster e importar no trusted CA store do NGFW
Conexões HTTP/3 falham mas HTTP/2 funciona	NGFW não suporta inspeção QUIC	Bloquear UDP 443 no NGFW para forçar downgrade para HTTP/2; registrar isso nos resultados do teste
Agentes não conseguem alcançar IPs das personas (`10.1.x.x`)	Rotas ausentes ou política do NGFW bloqueando	Verificar se a política de segurança do NGFW permite `172.16.0.0/16` e `172.17.0.0/16` para `10.1.0.0/16`
SNMP exporter não retorna dados do NGFW	SNMP do NGFW não habilitado, community errada ou VLAN 99 inacessível	Verificar se SNMP do NGFW está habilitado com community `public` (ou conforme `observability/snmp/snmp.yml`); verificar se o IP `192.168.90.3` na VLAN 99 responde a ping
Inspeção TLS não está sendo ativada	Política SSL não vinculada à regra de acesso ou zonas mal configuradas	Verificar se zonas de origem/destino correspondem às interfaces dos agentes e das personas
Erros de certificado após renovação de cert de persona	NGFW com fingerprint de cert antigo em cache	O cert-manager renova automaticamente os certs das personas a cada 11 meses; o Stakater Reloader reinicia os pods Caddy — nenhuma alteração no NGFW é necessária

Para detalhes de arquitetura do test-bed, consulte docs/ARCHITECTURE.md. Para instruções de deploy, consulte docs/UBUNTU_K3S_SINGLENODE_QUICKSTART_DEPLOY.pt-BR.md. Para o instalador Kubernetes automatizado, consulte scripts/k8s-install.sh.

Referência de Configuração do NGFW — TLSStress.Art Modo DUT¶

Índice¶

1. Como o Test-Bed Funciona¶

2. Conectividade Física¶

Cabeamento¶

Requisitos do Nexus 9000¶

3. Referência Completa de VLANs e IPs¶

3.0 Mapeamento de Zonas de Segurança do NGFW (v4.3, travado 2026-05-09)¶

3.1 VLANs dos Agentes (Inside — em direção ao NGFW)¶

3.2 VLAN de Gerência¶

3.3 VLANs das Personas (Outside — em direção aos webservers Caddy)¶

3.4 Resumo — todas as sub-redes¶

4. Configuração de Interfaces do NGFW¶

4.1 Interfaces necessárias¶

4.2 IPs das subinterfaces a configurar¶

4.3 Zonas de segurança¶

5. Tabela de Roteamento¶

6. PKI — As Duas CAs¶

6.1 CA para o Leg 2 — persona-ca (importar NO NGFW)¶

6.2 CA para o Leg 1 — ngfw-ca (exportar DO NGFW, instalar no cluster)¶

7. Política de Inspeção TLS¶

7.1 O que inspecionar¶

7.2 Versões TLS¶

7.3 Conjuntos de cifras¶

7.4 HTTP/3 (QUIC) — nota importante¶

7.5 Validação de certificado no Leg 2¶

8. Exemplos de Configuração por Fabricante¶

8.1 Cisco FTD — Firepower Management Center¶

Passo 1: Importar persona-ca (confiar nos certs dos webservers das personas)¶

Passo 2: Exportar ngfw-ca (para que os agentes confiem no NGFW)¶

Passo 3: Criar Política SSL¶

Passo 4: Criar regra na Política de Controle de Acesso¶

Passo 5: Configurar interfaces¶

8.2 Cisco FTD — Firepower Device Manager¶

Importar persona-ca¶

Exportar ngfw-ca¶

Criar Política de Descriptografia SSL¶

8.3 Cisco ASA¶

8.4 FortiGate¶

Criar VLANs e IPs das interfaces¶

Importar persona-ca¶

Exportar ngfw-ca¶

Criar Perfil de Inspeção SSL/SSH¶

Criar política de firewall¶

8.5 Palo Alto PAN-OS¶

Importar persona-ca¶

Exportar ngfw-ca¶

Criar interfaces¶

Criar Perfil de Descriptografia¶

Criar Política de Descriptografia¶

Criar Política de Segurança¶

8.6 Check Point¶

Importar persona-ca¶

Exportar ngfw-ca¶

Configurar Inspeção HTTPS¶

Configurar interfaces¶

9. Verificação¶

9.1 Verificar conectividade a partir do cluster¶

9.2 Verificar se a inspeção TLS está ativa¶

9.3 Verificar monitoramento SNMP¶

9.4 Verificar Leg 2 TLS (NGFW confia no cert do webserver)¶

10. Solução de Problemas¶

6.1 CA para o Leg 2 — `persona-ca` (importar NO NGFW)¶

6.2 CA para o Leg 1 — `ngfw-ca` (exportar DO NGFW, instalar no cluster)¶