Acelerando o troubleshooting do AWS Network Firewall com o AWS DevOps Agent

O problema: correlacionar dados manualmente custa tempo

Quando um administrador altera uma regra no AWS Network Firewall e a conectividade cai, identificar a causa exige inspecionar vários pontos ao longo do caminho do tráfego. O firewall oferece motores de regras stateless e stateful, regras de domínio e roteamento até o endpoint do firewall dentro da Rede Virtual Privada da Amazon (Amazon VPC). Para a carga de trabalho, uma queda de pacotes parece idêntica independentemente de onde se originou. Isolar a causa significa cruzar logs de alertas e de fluxo com a configuração do firewall, tabelas de rotas e chamadas de API recentes no AWS CloudTrail que possam ter modificado algum desses recursos.

É exatamente nessa correlação manual que o AWS DevOps Agent entra. Funcionando como um parceiro de operações sempre disponível, ele resolve e previne proativamente problemas operacionais em ambientes AWS, multicloud e on-premises. Quando um alarme do Amazon CloudWatch dispara, ele chega ao agente via webhook. O agente lê a configuração e os logs do firewall pelas APIs da AWS, associa a queda à atividade recente de API e devolve uma causa raiz acompanhada de um plano de mitigação — que você revisa antes de aplicar.

A arquitetura do ambiente de demonstração

A AWS disponibilizou um aplicativo AWS Cloud Development Kit (AWS CDK) que implanta todo o ambiente na sua própria conta, permitindo reproduzir cada falha e acompanhar o passo a passo. A carga de trabalho consiste em uma instância t3.micro em uma sub-rede protegida que verifica conectividade com um endpoint de teste em loop contínuo e publica os resultados no CloudWatch. O tráfego percorre o caminho de saída pela internet através do Network Firewall, do gateway NAT e do gateway de internet.

O endpoint de teste roda em uma VPC separada implantada pelo mesmo aplicativo CDK, servindo HTTPS na porta 443 e TCP na porta 9142. O pipeline de alarmes corre do CloudWatch pelo Amazon Simple Notification Service (Amazon SNS) e por uma função AWS Lambda de webhook até o DevOps Agent.

Para usar o mesmo padrão com sua própria carga de trabalho, você precisa de um alarme no CloudWatch que detecte o problema de conectividade e do pipeline de webhook (tópico SNS e função Lambda) que o entrega ao DevOps Agent. O agente lê configuração do firewall, logs e CloudTrail pelas APIs da AWS — sem necessidade de instrumentação adicional no lado do firewall.

Pré-requisitos e implantação

Para seguir o guia, são necessários:

• Uma conta AWS com permissões para implantar Amazon VPC, Network Firewall, Amazon Elastic Compute Cloud (Amazon EC2), CloudWatch, Amazon SNS, Lambda, Amazon CloudFront e recursos de AWS Identity and Access Management (IAM)
• Acesso ao AWS DevOps Agent com permissão para configurar o webhook
• Node.js 18 ou superior e npm instalados
• AWS Command Line Interface (AWS CLI) 2.x configurado com credenciais
• AWS CDK 2.x

O deploy é feito clonando o repositório e executando o script abaixo, que verifica pré-requisitos, instala dependências, compila, testa, faz o bootstrap do CDK se necessário e implanta todas as stacks:

git clone https://github.com/aws-samples/sample-accelerating-aws-network-firewall-troubleshooting-with-aws-devops-agent.git
cd sample-accelerating-aws-network-firewall-troubleshooting-with-aws-devops-agent
bash scripts/deploy.sh

