Resumo

  • conn.log contém a interpretação compacta de um sensor Zeek sobre o tráfego recebido; seus campos não formam uma transcrição pacote a pacote.
  • Uma conclusão verificável preserva log e esquema originais, versão do Zeek, scripts, ponto de captura, filtro, relógio, indícios de perda e registros associados pelo mesmo uid.

A abstração que tornou a vigilância possível

No trabalho de 1998 sobre o Bro, mais tarde rebatizado Zeek, Paxson descreveu duas camadas com funções diferentes. O motor de eventos reduzia o fluxo filtrado de pacotes a eventos de rede de nível mais alto. O interpretador de políticas decidia o que esses eventos significavam para o ambiente monitorado. A observação podia permanecer estável enquanto as regras locais mudavam.

Essa redução permitia acompanhar um enlace movimentado em tempo real. Mas também define a natureza do artefato. Antes da linha legível houve uma posição na rede, uma interface, um filtro de captura, verificações de integridade, uma máquina de estados e scripts. O log é uma saída dessa sequência; não é uma cópia neutra de tudo o que atravessou a rede.

O artigo original tratou a perda de pacotes como risco central. Se o monitor não consumisse o tráfego à velocidade necessária, o buffer do filtro terminaria cheio e pacotes seriam descartados. O pacote perdido poderia conter justamente o sinal da intrusão. O projeto ainda partia do princípio de que o atacante conheceria o monitor e tentaria enganá-lo ou sobrecarregá-lo. Portanto, a saúde do sensor faz parte da evidência.

O sujeito oculto é sempre o sensor

A documentação atual informa que conn.log registra principalmente elementos das camadas 3 e 4: quem falou com quem, quando, por quanto tempo e com qual protocolo. O log inclui TCP e UDP; para UDP e ICMP, “conexão” tem sentido de fluxo. O nome não garante uma sessão com as propriedades do TCP.

ts é o horário do primeiro pacote visto pelo Zeek, não uma prova de que nenhum pacote anterior existiu em outro trecho. uid é um identificador único no conjunto de registros do Zeek e permite correlacionar DNS, HTTP, TLS e outras atividades. Não é uma identidade negociada entre as pontas.

conn_state resume o estado inferido. S0 quer dizer que uma tentativa foi vista sem resposta; SF, que estabelecimento e encerramento pareceram normais; outros códigos representam rejeição, reset e fechamentos parciais. A mesma comunicação pode receber outro resumo num sensor que só vê uma direção, começa tarde ou perde pacotes.

history comprime eventos em letras. Maiúsculas representam o originador; minúsculas, o respondente. SYN, SYN-ACK, ACK, dados, FIN, RST, lacunas e retransmissões entram na sequência. Porém, algumas marcas aparecem no máximo uma vez por direção e outras repetem em escala logarítmica. O campo mostra a forma da comunicação, mas não contém ordem e multiplicidade suficientes para recriar cada pacote.

Os contadores também dependem do método. Em TCP, orig_bytes e resp_bytes vêm dos números de sequência e podem ficar imprecisos, sobretudo em conexões grandes. duration deixa de fora alguns pacotes finais sem carga nova, embora history possa registrá-los. Contagens de pacotes são opcionais e dependem do analisador de tamanho. A classificação local/remoto depende de Site::local_nets. Um vazio pode ser uma escolha de configuração.

Medir a limitação junto com o evento

missed_bytes indica bytes perdidos em lacunas de conteúdo. Um valor diferente de zero normalmente interrompe a análise do protocolo, embora parte dela possa ter sido concluída antes. capture_loss.log procura lacunas em números de sequência TCP e presume que o tráfego ausente corresponde a perda. É um indicador útil exatamente porque expõe a sua base de inferência.

reporter.log registra avisos e erros internos sobre processamento e recursos. A análise deve alinhar esses registros ao intervalo do incidente, verificando reinícios, mudanças de filtro, pressão de CPU, estado da interface e assimetria de rota. O simples fato de conn.log continuar sendo gravado não demonstra que o sensor recebeu tudo.

missed_bytes igual a zero não enxerga perdas antes da interface, tráfego que passou por outro caminho, classes removidas pelo filtro ou tempo anterior à inicialização. Tampouco uma perda estimada invalida automaticamente todos os campos. A incerteza bem descrita tem horário, direção, sensor e estágio.

Preservar um conjunto que possa ser reaberto

Para que a conclusão seja revisada depois, guarde o log bruto e o esquema exato, a versão do Zeek, scripts carregados, configuração relevante, interface e posição na topologia, filtro, fonte de tempo e desvio medido. Inclua capture_loss.log e reporter.log da janela, além dos logs de aplicação relacionados pelo mesmo uid.

Quando privacidade e retenção permitirem, acrescente um trecho PCAP imutável ou um hash que aponte para uma cópia controlada. A captura também tem posição, snap length, perda e cadeia de custódia. Ainda assim, oferece uma camada inferior com a qual o revisor pode testar a inferência compacta.

Se não houver PCAP, a ausência deve ser declarada. “Este sensor Zeek, nesta posição e configuração, observou e resumiu…” delimita uma afirmação forte. Dizer que “os pacotes fizeram” algo que não foi conservado ultrapassa o material disponível.

O esquema precisa acompanhar os dados. A referência atual diz que ip_proto entrou no Zeek 7.1; scripts podem acrescentar campos e alterar o registro. Sem versão e cabeçalho, uma ferramenta futura pode aplicar a semântica de hoje a uma linha de ontem.

Fontes