O problema que esse recurso resolve
Manter listas de domínios bloqueados e permitidos é um trabalho sem fim. Novos sites e serviços surgem todos os dias, e qualquer lacuna na atualização manual dessas listas representa uma brecha de segurança. O desafio se intensifica quando o assunto é controlar o acesso a categorias em rápida evolução — como serviços de Inteligência Artificial (IA), onde novas ferramentas aparecem com frequência.
Para endereçar esse problema, a AWS expandiu as capacidades do AWS Network Firewall com suporte a filtragem por categoria de URL e domínio. Em vez de gerenciar domínios individualmente, as equipes de segurança passam a trabalhar com categorias predefinidas e mantidas automaticamente pela própria AWS. Quando um novo domínio é registrado e se enquadra em uma categoria, ele já entra automaticamente no escopo das regras — sem nenhuma intervenção manual.
Como funciona a filtragem por categoria
O AWS Network Firewall é um serviço gerenciado de firewall de rede com estado (stateful) e detecção e prevenção de intrusões para controle granular do tráfego da sua Nuvem Privada Virtual (VPC). Com a filtragem por categoria, você escolhe de uma lista de categorias gerenciadas pela AWS — como Redes Sociais, Jogos de Azar ou Inteligência Artificial e Aprendizado de Máquina — e aplica políticas de acesso a elas de forma centralizada.
O serviço oferece dois modos de filtragem por categoria:
- Domain category (categoria de domínio): filtra pelo nome do domínio usando o campo Indicação de Nome do Servidor (SNI) do TLS, sem necessidade de descriptografia.
- URL category (categoria de URL): filtra pelo caminho completo da URL, o que exige inspeção TLS para tráfego HTTPS. Para configurar esse modo, consulte a documentação sobre criação de configuração de inspeção TLS no Network Firewall.
O foco deste guia é a filtragem por categoria de domínio, por ser mais direta de configurar.
Pré-requisitos
Antes de começar, é necessário ter um deployment do Network Firewall já em funcionamento para filtrar o tráfego de saída da sua Amazon VPC. Caso ainda não use o serviço, a AWS disponibiliza um guia de introdução ao AWS Network Firewall.
Outro ponto importante é configurar corretamente a variável $HOME_NET no nível da política do firewall. As regras usam essa variável para delimitar o escopo do tráfego à sua rede interna. A recomendação da AWS é definir $HOME_NET com os intervalos de endereços IP privados RFC 1918: 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16. O Network Firewall mapeia automaticamente a variável $EXTERNAL_NET como o inverso de $HOME_NET, então configurar uma resolve as duas.
Criando uma regra de categoria pelo console
Para começar rapidamente, é possível usar o construtor de regras do Console de Gerenciamento da AWS. O exemplo abaixo cria uma regra de alerta para a categoria de Inteligência Artificial e Aprendizado de Máquina:
- Acesse o console do Amazon VPC, navegue até Network Firewall > Rule groups e clique em Create rule group.
- Selecione Stateful rule group, formato Standard stateful rules e ordem de avaliação Strict order.
- Defina o nome como
Domain-Category-Rules, a descrição como Domain Category Rules e a capacidade como 50.
- No editor de regras, selecione o botão Category Matching e escolha Match all selected categories.
- Em AWS category type, selecione Domain Category. Em Categories, escolha Artificial Intelligence and Machine Learning.
- Defina o protocolo como TLS, a origem como Custom com o valor
$HOME_NET, o destino como Any e a ação como Alert.
- Clique em Add rule e, em seguida, em Create rule group.
Essa regra gera uma entrada de log de alerta sempre que uma conexão corresponder a um domínio da categoria de IA e ML. Ela não bloqueia o tráfego — para isso, basta alterar a ação para Drop ou Reject.
Criando a mesma regra com strings Suricata
O construtor de regras do console é prático para começar, mas a AWS recomenda o uso de strings de regras compatíveis com Suricata em ambientes de produção. As regras Suricata oferecem controle total sobre as opções de regra, são fáceis de copiar, editar, compartilhar e fazer backup, e suportam a maioria das capacidades do motor Suricata. Para mais detalhes, consulte as limitações e ressalvas para regras stateful no AWS Network Firewall.
Para criar o mesmo grupo de regras usando Suricata:
- Acesse Network Firewall > Network Firewall rule groups e clique em Create rule group.
- Selecione Stateful rule group, formato Suricata compatible rule string e ordem Strict order.
- Defina o nome como
Suricata-Domain-Category-Rules, a descrição como Suricata Domain Category Rules e a capacidade como 50.
- Deixe as seções de variáveis de regra e referências de conjunto de IPs vazias — a variável
$HOME_NET é herdada da política do firewall.
- Cole a seguinte regra no editor:
alert tls $HOME_NET any -> $EXTERNAL_NET any (msg:"Artificial Intelligence and Machine Learning Category"; aws_domain_category:Artificial Intelligence and Machine Learning; sid:1000001;)
A tabela abaixo explica cada componente dessa regra:
alert: ação — gera uma entrada de alerta no log quando a regra corresponder. Outras ações possíveis: pass, drop e reject.tls: protocolo — inspeciona tráfego TLS, correspondendo ao campo SNI no TLS Client Hello.$HOME_NET any -> $EXTERNAL_NET any: origem e destino — corresponde ao tráfego de qualquer IP interno para qualquer IP externo, em qualquer porta.msg:"...": mensagem gravada no log de alerta quando a regra é acionada.aws_domain_category:...: categoria de domínio gerenciada pela AWS a ser verificada. O firewall consulta o banco de dados de categorias e corresponde se o domínio de destino pertencer à categoria.sid:1000001: identificador único da assinatura. Cada regra em um grupo deve ter um SID único.
Após criar o grupo de regras, retorne à política do firewall e associe-o em Stateful rule groups. A recomendação é sempre associar novos grupos de regras primeiro em um ambiente de desenvolvimento ou teste antes de levar para produção.
Gerenciando exceções para serviços aprovados
É possível criar exceções para manter sites críticos para o negócio acessíveis. Por exemplo, para permitir o acesso ao OpenAI enquanto bloqueia todo o restante do tráfego de IA e ML, basta substituir a regra básica pelo seguinte conjunto de regras no grupo Suricata-Domain-Category-Rules:
# Allow OpenAI (TLS)
pass tls $HOME_NET any -> $EXTERNAL_NET any (tls.sni; dotprefix; content:".openai.com"; nocase; endswith; flow:to_server; alert; msg:"Allow OpenAI over TLS"; sid:1000001;)
# Allow OpenAI (HTTP)
pass http $HOME_NET any -> $EXTERNAL_NET any (http.host; dotprefix; content:".openai.com"; nocase; endswith; flow:to_server; alert; msg:"Allow OpenAI over HTTP"; sid:1000002;)
# Block all other AI/ML category traffic (TLS)
reject tls $HOME_NET any -> $EXTERNAL_NET any (msg:"Block non-approved AI/ML sites over TLS"; aws_domain_category:Artificial Intelligence and Machine Learning; flow:to_server; alert; sid:1000003;)
# Block all other AI/ML category traffic (HTTP)
reject http $HOME_NET any -> $EXTERNAL_NET any (msg:"Block non-approved AI/ML sites over HTTP"; aws_url_category:Artificial Intelligence and Machine Learning; flow:to_server; alert; sid:1000004;)
Com a avaliação em ordem estrita (strict order), o firewall processa as regras na sequência em que foram definidas. As regras de pass para o OpenAI aparecem primeiro, então o tráfego correspondente é permitido antes que as regras de bloqueio da categoria mais ampla sejam avaliadas.
Para verificar se as regras estão funcionando como esperado, é possível testar a partir de um host que roteia o tráfego pelo firewall. Os comandos abaixo suprimem o corpo da resposta e verificam o código de saída da requisição curl. Se o curl completar uma conexão TCP, exibe CONNECTION ALLOWED; se o firewall resetar a conexão, exibe CONNECTION BLOCKED:
curl -s -o /dev/null https://openai.com && echo "CONNECTION ALLOWED" || echo "CONNECTION BLOCKED"
Resultado esperado: CONNECTION ALLOWED
curl -s -o /dev/null https://chat.mistral.ai && echo "CONNECTION ALLOWED" || echo "CONNECTION BLOCKED"
Resultado esperado: CONNECTION BLOCKED
Monitorando o uso por categoria
Quando uma regra de categoria de domínio é adicionada à política do firewall, o Network Firewall realiza uma consulta de categoria para cada conexão que corresponde ao protocolo e às especificações de IP da regra. As regras deste guia correspondem a $HOME_NET any -> $EXTERNAL_NET any, o que significa que o firewall consulta a categoria de todo o tráfego de saída originado da rede interna.
Cada entrada de log inclui um campo aws_category com um array JSON contendo todas as categorias às quais o domínio de destino pertence. Um único domínio pode pertencer a múltiplas categorias. Por exemplo, uma requisição para chat.mistral.ai gera uma entrada com "aws_category": "[\"Social Networking\",\"Artificial Intelligence and Machine Learning\"]".
Os logs do firewall podem ser acessados pelo Amazon CloudWatch, pelo Amazon S3 e pelo Amazon Data Firehose.
Abaixo está um exemplo de entrada de log para uma requisição bloqueada ao chat.mistral.ai:
{
"firewall_name": "egress-and-east-west-firewall",
"availability_zone": "us-east-1a",
"event_timestamp": "1775599146",
"event": {
"aws_category": "[\"Social Networking\",\"Artificial Intelligence and Machine Learning\"]",
"tx_id": 0,
"app_proto": "tls",
"src_ip": "10.1.1.100",
"src_port": 58664,
"event_type": "alert",
"alert": {
"severity": 3,
"signature_id": 1000003,
"rev": 1,
"signature": "Block non-approved AI/ML sites over TLS",
"action": "blocked",
"category": ""
},
"flow_id": 763153567844057,
"dest_ip": "172.66.2.203",
"proto": "TCP",
"verdict": {
"action": "drop",
"reject-target": "to_client",
"reject": [
"tcp-reset"
]
},
"tls": {
"sni": "chat.mistral.ai",
"version": "UNDETERMINED"
},
"dest_port": 443,
"pkt_src": "geneve encapsulation",
"timestamp": "2026-04-07T21:59:06.906761+0000",
"direction": "to_server"
}
}
O campo aws_category mostra que o domínio pertence às categorias “Social Networking” e “Artificial Intelligence and Machine Learning”. O campo verdict confirma que a conexão foi descartada com um reset TCP enviado ao cliente.
Consultando logs com o CloudWatch Logs Insights
Se os logs do firewall forem enviados para o Amazon CloudWatch Logs, é possível usar o CloudWatch Logs Insights para analisar padrões de tráfego por categoria. Como uma única conexão pode gerar múltiplas entradas de log, as queries abaixo deduplicam por flow_id para contar cada conexão apenas uma vez. Atenção: as consultas no CloudWatch Logs Insights geram cobranças com base na quantidade de dados varridos — consulte a página de preços do Amazon CloudWatch para detalhes.
Categorias mais acessadas
fields @timestamp, event.aws_category, event.flow_id
| filter ispresent(event.aws_category) and event.aws_category != "[]"
| stats latest(event.aws_category) as categories by event.flow_id
| stats count(*) as connections by categories
| sort connections desc
| limit 20
Categorias menos acessadas
fields @timestamp, event.aws_category, event.flow_id
| filter ispresent(event.aws_category) and event.aws_category != "[]"
| stats latest(event.aws_category) as categories by event.flow_id
| stats count(*) as connections by categories
| sort connections asc
| limit 20
Categorias mais acessadas — apenas tráfego permitido
fields @timestamp, event.aws_category, event.flow_id, event.verdict.action
| filter ispresent(event.aws_category) and event.aws_category != "[]"
| stats latest(event.aws_category) as categories, latest(event.verdict.action) as verdict by event.flow_id
| filter verdict = "alert"
| stats count(*) as connections by categories
| sort connections desc
| limit 20
Categorias mais acessadas — apenas tráfego bloqueado
fields @timestamp, event.aws_category, event.flow_id, event.verdict.action
| filter ispresent(event.aws_category) and event.aws_category != "[]"
| stats latest(event.aws_category) as categories, latest(event.verdict.action) as verdict by event.flow_id
| filter verdict = "drop"
| stats count(*) as connections by categories
| sort connections desc
| limit 20
Detalhamento por categoria específica
Esta query usa um filtro like para encontrar todo o tráfego onde o campo aws_category contém uma categoria específica, independentemente de quais outras categorias o domínio também pertença. Substitua o nome da categoria no filtro like para investigar qualquer outra categoria:
fields @timestamp, event.tls.sni, event.aws_category, event.verdict.action, event.flow_id
| filter ispresent(event.aws_category) and event.aws_category like /Artificial Intelligence and Machine Learning/
| stats latest(event.tls.sni) as sni, latest(event.verdict.action) as verdict by event.flow_id
| stats count(*) as connections by sni, verdict
| sort connections desc
| limit 20
Consumo de banda por categoria
Esta query mostra quais combinações de categorias consomem mais banda de saída. Ela correlaciona os logs de fluxo (que contêm contagens de bytes) com os logs de alerta (que contêm dados de categoria) usando o campo flow_id compartilhado. Para executar esta query, selecione tanto o grupo de logs de alerta quanto o de logs de fluxo no CloudWatch Logs Insights:
fields @timestamp
| filter ispresent(event.netflow.bytes) or ispresent(event.aws_category)
| stats sum(event.netflow.bytes) as flowBytes, latest(event.aws_category) as categories by event.flow_id
| filter ispresent(categories) and categories != "[]"
| stats sum(flowBytes) as totalBytes by categories
| sort totalBytes desc
| limit 20
Disponibilidade
O recurso de filtragem por categoria de URL e domínio está disponível em todas as regiões comerciais da AWS onde o AWS Network Firewall é suportado. Para saber mais, consulte a documentação do recurso.
Fonte
Simplifying policy management with URL and Domain Category filtering on AWS Network Firewall (https://aws.amazon.com/blogs/security/simplifying-policy-management-with-url-and-domain-category-filtering-on-aws-network-firewall/)