Logs de ALB e CloudFront: como analisar tráfego web com foco em segurança
Os logs de borda contam a história de cada requisição. Veja como lê-los para detectar abuso e investigar ataques web.
Aplicações web recebem tráfego automatizado o tempo todo, e a maior parte dele só fica visível nos logs de borda. Os logs do Application Load Balancer e do CloudFront registram cada requisição que chegou: IP de origem, status de resposta, URI, user agent, tempo de processamento e mais. Analisados com olhar de segurança, eles revelam força bruta, scraping, varredura de caminhos e anomalias que indicam abuso.
Este guia mostra como usar esses logs de forma defensiva para detecção e investigação. O foco é entender quais campos importam, que padrões procurar e como ligar essa análise ao WAF e à postura de segurança da aplicação.
Campos que contam a história
O status code é um dos sinais mais ricos. Muitos 401 e 403 concentrados em um endpoint de login sugerem força bruta ou credential stuffing. Uma sequência de 404 variando o caminho indica varredura procurando arquivos e rotas. Picos de 5xx podem revelar tanto problema operacional quanto tentativa de abuso. O IP de origem, o user agent e o URI completam o quadro.
- Status code: 401 e 403 em login indicam tentativa de acesso
- Sequência de 404 variando caminho indica varredura
- User agent ausente ou genérico sugere automação
- URI revela quais rotas estão sendo sondadas
- Volume por IP em janela curta indica abuso ou scraping
Combine campos antes de concluir
Nenhum campo isolado prova abuso. O valor aparece no cruzamento: um mesmo IP que gera muitos 401 em /login, com user agent genérico e sem carregar recursos estáticos, tem cara de automação. Já um IP com muitos acessos, mas user agents variados e navegação que busca CSS, imagens e scripts, costuma ser um gateway corporativo com vários usuários reais atrás dele.
time 2026-07-20T14:03:11Z
client_ip 203.0.113.45
request "POST https://app.exemplo/login HTTP/2.0"
elb_status_code 401
user_agent "python-requests/2.31"
target_processing_time 0.004Padrões de abuso e correlação com WAF
Cruze os logs de borda com os logs do WAF para entender o que foi bloqueado e o que passou. Se o WAF bloqueia muito de um padrão, mas algo semelhante passa com status de sucesso, há uma lacuna de regra a ajustar. User agents incomuns, ausência de cabeçalhos esperados e rajadas de requisições de um mesmo IP ou faixa são indícios de bots e scraping.
Atenção a IPs compartilhados: muitos usuários legítimos saem por um mesmo endereço corporativo. Volume alto de um IP nem sempre é ataque; combine sinais, como o padrão de URIs e a taxa de erro, antes de concluir que é abuso.
Consultas de investigação sobre os logs
Com os logs em um bucket S3, o Athena permite consultar sob demanda sem manter infraestrutura de análise ligada o tempo todo. Padronize algumas consultas antes do incidente, para não ter que escrevê-las sob pressão. A primeira que costuma render é a concentração de respostas de acesso negado por IP em endpoints de autenticação.
SELECT client_ip, count(*) AS tentativas
FROM alb_logs
WHERE elb_status_code IN (401, 403)
AND request LIKE '%/login%'
AND time >= '2026-07-01'
GROUP BY client_ip
ORDER BY tentativas DESC
LIMIT 20;A segunda revela varredura: um único IP que gera muitos 404 tocando caminhos distintos está mapeando rotas e arquivos, e não navegando de verdade. Ajuste o limiar ao seu tráfego, porque aplicações grandes geram 404 legítimos.
SELECT client_ip, count(DISTINCT request) AS caminhos_404
FROM alb_logs
WHERE elb_status_code = 404
GROUP BY client_ip
HAVING count(DISTINCT request) > 50
ORDER BY caminhos_404 DESC;Armazenamento, particionamento e detecção contínua
Os logs de ALB e CloudFront são entregues a um bucket S3, e o volume cresce rápido em aplicações movimentadas. Particione por data no layout das chaves, para que uma consulta de investigação leia apenas o período relevante em vez de varrer todo o histórico, o que reduz custo e tempo de resposta. Defina uma política de ciclo de vida que mova o histórico antigo para armazenamento mais barato e expire o que passou da janela de retenção.
Da consulta manual ao alerta
Consulta sob demanda serve para investigar depois do fato; detecção exige que alguns sinais gerem alerta sozinhos. Uma opção é encaminhar métricas de status para o CloudWatch e alertar sobre picos de 401 e 403 ou de 5xx. Outra é agendar consultas periódicas no Athena para os padrões que você já sabe procurar. O objetivo é reduzir o tempo entre o abuso acontecer e alguém perceber, sem depender de olhar o painel por acaso.
Em uma investigação, esses logs reconstroem a sequência de requisições de um atacante e mostram qual rota foi sondada, complementando a visão de identidade no CloudTrail e a de rede nos VPC Flow Logs.
Checklist prático
- Habilitar logs de acesso do ALB e do CloudFront
- Entregar os logs a um bucket com retenção definida
- Analisar concentração de 401 e 403 em endpoints de login
- Detectar varredura por sequências de 404 variando caminho
- Identificar bots por user agent e padrão de requisição
- Cruzar com logs de WAF para achar lacunas de regra
- Considerar IPs compartilhados antes de concluir abuso
- Investigar picos de 5xx para separar erro de abuso
- Padronizar consultas de investigação no Athena antes do incidente
- Particionar os logs por data para acelerar e baratear consultas
- Mover histórico antigo para armazenamento mais barato via ciclo de vida
- Alertar sobre picos de 401, 403 e 5xx, não só consultar sob demanda
- Correlacionar com identidade e rede no incidente
Boas práticas
- Use status code como sinal primário de abuso
- Combine IP, user agent e URI antes de concluir
- Correlacione borda e WAF para ajustar regras
- Trate IPs corporativos compartilhados com cautela
- Particione os logs por data para consultas rápidas
- Transforme os padrões conhecidos em alerta, não só consulta
- Prepare consultas de investigação antes do incidente
Erros comuns
Não habilitar logs de borda
A maior parte do tráfego automatizado e do abuso fica invisível.
Consultar o histórico inteiro sem particionar
A investigação fica lenta e cara, o que desestimula a análise.
Concluir abuso só pelo volume de um IP
Risco de bloquear muitos usuários legítimos atrás de um gateway.
Ignorar a correlação com o WAF
Lacunas de regra permanecem, com ataques passando pela borda.
Sem retenção dos logs
A reconstrução do ataque fica impossível depois de poucos dias.
Olhar apenas 2xx e ignorar 4xx e 5xx
Sinais de varredura e abuso, concentrados nos erros, passam despercebidos.
Quando procurar apoio especializado
Transformar logs de borda em detecção e tuning de WAF é parte dos serviços de WAF e Proteção de Borda e de Monitoramento e Resposta da GUARDIASEC, que ajustam regras e definem casos de uso de detecção web.
Perguntas frequentes
Quais status codes mais indicam ataque?
Concentração de 401 e 403 em endpoints de login sugere força bruta ou credential stuffing. Sequências de 404 variando o caminho indicam varredura de rotas e arquivos. Picos de 5xx podem ser abuso ou problema operacional. Nenhum sinal isolado é conclusivo; o valor está em cruzar status code com IP, URI e user agent.
Logs de borda substituem o WAF?
Não. O WAF age bloqueando tráfego, enquanto os logs de borda mostram o que aconteceu, incluindo o que passou. Eles se complementam: os logs ajudam a identificar lacunas nas regras do WAF e a investigar ataques que não foram bloqueados. Juntos, dão tanto a defesa ativa quanto a visibilidade para ajustá-la.
Como evito concluir que um IP é malicioso por engano?
Muitos usuários legítimos saem por um mesmo IP corporativo, então volume alto nem sempre é ataque. Combine sinais antes de concluir: o padrão de URIs acessados, a taxa de erro, o user agent e o comportamento ao longo do tempo. Decisões de bloqueio baseadas só em volume de IP costumam afetar usuários reais.
Onde esses logs são armazenados?
Tanto o ALB quanto o CloudFront costumam entregar logs de acesso a um bucket S3. A partir daí, você define retenção e usa consultas para análise sob demanda. Como o volume pode ser grande, direcione para armazenamento econômico e foque a análise em janelas e padrões específicos durante uma investigação.
Como consulto esses logs sem montar muita infraestrutura?
O Athena consulta os arquivos direto no bucket S3 usando SQL, sem precisar carregar os dados em outro lugar. Você define uma tabela apontando para o caminho dos logs, de preferência particionada por data, e roda consultas sob demanda. É o caminho de menor atrito para investigar concentração de erros por IP, varredura por 404 e user agents suspeitos, pagando apenas pelo que cada consulta lê.
Como diferencio um scraper de um buscador legítimo?
Buscadores conhecidos se identificam por user agent e costumam respeitar o robots. Um scraper abusivo tende a variar o user agent ou usar um genérico, ignorar recursos estáticos, percorrer muitas rotas em ritmo alto e vir de faixas de IP incomuns para o seu público. Nenhum sinal isolado basta: combine o padrão de URIs, a taxa de requisições e o user agent antes de decidir bloquear.
Por que particionar os logs por data?
Sem particionamento, cada consulta varre todo o histórico do bucket, o que fica lento e caro conforme o volume cresce. Particionar por ano, mês e dia permite que uma consulta de investigação leia apenas o período que interessa, reduzindo o custo e o tempo de resposta. Isso torna a análise viável no dia a dia, e não só em uma investigação pontual.
Guias relacionados
Próximo passo
Vamos avaliar os riscos do seu ambiente?
Conte seu cenário e definimos juntos o escopo certo. O objetivo é reduzir caminhos prováveis de ataque e elevar a maturidade de segurança, sem promessas absolutas.