Cibersegurança e segurança da informação

Zeek Logs: Como Investigar conn.log, dns.log e http.log

7 min de leituraPublicado: 5 de agosto de 2026
Representação visual profissional de Zeek Logs no domínio de Monitorização de Segurança de Rede
Resposta rápida

A análise de Zeek Logs é feita mapeando Flow, horários, protocolos, DNS/TLS/HTTP e o contexto do ativo. Um único pacote ou conexão é uma evidência parcial, por isso é construída uma sequência e validada com fontes adicionais.

O tráfego de rede fornece uma perspetiva que não depende apenas do endpoint. Permite identificar quem comunicou com quem, qual protocolo, em que ordem e com que volume, mas requer uma compreensão dos limites da visibilidade e da encriptação. Este artigo foca-se nos Zeek Logs e destina-se a analistas SOC e Network Hunters. O objetivo é fornecer um método de trabalho que possa ser aplicado na prática, numa entrevista profissional e num ambiente de trabalho, sem se limitar a uma definição de dicionário.

O principal desafio é que os dados são quase sempre parciais. query name, response code, TTL podem indicar uma direção, mas o seu significado depende do tempo, do ativo, do utilizador e da atividade esperada. Por isso, construiremos a investigação em torno de uma questão de inquérito, evidências necessárias e um critério claro para a conclusão.

O cenário prático no artigo é: investigar uma única sessão através de quatro Logs. Todos os exemplos são dados de laboratório ou descrições de processos. Quando se trata de Penetration Testing, Web ou Cloud, deve-se trabalhar apenas com autorização expressa, Scope definido e capacidade de interromper o teste.

Estrutura dos Logs e UID

Os campos importantes não são necessariamente os que são apresentados no topo do ecrã. Nos Zeek Logs, devem ser identificados identificadores estáveis, tempo, origem, destino, resultado e contexto. Exemplos úteis incluem query name, response code, TTL, subdomain entropy, NXDOMAIN ratio, resolver context. O objetivo é permitir a Correlation entre registos e não apenas a leitura de um Event individual.

É recomendável criar um pequeno Data dictionary: nome do campo, significado, formato, fonte, valores Null esperados e se é confiável para ligação. Assim, pode-se diferenciar um campo de visualização de um identificador de investigação e identificar quando um Connector ou versão alterou o Schema.

conn.log

O tópico 'conn.log' é uma parte central do trabalho com Zeek Logs. É aconselhável dividi-lo em três perguntas: qual é a entrada, que decisão se quer tomar e qual a evidência suficiente para a justificar. Estas perguntas evitam o uso automático da ferramenta sem compreender o objetivo.

Na prática, registe query name, response code, TTL, subdomain entropy, NXDOMAIN ratio, compare com o comportamento esperado e defina pelo menos um Pivot. O resultado deve ser verificável por outro analista, incluindo limitações e próximos passos.

dns.log

O tópico 'dns.log' é uma parte central do trabalho com Zeek Logs. É aconselhável dividi-lo em três perguntas: qual é a entrada, que decisão se quer tomar e qual a evidência suficiente para a justificar. Estas perguntas evitam o uso automático da ferramenta sem compreender o objetivo.

Na prática, registe query name, response code, TTL, subdomain entropy, NXDOMAIN ratio, compare com o comportamento esperado e defina pelo menos um Pivot. O resultado deve ser verificável por outro analista, incluindo limitações e próximos passos.

http.log e tls.log

O tópico 'http.log e tls.log' é uma parte central do trabalho com Zeek Logs. É aconselhável dividi-lo em três perguntas: qual é a entrada, que decisão se quer tomar e qual a evidência suficiente para a justificar. Estas perguntas evitam o uso automático da ferramenta sem compreender o objetivo.

Na prática, registe query name, response code, TTL, subdomain entropy, NXDOMAIN ratio, compare com o comportamento esperado e defina pelo menos um Pivot. O resultado deve ser verificável por outro analista, incluindo limitações e próximos passos.

Correlação e Timeline

A Timeline é a espinha dorsal dos Zeek Logs. Os tempos são normalizados para UTC ou o fuso horário é explicitamente indicado, mantendo tanto o Event time quanto o Ingestion time, e os eventos são conectados por identificadores estáveis. A linha deve incluir tempo, origem, entidade, ação, resultado e confiabilidade.

Uma lacuna ou contradição não é um erro no documento, mas sim uma descoberta. Clock drift, atraso na receção, NAT, reutilização de PID ou uma Session contínua podem alterar a ordem. Por isso, são indicados intervalos de incerteza e é mantida uma ligação de volta à evidência bruta.

Quando regressar ao PCAP

O tópico 'Quando regressar ao PCAP' é uma parte central do trabalho com Zeek Logs. É aconselhável dividi-lo em três perguntas: qual é a entrada, que decisão se quer tomar e qual a evidência suficiente para a justificar. Estas perguntas evitam o uso automático da ferramenta sem compreender o objetivo.

Na prática, registe query name, response code, TTL, subdomain entropy, NXDOMAIN ratio, compare com o comportamento esperado e defina pelo menos um Pivot. O resultado deve ser verificável por outro analista, incluindo limitações e próximos passos.

Pontos de verificação únicos

