VPC Flow Logs: como usar logs de rede para investigação e visibilidade
Sem logs de rede, movimento lateral e exfiltração passam invisíveis. Veja como capturar e usar VPC Flow Logs.
Logs de identidade respondem quem fez o quê, mas não mostram como o tráfego se moveu pela rede. Os VPC Flow Logs preenchem essa lacuna, registrando metadados das conexões dentro da VPC: origem, destino, portas, protocolo e se o tráfego foi aceito ou rejeitado. Em uma investigação, eles são essenciais para detectar movimento lateral, varreduras internas e exfiltração de dados.
Este guia mostra como capturar e usar VPC Flow Logs de forma defensiva, entendendo o que eles registram, como escolher o formato de captura, suas limitações e como consultá-los e correlacioná-los com outras fontes. O objetivo é ganhar visibilidade de rede sem se afogar em volume.
O que os Flow Logs registram
Os Flow Logs capturam metadados de fluxo por interface de rede, sub-rede ou VPC inteira. Cada registro indica IPs de origem e destino, portas, protocolo, bytes e a ação, aceito ou rejeitado. Tráfego rejeitado é especialmente interessante: uma rajada de conexões rejeitadas pode indicar varredura, enquanto conexões aceitas inesperadas entre cargas que não deveriam se comunicar sugerem movimento lateral.
É importante saber o que eles não capturam: Flow Logs registram metadados, não o conteúdo dos pacotes. Eles dizem que houve uma conexão, mas não o que trafegou dentro dela. Para conteúdo, são necessárias outras abordagens, como inspeção em camada de aplicação.
Formato customizado e campos que importam
O formato padrão dos Flow Logs cobre o básico, mas o formato customizado adiciona campos que mudam muito o valor da investigação. Vale incluir campos que revelam direção do tráfego, endereços reais por trás de tradução de rede e flags de conexão. Definir o formato certo antes do incidente evita descobrir, no meio da análise, que o dado necessário não foi capturado.
action # ACCEPT ou REJECT
flow-direction # ingress ou egress
pkt-srcaddr # IP de origem real, antes de NAT
pkt-dstaddr # IP de destino real, antes de NAT
tcp-flags # flags da conexão TCP
traffic-path # caminho do tráfego de saídaOs campos pkt-srcaddr e pkt-dstaddr importam porque, quando o tráfego passa por NAT ou por um balanceador, os campos de endereço tradicionais mostram o intermediário, não a ponta real. Os campos de pacote revelam quem de fato originou ou recebeu a conexão. O flow-direction separa entrada de saída, o que ajuda a focar exfiltração, e o tcp-flags ajuda a distinguir varredura de conexão estabelecida.
Investigar e correlacionar
Os Flow Logs ganham força quando correlacionados. Combine-os com o CloudTrail para ligar uma atividade de rede a uma identidade que provisionou um recurso, e com os logs de aplicação para entender o contexto de negócio. Em um incidente, eles ajudam a mapear quais hosts um recurso comprometido tentou alcançar e se houve tráfego de saída anômalo, indício de exfiltração.
Consultas que se repetem
Se os Flow Logs vão para o CloudWatch Logs ou para o S3 com consulta por Athena, algumas perguntas aparecem sempre: quem gerou mais tráfego de saída, quais conexões foram rejeitadas e para quais portas, e quais pares de origem e destino trocaram mais bytes. Consultar bytes de saída agrupados por destino ajuda a flagrar exfiltração, enquanto contar rejeições por porta destaca varredura.
fields dstAddr, bytes
| filter action = "ACCEPT"
| stats sum(bytes) as total_saida by dstAddr
| sort total_saida desc
| limit 20- Investigar conexões rejeitadas para detectar varredura
- Procurar comunicação inesperada entre cargas (movimento lateral)
- Somar bytes de saída por destino para achar exfiltração
- Usar pkt-srcaddr para ver o IP real por trás de NAT e balanceador
- Correlacionar com CloudTrail e logs de aplicação
- Mapear o que um host comprometido tentou alcançar
Armazenamento, custo e foco
Flow Logs geram volume alto. Direcione-os para armazenamento econômico e use consultas para análise sob demanda, em vez de tentar olhar tudo o tempo todo. Enviar para o S3 costuma sair mais barato para retenção longa e análise por Athena; enviar para o CloudWatch Logs facilita consulta ágil e alertas. Muitos ambientes usam os dois caminhos conforme a necessidade.
Defina o escopo com critério: capturar a VPC inteira dá cobertura ampla, mas habilitar em sub-redes e interfaces sensíveis pode equilibrar visibilidade e custo. Ative pelo menos onde há cargas críticas e exposição. Vale lembrar que o registro agrega o fluxo por um intervalo, então os Flow Logs mostram padrões de conexão, não cada pacote isolado, e não capturam certo tráfego, como consultas ao servidor de metadados da instância.
Checklist prático
- Habilitar Flow Logs ao menos em VPCs e sub-redes críticas
- Capturar tráfego aceito e rejeitado
- Usar formato customizado com pkt-srcaddr, flow-direction e tcp-flags
- Direcionar para armazenamento econômico, com S3 para retenção longa
- Definir retenção compatível com investigação
- Investigar conexões rejeitadas como sinal de varredura
- Procurar comunicação inesperada entre cargas
- Somar bytes de saída por destino para achar exfiltração
- Correlacionar com CloudTrail e logs de aplicação
- Padronizar consultas de investigação de rede
- Equilibrar escopo de captura com custo
Boas práticas
- Use Flow Logs para visibilidade de rede que a identidade não dá
- Defina um formato customizado que capture os campos que importam
- Foque em rejeitados e em comunicação inesperada
- Use pkt-srcaddr para enxergar o IP real por trás de NAT
- Correlacione com outras fontes para contexto completo
- Direcione o volume para armazenamento de baixo custo
- Lembre que eles registram metadados agregados, não conteúdo
Erros comuns
Não habilitar Flow Logs em nenhuma rede
Movimento lateral e exfiltração ficam invisíveis na investigação.
Usar só o formato padrão sem campos de pacote
Você vê o endereço do NAT ou do balanceador, não o IP real da ponta.
Capturar tudo sem estratégia de custo
Volume e custo altos sem ganho proporcional de visibilidade.
Esperar conteúdo de pacote nos Flow Logs
Expectativa errada: eles registram metadados agregados, não o conteúdo.
Ignorar tráfego rejeitado
Sinais de varredura e enumeração interna passam despercebidos.
Flow Logs sem correlação com outras fontes
Visão de rede isolada, sem ligar atividade a identidade e contexto.
Quando procurar apoio especializado
Definir o que capturar na rede e como correlacionar com identidade e aplicação é parte do serviço de Monitoramento e Resposta da GUARDIASEC, que estrutura visibilidade e investigação adaptadas ao seu ambiente.
Perguntas frequentes
VPC Flow Logs capturam o conteúdo das conexões?
Não. Eles registram metadados de fluxo: IPs de origem e destino, portas, protocolo, bytes e se o tráfego foi aceito ou rejeitado. Eles dizem que houve uma conexão e entre quem, mas não o que trafegou. Para inspecionar conteúdo, são necessárias outras abordagens, em camadas diferentes.
Qual a diferença entre o formato padrão e o customizado?
O formato padrão traz os campos básicos de fluxo. O formato customizado permite escolher campos adicionais que mudam bastante a investigação, como flow-direction, tcp-flags e, principalmente, pkt-srcaddr e pkt-dstaddr. Como você define o formato ao criar o Flow Log, vale planejar os campos antes, para não descobrir no meio de um incidente que o dado necessário não foi capturado.
Por que os campos pkt-srcaddr e pkt-dstaddr importam?
Quando o tráfego passa por NAT ou por um balanceador de carga, os campos de endereço tradicionais mostram o intermediário, não a ponta real da conexão. Os campos pkt-srcaddr e pkt-dstaddr revelam o IP de origem e destino reais, antes da tradução. Sem eles, uma investigação pode atribuir a atividade ao gateway em vez do host que de fato originou ou recebeu a conexão.
Por que o tráfego rejeitado é tão útil?
Porque conexões rejeitadas costumam revelar comportamento suspeito. Uma rajada de tentativas rejeitadas pode indicar varredura de portas, e padrões de rejeição entre cargas internas ajudam a mapear tentativas de movimento lateral. Analisar o que foi bloqueado, e não só o que passou, enriquece bastante a investigação de rede.
Envio os Flow Logs para o S3 ou para o CloudWatch Logs?
Depende do uso. O S3 costuma ser mais econômico para retenção longa e para análise por Athena em grandes volumes. O CloudWatch Logs facilita consulta ágil com o Logs Insights e a criação de alertas. Muitos ambientes usam os dois: S3 para o histórico e a análise pesada, CloudWatch para investigação rápida das redes mais críticas.
Devo habilitar Flow Logs na VPC inteira?
Capturar a VPC inteira dá cobertura ampla, mas gera volume e custo altos. Uma estratégia equilibrada é habilitar pelo menos onde há cargas críticas e exposição, e expandir conforme a necessidade. O importante é ter visibilidade nas redes que mais importam, direcionando os logs para armazenamento econômico.
Como os Flow Logs ajudam em um incidente?
Eles permitem mapear quais hosts um recurso comprometido tentou alcançar, identificar tráfego de saída anômalo que sugere exfiltração e detectar comunicação inesperada entre cargas. Correlacionados com o CloudTrail e os logs de aplicação, ajudam a reconstruir como o ataque se moveu pela rede, não apenas quem agiu.
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.