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
Padrõ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.
Armazenamento e investigação
Os logs de ALB e CloudFront costumam ser entregues a um bucket S3. Defina retenção e use consultas para análise sob demanda, em vez de tentar acompanhar tudo em tempo real. Em uma investigação, esses logs ajudam a reconstruir a sequência de requisições de um atacante e a entender qual rota foi explorada, complementando a visão de identidade e de rede.
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 web
- 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
- Direcione o volume para armazenamento econômico
- 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.
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.
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.