O problema que motivou a novidade
Quem gerencia firewalls em ambientes corporativos sabe bem como conjuntos de regras crescem com o tempo. Novas regras são adicionadas para atender a requisitos de segurança, auditorias ou incidentes pontuais — e poucas são removidas. O resultado é um conjunto de regras cada vez mais extenso, com muitas entradas que podem nunca ser acionadas na prática.
Até então, a única forma de descobrir quais regras do AWS Network Firewall estavam realmente correspondendo ao tráfego era analisar logs manualmente. Isso cria dois problemas sérios: operacional e de conformidade. Do ponto de vista operacional, equipes não conseguem identificar regras dormentes que consomem capacidade sem servir a nenhum propósito. Do ponto de vista de conformidade, frameworks como o Padrão de Segurança de Dados da Indústria de Cartões de Pagamento (PCI) 4.0 e a Lei de Resiliência Operacional Digital (DORA) exigem evidências de que controles específicos estão ativamente funcionando — e sem dados de ativação de regras, essa evidência simplesmente não existe.
Para resolver esse cenário, a AWS anunciou o suporte a rule hit count (contagem de hits por regra) no Network Firewall, uma funcionalidade que entrega exatamente essa visibilidade de forma nativa e automática.
Como funciona o rule hit count
O rule hit count registra quantas vezes cada regra stateful corresponde ao tráfego de rede. O contador é incrementado sempre que uma regra gera um log de alerta — ou seja, regras com ações de alert, drop ou reject são contabilizadas automaticamente, pois essas ações produzem logs de alerta por padrão.
Regras configuradas com a ação pass, por outro lado, não geram logs de alerta por padrão e, portanto, não aparecem na métrica de hit count. Para incluir esse tipo de regra na contagem, basta adicionar a palavra-chave alert dentro da própria regra de pass. Isso faz com que o tráfego continue sendo permitido normalmente, mas um log de alerta também seja gerado, tornando a regra visível na métrica. O exemplo abaixo, em sintaxe Suricata, ilustra esse padrão:
pass tls $HOME_NET any -> $EXTERNAL_NET 443 (msg:"Pass and Log HTTPS traffic"; alert; sid:1000001; rev:1;)Essa regra permite o tráfego HTTPS ao destino pretendido e, ao mesmo tempo, gera um log de alerta para que a regra apareça no hit count.
Metadados adicionados nos logs de alerta
A funcionalidade também enriquece cada log de alerta com um bloco de metadados que identifica o grupo de regras responsável pelo match. Esse enriquecimento é automático e não requer configuração adicional:
"aws_metadata": {
"resource_arn": "arn:aws:network-firewall:us-east-1:123456789012:stateful-rulegroup/StatefulRuleGroup"
}Para ilustrar como esse metadado aparece em um log completo, veja o exemplo abaixo:
{
"firewall_name": "egress-and-east-west-firewall",
"availability_zone": "us-east-1a",
"event_timestamp": "1786112515",
"event": {
"tx_guessed": true,
"aws_category": "",
"tx_id": 0,
"app_proto": "http",
"ip_v": 4,
"src_ip": "10.2.1.205",
"src_port": 46240,
"event_type": "alert",
"alert": {
"severity": 3,
"signature_id": 10000003,
"rev": 0,
"signature": "Egress HTTP but not port TCP/80",
"action": "blocked",
"category": ""
},
"ts_progress": "request_complete",
"flow_id": 927132830538451,
"dest_ip": "3.226.253.175",
"proto": "TCP",
"verdict": {
"action": "drop"
},
"http": {
"hostname": "3.226.253.175",
"http_port": 4444,
"url": "/",
"http_user_agent": "curl/8.17.0",
"http_method": "GET",
"protocol": "HTTP/1.1",
"length": 0
},
"tc_progress": "response_started",
"dest_port": 4444,
"pkt_src": "geneve encapsulation",
"aws_metadata": {
"resource_arn": "arn:aws:network-firewall:us-east-1:123456789012:stateful-rulegroup/StatefulRuleGroup"
},
"timestamp": "2026-08-07T14:21:55.611810+0000",
"direction": "to_server"
}
}O Network Firewall envia esses logs de alerta para o Amazon CloudWatch Logs ou para o Amazon Simple Storage Service (Amazon S3). Para identificar qual regra específica gerou um alerta, basta combinar os campos sid (identificador de assinatura) e resource_arn na consulta. O dashboard de monitoramento do firewall usa exatamente esses campos para calcular e exibir os hit counts por regra, dispensando a necessidade de consultar os logs diretamente. Mas caso prefira análise customizada, é possível usar o CloudWatch Logs Insights para logs armazenados no CloudWatch, ou o Amazon Athena para logs no S3.
Como começar a usar
O rule hit count já vem habilitado por padrão no Network Firewall — não é necessária nenhuma configuração adicional. Assim que as regras do firewall estão em operação, o rastreamento de hits começa automaticamente.
Pré-requisitos
Para aproveitar o recurso, alguns pontos precisam estar configurados:
- Firewall existente: É necessário ter um Network Firewall configurado para inspecionar tráfego de uma Amazon Virtual Private Cloud (Amazon VPC). Se ainda não tiver um, o guia de introdução ao AWS Network Firewall é o ponto de partida recomendado.
- Entrega de logs de alerta configurada: O firewall precisa ter o log de alertas habilitado. Os metadados de hit count são capturados independentemente do destino dos logs, mas o dashboard nativo exige que os logs sejam enviados ao CloudWatch Logs ou ao Amazon S3.
- Monitoramento detalhado habilitado: Para visualizar o painel de Top Rule Hits no console, é necessário habilitar o monitoramento detalhado nas configurações de log do firewall ou pela aba de Monitoramento no Console de Gerenciamento da AWS. Se você tiver uma solução de dashboard própria, os metadados necessários já estão presentes nos logs automaticamente — independentemente de o monitoramento detalhado estar ativo ou não.
- Regras pass com a palavra-chave alert: Regras com ação
passnão geram logs de alerta por padrão. Para que apareçam na métrica de hit count, inclua a palavra-chavealertnessas regras, conforme demonstrado anteriormente.
Visualizando os dados no console
Para acessar as métricas de hit count, abra o console do Network Firewall, selecione o firewall desejado e navegue até a seção Monitoring and observability. Em Top analysis, o painel Top Rule Hits exibe as regras stateful mais acionadas. É possível selecionar um período de lookback para filtrar a atividade dentro de um intervalo de tempo específico.
O painel apresenta colunas para contagem de hits (com gráfico de barras e fração), percentual do total de hits, Resource ARN (Nome de Recurso da Amazon), Signature ID (identificador de assinatura), descrição da regra (campo msg da regra Suricata) e última ocorrência em UTC.
Vale notar que os IDs de assinatura 2, 4, 6 e 8 são assinaturas geradas automaticamente pelo sistema, correspondentes às ações padrão da política de firewall em modo de ordem estrita. Como essas assinaturas têm origem na política — e não em um grupo de regras —, o campo resource_arn exibe o ARN da política de firewall em vez do ARN de um grupo de regras. Elas aparecem no Top Rule Hits quando a política tem ações padrão como Drop established, Alert established ou suas variantes de camada de aplicação configuradas. Essas assinaturas disparam em pacotes de conexão estabelecida que não correspondem a nenhuma regra explícita, aplicando a postura de negação padrão da política.
Casos de uso práticos
Identificando regras inativas
Qualquer regra cujo Signature ID não apareça no painel de Top Rule Hits durante o período selecionado não correspondeu a nenhum tráfego naquele intervalo. Isso indica que a regra pode estar obsoleta ou posicionada incorretamente dentro do grupo de regras.
Acelerando a resposta a incidentes
Filtrando o painel pelo período de um incidente suspeito, a equipe consegue identificar rapidamente quais regras foram acionadas naquele intervalo — sem precisar percorrer manualmente milhares de entradas de log. Por exemplo: uma regra com a descrição traffic_to_oast [oast[.]fun] com seis hits pode indicar que um atacante está tentando exfiltrar dados ou validar uma vulnerabilidade no ambiente.
Validando regras recém-adicionadas
Após adicionar uma nova regra para monitorar ou restringir tráfego — como uma regra de geofencing para bloquear conexões a países fora dos Estados Unidos, ou uma regra para categorizar tráfego a domínios de Inteligência Artificial e Aprendizado de Máquina (IA/ML) —, o hit count confirma se a regra está sendo acionada conforme esperado. Isso fornece evidência concreta de que os controles implantados estão funcionando.
Preços
O rule hit count está incluído no Network Firewall sem custo adicional. No entanto, as tarifas padrão se aplicam ao armazenamento e à consulta dos dados de log. Se os logs forem enviados ao CloudWatch Logs, aplicam-se os preços do CloudWatch. Se forem armazenados no Amazon S3 e consultados via Athena, aplicam-se as tarifas padrão de armazenamento do S3 e de consulta do Athena. Para detalhes completos, consulte a página de preços do AWS Network Firewall.
Considerações importantes
- Para gerenciar custos, revise a utilização dos logs e configure políticas de filtragem ou retenção.
- O rule hit count se aplica apenas a regras stateful. Regras stateless não suportam rastreamento de hit count no momento.
- O recurso está disponível em todas as regiões AWS onde o Network Firewall é suportado, exceto Oriente Médio (Emirados Árabes Unidos) e Oriente Médio (Bahrein).
Conclusão
O rule hit count é uma adição relevante para equipes que precisam de mais visibilidade sobre a efetividade das suas políticas de firewall. A funcionalidade resolve um problema concreto e recorrente: saber quais regras realmente fazem alguma coisa. Com ela, é possível limpar conjuntos de regras obsoletos, demonstrar conformidade com evidências reais e reagir mais rápido durante investigações de segurança.
Para mais informações sobre o serviço, consulte a documentação do AWS Network Firewall.
Fonte
AWS Network Firewall now supports rule hit count (https://aws.amazon.com/blogs/security/aws-network-firewall-now-supports-rule-hit-count/)
Leave a Reply