Os logs do Zeek são a telemetria de rede mais completa que um SOC pequeno consegue operar sem pagar licença: o sensor escuta o tráfego de forma passiva e transforma cada protocolo em um arquivo próprio — cada conexão TCP, UDP ou ICMP observada pelo sensor vira uma linha no conn.log, a atividade DNS vai para o dns.log e as requisições HTTP para o http.log. O caminho para usar isso na prática não é instalar mais nada: é aprender o que cada arquivo registra e em qual ordem consultá-lo durante uma triagem.
Este guia mostra como ler os três arquivos centrais, o que procurar em cada um durante uma investigação e como transformar os registros em alertas com um roteiro testável em laboratório. Todas as linhas de log usadas como exemplo aqui são sintéticas, criadas apenas para demonstrar o formato.
O que o Zeek registra
O Zeek é um analisador de tráfego de rede que, em vez de emitir apenas alertas, registra o que observa em arquivos de log estruturados, um para cada protocolo e atividade. A documentação oficial lista os arquivos gerados pela ferramenta com a descrição de cada tipo, e a leitura dessa lista já orienta por onde começar: toda a atividade DNS resolvida no ambiente aparece registrada no dns.log, as conexões de rede ficam no conn.log e as transações HTTP no http.log.
Para um time enxuto, alguns arquivos cobrem a maior parte das triagens de rede:
| Arquivo | O que registra | Sinal típico na triagem |
|---|---|---|
| conn.log | Conexões TCP, UDP e ICMP | Host falando com serviço incomum na rede |
| dns.log | Consultas e respostas DNS | Domínios longos gerados por algoritmo |
| http.log | Requisições e respostas HTTP | User-agent de ferramenta conhecida |
| ssl.log | Negociação TLS | Certificado autoassinado em servidor interno |
| smb_cmd.log | Comandos SMB | Cópia de arquivo entre hosts vizinhos |
Cada registro carrega um identificador único de conexão, o uid, que amarra linhas de protocolos diferentes da mesma sessão: a consulta HTTP e o handshake TLS que a antecede compartilham o uid da conexão registrada no conn.log. Esse vínculo permite reconstruir a história de uma comunicação sem manter captura completa de pacotes — o que economiza armazenamento, o custo que mais dói em retenção longa.
Como ler o conn.log
O conn.log é o mapa de quem falou com quem: origem e destino, portas, serviço identificado, duração, volume de bytes em cada direção e estado da conexão. Na triagem, três perguntas se respondem rápido com ele: qual host iniciou a conexão, para qual destino incomum ela aponta e em que horário o padrão fugiu da linha de base do ativo.
É também onde o movimento lateral aparece em escala antes de qualquer alerta corporativo: uma estação de trabalho que passa a abrir sessões SMB para dezenas de hosts vizinhos na mesma janela de tempo salta aos olhos numa simples ordenação por par origem-destino. Um beacon deixa rastro aqui igualmente — conexões curtas, de duração parecida, repetindo em intervalos regulares para o mesmo destino externo.
DNS e HTTP na triagem
O dns.log registra cada consulta e resposta: domínio consultado, tipo de registro, servidor que respondeu e código de retorno. É o arquivo onde o abuso do protocolo fica exposto. A matriz MITRE ATT&CK registra que adversários se comunicam pelo DNS justamente para se misturar ao tráfego existente e embutir comandos nas consultas, sem abrir conexões novas que chamariam atenção.
Três sinais merecem a consulta filtrada inicial: consultas TXT incomuns para domínios sem motivo operacional, nomes longos com alta entropia (típicos de tunneling, em que o dado viaja escondido dentro do rótulo do domínio) e domínios recém-registrados procurados por poucos hosts. Um registro sintético de laboratório mostra o formato, com dados fabricados apenas para demonstração:
1700000000.123456 CAbCdEfG 192.168.10.23 53291 8.8.4.4 53 udp 412 190 - - - - - dominio-exemplo-91j2.com 1.2.3.4 TXT IN NOERROR
O http.log, por sua vez, mantém método, URI, host, user-agent e código de resposta de cada transação em HTTP claro. O tráfego criptografado não aparece ali, mas deixa vizinhos: o ssl.log guarda o nome do servidor do handshake TLS e o resumo do certificado apresentado — suficiente para listar servidores internos com certificado autoassinado ou domínios incomuns sendo acessados por hosts sensíveis.
Do log ao alerta
Os arquivos sozinhos não alertam ninguém; a detecção começa quando alimentam uma consulta. O próprio Zeek tem uma camada de detecção: o notice.log concentra os avisos que os scripts carregados consideram relevantes, e o framework de assinaturas registra correspondências em arquivo próprio. Para o pipeline do SOC, o caminho usual é exportar os logs em JSON para o indexador ou SIEM da equipe e escrever as primeiras consultas de triagem sobre conn.log e dns.log, onde o volume compensa o esforço de escrita.
Uma ordem pragmatica de maturidade: primeiro consultas manuais respondendo perguntas de investigação, depois regras salvas que rodam na semana, e só então alertas automáticos para os padrões cujo falso positivo você já mediu.
Checklist de implantação
Um roteiro enxuto para validar o sensor antes de confiar nele, executável em laboratório com tráfego gerado por você:
- Posicione o sensor em um ponto que veja o tráfego de saída para a internet e o tráfego entre segmentos internos, por porta espelhada ou TAP.
- Gere tráfego sintético conhecido, como consultas DNS para domínios de teste e downloads controlados, e confirme que cada evento aparece no arquivo esperado.
- Calcule a linha de base de volume de conexões e consultas DNS por host em uma semana comum, para ter referência de comparação.
- Escreva três consultas de triagem: destinos nunca vistos por host, consultas TXT para domínios sem motivo e conexões internas host-a-host em portas administrativas.
- Revise os falsos positivos com o dono do ativo antes de transformar consulta em alerta automático.
Nenhuma dessas consultas garante detecção por si só — elas sustentam a triagem com evidência. Quando um incidente é confirmado, os logs de rede encurtam o interrogatório de quem falou com quem, quando e por quanto tempo, antes de qualquer resposta guiada, como no roteiro de resposta a ransomware.