Neste tópico, é aconselhável construir antecipadamente um mapa de evidências focado. Os principais pontos de verificação são: query name, response code, TTL, subdomain entropy, NXDOMAIN ratio, resolver context, uid, conn.log, dns.log, http.log. A lista não é um Checklist automático; cada item é escolhido porque pode ligar uma entidade, ação e tempo, ou explicar um comportamento legítimo.

  • query name: Defina qual é o valor esperado, o que seria considerado anómalo e qual fonte adicional validará a descoberta.
  • response code: Defina qual é o valor esperado, o que seria considerado anómalo e qual fonte adicional validará a descoberta.
  • TTL: Defina qual é o valor esperado, o que seria considerado anómalo e qual fonte adicional validará a descoberta.
  • subdomain entropy: Defina qual é o valor esperado, o que seria considerado anómalo e qual fonte adicional validará a descoberta.
  • NXDOMAIN ratio: Defina qual é o valor esperado, o que seria considerado anómalo e qual fonte adicional validará a descoberta.
  • resolver context: Defina qual é o valor esperado, o que seria considerado anómalo e qual fonte adicional validará a descoberta.

Quando um dos pontos focais não está disponível, a lacuna deve ser documentada e uma alternativa escolhida. Por exemplo, se o Process identifier não for estável, pode-se usar tempo, Host, User e Parent; se o Payload for encriptado, usam-se Metadados, volume, frequência e o contexto TLS/DNS.

Processo de trabalho recomendado

  1. Defina um Scope e uma única questão de trabalho sobre Zeek Logs.
  2. Registe as fontes de dados e as evidências necessárias: query name, response code, TTL, subdomain entropy.
  3. Crie um Baseline curto de comportamento normal ou resultado esperado.
  4. Execute o teste mínimo num ambiente de laboratório e guarde tempo, entrada e saída.
  5. Construa uma Timeline ou tabela de comparação e separe o facto da interpretação.
  6. Faça um Pivot para uma fonte adicional para confirmar ou refutar a explicação inicial.
  7. Resuma a decisão, as limitações, a ação recomendada e o critério de Retest.

Cenário prático

O cenário escolhido é a investigação de uma única Sessão através de quatro Logs. O objetivo do exercício não é provar a capacidade de ataque, mas sim praticar a recolha, comparação e documentação de forma segura. Antes de iniciar o trabalho, são definidos dados simulados, uma janela de tempo e um resultado esperado.

No final do exercício, deve ser apresentado um produto que outro analista ou testador possa rever: uma captura de ecrã ou Export da evidência, uma Timeline curta, uma suposição inicial, uma evidência de validação, uma limitação e uma recomendação. Quando não há evidência suficiente, a conclusão correta é que o cenário não foi provado.

EtapaO que executarProduto
PreparaçãoDefina Scope, tempo e objetivo. Anote quais campos ou evidências de query name, response code, TTL devem aparecer.Plano de teste curto
Criação de dadosExecute uma ação segura e simulada relacionada com Zeek Logs, sem informação real ou impacto no sistema de produção.Evento/Pedido/Flow controlado
RecolhaRecolha a evidência bruta e o contexto de uma fonte adicional. Verifique Time zone, identificadores e integridade.Duas evidências ligadas
AnáliseEscreva o que cada evidência prova, o que não prova e qual é a possível explicação legítima.Conclusão provisória
ConclusãoEscolha fechar, escalar, Finding ou Tuning; adicione uma recomendação e Retest.Produto documentado

Checklist prático

  • Verifique e documente: os cinco componentes do Flow.
  • Verifique e documente: hora de início, duração e volume.
  • Verifique e documente: DNS name e TLS metadata.
  • Verifique e documente: HTTP method, host e URI quando visíveis.
  • Verifique e documente: TCP flags e stream.
  • Verifique e documente: ligação ao Host e ao Process.
  • Indique Time zone, versão da ferramenta e hora de recolha.
  • Guarde os dados brutos antes de filtrar ou alterar.
  • Escreva o que a descoberta prova e o que ainda é desconhecido.
  • Defina proprietário e ação de acompanhamento com prazo.

Erros comuns

  • Confundir Capture Filter com Display Filter.
  • Inferir conteúdo quando o tráfego está encriptado.
  • Analisar IP sem contexto DNS/TLS.
  • Ignorar NAT ou Proxy.
  • Focar-se num único Packet.
  • Não guardar o Capture original.

Resumo e CTA

Zeek Logs: Como investigar conn.log, dns.log e http.log é um tópico que combina conhecimento técnico com disciplina de trabalho. Comece com uma pergunta, recolha apenas evidências relevantes, mantenha o contexto e o tempo, e escolha uma ação que possa ser justificada e retestada.

No percurso Cybersecurity & AI da HPI, estes princípios são praticados usando sistemas, logs e laboratórios. Um passo natural é passar para os artigos relacionados, realizar o exercício de laboratório e guardar o produto como parte de um portfólio profissional.

Perguntas frequentes

Os Zeek Logs sozinhos provam um ataque ou uma vulnerabilidade?

Não. Eles fornecem um sinal ou uma descoberta que precisa de contexto, validação e uma fonte adicional. Uma conclusão profissional baseia-se numa sequência de evidências e na conformidade com o comportamento esperado.

O que fazer quando faltam alguns dados?

Documente o que falta, verifique uma fonte alternativa e reduza o nível de confiança. Não complete campos com suposições ou apresente Unknown como correto.

Quanto tempo devo guardar as evidências?

O tempo depende da política, regulamentação, custo e tipo de incidente. É importante definir antecipadamente Retention, Legal hold e a capacidade de exportar evidências num formato verificável.

Como praticar sem comprometer um sistema real?

Use máquinas virtuais, dados simulados, CTF ou um laboratório dedicado. Em testes autorizados, defina Scope, Stop conditions e backup antes de iniciar o trabalho.

Quer verificar se este percurso é para si?

Deixe os seus dados e um consultor da HPI ligará para uma breve conversa de adequação, sem compromisso.

Os seus dados são armazenados em segurança.

Para estudos SOC e Cyber na HPI Cybersecurity & AI Program

Quer os detalhes do programa? Deixe os seus dados e entraremos em contacto.

Artigos relacionados