Problemas de carimbo de data/hora PCAP: quando inspecionar, normalizar ou reescrever o tempo de captura
Como raciocinar sobre carimbos de data/hora PCAP incorretos, desvios de relógio, pedidos de captura e reescritas controladas de carimbos de data/hora sem perder evidências.
Os carimbos de data e hora fazem parte da evidência em uma captura de pacote. Eles explicam a ordem, a latência, o tempo de retransmissão, as lacunas entre solicitação e resposta e se um problema corresponde a um log de aplicativo. Quando os carimbos de data/hora estão errados, toda a investigação pode desviar.
Mas o reparo do carimbo de data/hora é sensível. Alterar o tempo de captura pode facilitar a análise e, ao mesmo tempo, tornar o arquivo menos fiel ao evento original.
Problemas comuns de carimbo de data/hora
Os problemas de carimbo de data/hora PCAP incluem:
- pacotes aparecem fora de ordem
- timestamps saltam para trás
- carimbos de data e hora são todos zero
- a resolução é menor do que o esperado
- a captura abrange um intervalo de tempo impossível
- Mudanças no relógio da VM ou do host durante a captura
- capturas mescladas usam relógios diferentes
- suposições de fuso horário confundem relatórios humanos
Alguns deles são problemas de exibição. Alguns são problemas de captura. Alguns são problemas de mesclagem. A estratégia de reparo depende de qual é.
Pedido separado do significado do relógio de parede
A ordem dos pacotes e a hora do relógio de parede estão relacionadas, mas não são idênticas. Uma captura pode preservar a ordem dos pacotes enquanto possui valores de relógio de parede inúteis. Outra captura pode ter valores de relógio de parede plausíveis, mas incluir fluxos mesclados de diferentes pontos de captura que tornam as comparações de tempo inseguras.
Antes de reescrever os carimbos de data/hora, pergunte:
- a ordem dos pacotes é confiável?
- o tempo relativo é confiável?
- é necessário o tempo absoluto do relógio de parede?
- a captura é mesclada de várias fontes?
- os logs do aplicativo fornecem uma âncora externa?
- as ferramentas downstream interpretarão mal os carimbos de data/hora atuais?
Essas questões determinam se a inspeção, anotação, normalização ou reescrita é apropriada.
Quando a normalização ajuda
A normalização do carimbo de data/hora pode ser útil quando o tempo absoluto original não é importante, mas a ordem relativa e o espaçamento são. Por exemplo, uma captura de laboratório com um relógio de sistema errado ainda pode mostrar um tempo de resposta de solicitação válido. A normalização da hora de início pode facilitar a leitura dos relatórios sem alterar o comportamento relativo.
A saída deve registrar:
- primeiro carimbo de data/hora original
- primeiro carimbo de data/hora normalizado
- se os deltas foram preservados
- pacotes afetados
- motivo da normalização
Sem esse registro, um futuro engenheiro não poderá dizer se a evidência temporal é original ou editada.
Quando reescrever é arriscado
Reescrever carimbos de data/hora é arriscado quando a captura deve ser correlacionada com:
- registros do servidor
- registros da câmera
- Rastreamentos USB ou seriais
- cronogramas de incidentes
- evidências legais ou de conformidade
- capturas de rede multiponto
Nesses casos, alterar os carimbos de data/hora pode tornar o arquivo mais fácil de inspecionar, mas mais difícil de confiar. Um primeiro passo melhor pode ser a anotação: documente o problema do relógio e deixe a captura bruta intacta.
Onde a cirurgia PCAP se encaixa
A cirurgia PCAP é construída em torno de edições controladas, não de mutações casuais. O trabalho de carimbo de data e hora deve seguir a mesma regra da soma de verificação ou do corte de pacotes: inspecionar primeiro, decidir depois, reescrever somente quando a evidência o apoiar.
Um bom fluxo de trabalho de cirurgia PCAP deve ajudar a responder:
- que anomalia de carimbo de data/hora existe?
- quantos pacotes são afetados?
- o pedido ainda é confiável?
- o tempo relativo ainda é útil?
- que reescrita ou normalização foi aplicada?
- a mudança pode ser reproduzida?
Para engenheiros de protocolo, o valor não é apenas alterar um arquivo. O valor é produzir uma captura e uma trilha de raciocínio que outro engenheiro possa validar.