Após o deploy, abra o link da página de status (um endereço https://<random-id>.cloudfront.net) e confirme que os três cards mostram o status Healthy (saudável) em verde.

Como o pipeline de alarmes funciona

Todos os cenários chegam ao DevOps Agent pelo mesmo caminho: um alarme do CloudWatch muda para o estado ALARM e notifica o tópico SNS. O SNS invoca a função Lambda, que lê a URL do webhook e o segredo de assinatura do AWS Secrets Manager, assina o payload do alarme e faz um POST para o webhook do DevOps Agent.

Há dois tipos de alarme no ambiente de demonstração:

• Alarm-1 — usa a métrica nativa AWS/NetworkFirewall DroppedPackets, somada nos fluxos stateful. Não exige nenhuma instrumentação adicional na carga de trabalho, mas só informa que o firewall está descartando pacotes, sem identificar qual regra é responsável.
• Alarm-2 e Alarm-3 — usam uma métrica customizada de verificação de conectividade. São úteis para alarmes vinculados ao impacto real no usuário ou para distinguir um caminho de tráfego de outro.

Cenário 1: lista de negação de domínio bloqueando um endpoint legítimo

Na baseline, o grupo de regras Suricata rg-domain nega apenas um placeholder não utilizado, mantendo o endpoint de teste acessível. O grupo inspeciona o Indicador de Nome do Servidor TLS (TLS SNI) em cada conexão de saída e descarta as que correspondem a um domínio negado.

Para introduzir a falha, adiciona-se uma regra drop no grupo rg-domain que corresponde ao nome DNS do endpoint de teste no SNI do TLS:

drop tls $HOME_NET any -> $EXTERNAL_NET any (ssl_state:client_hello; tls.sni; content:"<app-endpoint-dns>"; startswith; nocase; endswith; msg:"S1 domain denylist"; flow:to_server, established; sid:2000002; rev:1;)

Após salvar, a verificação HTTPS da carga de trabalho para o endpoint expira, a métrica DroppedPackets sobe acima da baseline e o Alarm-1 entra em ALARM. Os cenários 2 e 3 permanecem saudáveis.

O DevOps Agent executa várias linhas de investigação em paralelo:

• Lê a métrica DroppedPackets e correlaciona o pico com uma queda simultânea em pacotes passados, confirmando que o firewall está bloqueando tráfego ativamente.
• Lê o log de ALERTA e encontra as conexões TLS da carga de trabalho bloqueadas pela regra S1 domain denylist.
• Compara o estado atual com uma janela de baseline onde o mesmo endpoint era acessível sem alertas.
• Busca no CloudTrail e identifica a chamada UpdateRuleGroup que adicionou a regra de negação, com usuário, papel assumido e timestamp — aproximadamente um minuto antes do início dos descartes.
• Reporta a causa raiz como aquela alteração manual no grupo de regras e recomenda remover a entrada de negação ou adicionar uma exceção de permissão, além de habilitar FirewallPolicyChangeProtection para evitar alterações não autorizadas.

Atenção: em um ambiente real, esse tipo de regra normalmente existe por um motivo. Antes de removê-la, verifique se foi intencional mas com escopo muito amplo. Se for o caso, refine a regra para bloquear apenas endpoints não autorizados em vez de removê-la inteiramente.

Cenário 2: inversão de prioridade em regra stateless

Na baseline, o grupo de regras stateless rg-stateless-priority mantém a regra de permissão na prioridade 100 e a regra de descarte na prioridade 200 para a classe de tráfego TCP na porta de destino 9142. Como o Network Firewall avalia os números de prioridade menores primeiro, a regra de permissão vence.

Para introduzir a falha, inverte-se as duas prioridades: a regra de permissão passa para a prioridade 300 e a regra de descarte permanece em 200. Isso faz com que a regra de descarte seja avaliada primeiro — exatamente o tipo de erro que uma edição apressada pode introduzir.

Como um descarte stateless ocorre antes de o tráfego alcançar o motor de inspeção stateful, não há entradas de ALERTA nos logs. O agente recorre à configuração e aos logs de fluxo:

• Lê o estado do grupo de regras stateless e encontra a regra de descarte com número de prioridade menor, à frente da regra de permissão.
• Lê os logs de fluxo e observa os pacotes passados caírem a zero dentro de um minuto após a mudança.
• Busca no CloudTrail e identifica a chamada UpdateRuleGroup que inverteu as prioridades.
• Reporta a causa raiz como essa inversão de prioridade e recomenda remover a regra de descarte redundante e gerenciar o grupo de regras por infraestrutura como código (IaC) para evitar erros manuais.

Cenário 3: descarte por roteamento assimétrico entre Zonas de Disponibilidade

Na baseline, a sub-rede protegida em cada Zona de Disponibilidade (AZ) roteia sua saída pelo endpoint do firewall na mesma AZ. Assim, um endpoint vê as duas direções do fluxo e o motor stateful completa o handshake.

Para criar a falha, são necessárias duas edições de tabela de rotas: a saída da sub-rede protegida em us-east-1a é apontada para o endpoint do firewall em us-east-1b, e a rota de retorno na sub-rede pública de us-east-1b é apontada para o endpoint do firewall em us-east-1a. Com isso, a saída de um fluxo passa por um endpoint enquanto o retorno chega ao outro — nenhum endpoint vê o fluxo completo e o handshake falha.

Diferente dos cenários anteriores, esse problema afeta toda a sub-rede e faz com que o Alarm-2 e o Alarm-3 disparem ao mesmo tempo. O Alarm-1 (baseado em DroppedPackets) permanece silencioso, pois nenhum endpoint toma uma decisão de descarte — o fluxo simplesmente se perde pelo roteamento assimétrico. Isso ilustra por que monitorar a conectividade da aplicação é fundamental: uma falha de roteamento é invisível para o contador de descartes do próprio firewall.

O DevOps Agent reconhece os dois alarmes como relacionados e os une em uma única investigação:

• Lê os logs de fluxo e observa as conexões TLS bidirecionais parando abruptamente, com apenas tráfego unidirecional restante e nenhum fluxo atingindo o estado estabelecido.
• Lê as métricas do firewall e percebe que os pacotes recebidos e passados mudam de uma AZ para a outra no momento da alteração.
• Chama DescribeRouteTables e encontra a rota de saída apontando para o endpoint do firewall em uma AZ enquanto a rota de retorno aponta para a outra.
• Busca no CloudTrail e identifica as chamadas ReplaceRoute e CreateRoute pelo mesmo usuário, cerca de um minuto antes dos dois alarmes.
• Reporta a causa raiz como a mudança de roteamento assimétrico e recomenda restaurar o roteamento simétrico na mesma AZ.

Atenção: o plano de mitigação é uma recomendação para você revisar, não uma mudança automática. A correção correta depende do design pretendido. O agente infere um destino plausível com base no que pode observar — revise a rota específica proposta em relação à sua topologia pretendida antes de aplicar.

Considerações adicionais

Em produção, uma única mudança pode disparar vários alarmes ao mesmo tempo, como o Cenário 3 demonstra. O DevOps Agent vincula investigações relacionadas e as trabalha como uma só, permitindo que você valide os achados ou desvincule um alarme para investigá-lo de forma independente. Também é possível adicionar lógica de correlação na função Lambda de ponte, agrupando alarmes por firewall antes que cheguem ao agente.

O agente pode trabalhar com mais contexto quando conectado a repositórios de código-fonte e pipelines de CI/CD, integrando-se com GitHub (incluindo GitHub Enterprise Server e GitLab Self-Managed via conexão privada). Ele pode associar recursos AWS a implantações de AWS CloudFormation, AWS CDK, imagens do Amazon Elastic Container Registry (Amazon ECR) e Terraform. Com configuração implantada e eventos recentes de deploy em mãos, o agente correlaciona a interrupção com a mudança que a introduziu e recomenda uma correção alinhada ao design pretendido.

O DevOps Agent também suporta prevenção proativa de incidentes: analisa padrões em investigações anteriores e entrega recomendações para evitar problemas similares, incluindo sugestões de governança que fortalecem processos de deploy e controles de pipeline. Para mudanças em regras do Network Firewall, isso significa que o agente pode recomendar guardrails para o pipeline de CI/CD com base nas classes de erros que já resolveu. Essas recomendações ficam acessíveis na página de Melhorias (Improvements) no Operator Web App do DevOps Agent.

O padrão descrito não é exclusivo do Network Firewall. O mesmo fluxo se aplica a qualquer serviço que emita métricas e logs no CloudWatch, como AWS WAF, security groups e listas de controle de acesso à rede (NACLs).

Limpeza do ambiente

Para remover todos os recursos implantados, basta executar:

bash scripts/destroy.sh

O script reverte qualquer cenário ativo, executa cdk destroy para todas as stacks e busca recursos remanescentes pela tag Project = nf-devops-agent. Os principais geradores de custo são os dois endpoints do Network Firewall, os gateways NAT e os load balancers do endpoint de teste — todos cobrados por hora enquanto provisionados, independentemente de haver tráfego. Executar os cenários e destruir a stack no mesmo dia limita o custo a poucas horas ativas.

Conclusão

A AWS demonstrou como o DevOps Agent acelera o troubleshooting de três problemas comuns de conectividade no Network Firewall: lista de negação de domínio, inversão de prioridade stateless e descarte por roteamento assimétrico entre AZs. Em cada caso, o agente investigou a queda e retornou uma causa raiz com um plano de mitigação para aprovação antes da aplicação.

O primeiro cenário disparou com base em uma métrica nativa do Network Firewall; os outros dois, com base em métricas de saúde da aplicação — mostrando as duas formas de alarmar sobre um problema de firewall pelo mesmo pipeline.

Para explorar a solução, clone o repositório de exemplo e aplique o que aprender ao seu próprio firewall, aplicação e alarmes. Para mais detalhes, consulte o Guia do Desenvolvedor do AWS Network Firewall e a página de preços do AWS Network Firewall. Para começar, acesse o guia de introdução ao AWS DevOps Agent para conectar seu primeiro webhook.

Fonte

Accelerating AWS Network Firewall troubleshooting with AWS DevOps Agent (https://aws.amazon.com/blogs/security/accelerating-aws-network-firewall-troubleshooting-with-aws-devops-agent/)