O que um registro VPN pode e não pode provar sobre a navegação
Registros de sessão, resolvedor, fluxo e aplicativo provam eventos diferentes. Escolha a pergunta de auditoria e a junção de identidade antes de chamar isso de histórico de navegação.
Antes de escolher um coletor de registros, decida qual evento a auditoria deve estabelecer. Perguntar qual sessão VPN contatou um endereço de destino é diferente de perguntar qual pessoa abriu uma página específica. Ambos exigem registros diferentes, junções diferentes e níveis de confiança diferentes. Um registro de conexão do OpenVPN responde ao primeiro e não pode responder ao segundo.
Nomeie o evento antes de escolher um coletor
Um registro de sessão mostra uma identidade aceita, um horário de início e fim e um endereço que o servidor atribuiu segundo sua própria política. O registro de um resolvedor mostra que um nome foi consultado nesse resolvedor. Um registro de fluxo mostra endereços, portas, protocolo e horário, e um registro de aplicativo mostra a transação que esse aplicativo realmente tratou. Nenhum dos quatro substitui outro.
Cada um deles estabelece um evento e deixa os outros em aberto. Escrever a pergunta primeiro impede você de montar uma história que os dados não podem sustentar.
journalctl -u [email protected] --since today | grep -i 'peer info\|assigned' cat /etc/openvpn/server/openvpn-status.log | head -20 conntrack -L -p tcp --dport 443 2>/dev/null | head -20
O primeiro comando mostra eventos de sessão do diário do serviço. O segundo imprime a lista atual de clientes com os endereços atribuídos, que é o mapeamento do qual depende uma junção de auditoria. O terceiro mostra o estado de fluxo ao vivo, útil apenas enquanto a conexão ainda existe.
Uma consulta não é uma visita
Um navegador resolve nomes de forma especulativa, armazena as respostas em cache e as reutiliza sem perguntar novamente ao resolvedor monitorado. Um nome no registro de um resolvedor prova, portanto, uma consulta, não uma visita. DNS sobre HTTPS amplia essa lacuna, porque um navegador configurado para isso envia suas perguntas a um lugar onde o seu registrador comum nunca as vê.
Endereços de destino não são melhores por si sós. Um endereço pode hospedar muitos sites não relacionados, o DNS reverso é uma conjectura e não uma reconstrução, e um nome de host visível durante um handshake TLS não é o caminho da requisição dentro da sessão cifrada.
Para transações exatas você precisa dos registros de eventos do próprio aplicativo ou de um projeto de proxy explicitamente suportado para registro. Um túnel CONNECT dá ao proxy o destino e o volume, não os caminhos de página dentro dele. O acesso administrativo à rede não é uma licença para substituir em silêncio o modelo de confiança do aplicativo.
Junte identidade e tempo antes de nomear uma pessoa
Um registro de fluxo com um endereço de origem interno não significa nada até que esse endereço seja unido a uma sessão no mesmo momento. Endereços são reutilizados, e o mesmo endereço pode ter pertencido a outra sessão uma hora antes. A atribuição estática é uma forma de manter a associação, não a única.
As fronteiras de tradução enfraquecem ainda mais a junção. Se vários dispositivos já compartilhavam um endereço de origem antes do seu ponto de observação, o melhor que você pode identificar é a sessão de gateway compartilhada e não um único dispositivo. Um certificado ou conta usados por várias pessoas têm o mesmo efeito.
Registre os fusos horários, as fontes de relógio, os pontos de observação e cada salto de tradução. Registros ausentes podem significar que uma entrada de fluxo expirou, que um sensor foi contornado ou que um registro de aplicativo estava desligado. A ausência não é prova de que nada aconteceu.
Depois defina os campos mínimos, os leitores permitidos e o período de retenção para a finalidade declarada. Correlação e atribuição errada são questões de projeto e não um pensamento tardio, e metadados que identificam pessoas merecem a mesma proteção que o mapeamento de identidade do qual dependem.
Teste a auditoria com atividade que você controla
Gere tráfego permitido cuja sessão e aplicativo você já conhece e depois verifique o que cada registro realmente capturou. Faça uma consulta sem carregar a página, carregue uma página do cache e abra uma conexão através de um proxy, e observe quais eventos aparecem.
Relate o evento que as provas sustentam e diga o que ele não cobre. Um registro modesto com um escopo declarado sobrevive à revisão; um histórico de navegação ambicioso montado com suposições não sobrevive.