Ce qu'un journal VPN peut prouver sur la navigation et ce qu'il ne peut pas
Les enregistrements de session, de résolveur, de flux et d'application prouvent des événements différents. Choisissez la question d'audit et la jointure d'identité avant de parler d'historique de navigation.
Avant de choisir un collecteur de journaux, décidez quel événement l'audit doit établir. Demander quelle session VPN a contacté une adresse de destination est une autre question que demander quelle personne a ouvert une page précise. Les deux exigent des enregistrements différents, des jointures différentes et des niveaux de confiance différents. Un journal de connexion OpenVPN répond à la première et ne peut pas répondre à la seconde.
Nommez l'événement avant de choisir un collecteur
Un enregistrement de session montre une identité acceptée, une heure de début et de fin et une adresse que le serveur a attribuée selon sa propre politique. Le journal d'un résolveur montre qu'un nom a été interrogé auprès de ce résolveur. Un enregistrement de flux montre les adresses, les ports, le protocole et l'heure, et un journal d'application montre la transaction que cette application a réellement traitée. Aucun de ces quatre ne remplace un autre.
Chacun d'eux établit un événement et laisse les autres ouverts. Écrire la question d'abord vous empêche de monter une histoire que les données ne peuvent pas soutenir.
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
La première commande affiche les événements de session du journal du service. La deuxième imprime la liste actuelle des clients avec les adresses attribuées, qui est la correspondance dont dépend une jointure d'audit. La troisième affiche l'état de flux en direct, utile seulement tant que la connexion existe encore.
Une requête n'est pas une visite
Un navigateur résout les noms de manière spéculative, met les réponses en cache et les réutilise sans interroger de nouveau le résolveur surveillé. Un nom dans le journal d'un résolveur prouve donc une requête, pas une visite. Le DNS sur HTTPS élargit cet écart, car un navigateur configuré pour cela envoie ses questions là où votre enregistreur ordinaire ne les voit jamais.
Les adresses de destination ne sont pas meilleures à elles seules. Une adresse peut héberger de nombreux sites sans rapport, le DNS inverse est une supposition et non une reconstruction, et un nom d'hôte visible pendant une poignée de main TLS n'est pas le chemin de requête à l'intérieur de la session chiffrée.
Pour des transactions exactes, il vous faut les enregistrements d'événements de l'application elle-même ou une conception de mandataire explicitement prise en charge pour la journalisation. Un tunnel CONNECT donne au mandataire la destination et le volume, pas les chemins de page à l'intérieur. L'accès administratif au réseau n'est pas une licence pour remplacer discrètement le modèle de confiance de l'application.
Joignez identité et temps avant de nommer une personne
Un enregistrement de flux portant une adresse source interne ne signifie rien tant que cette adresse n'est pas jointe à une session au même moment. Les adresses sont réutilisées, et la même adresse a pu appartenir à une autre session une heure plus tôt. L'attribution statique est une façon de conserver l'association, pas la seule.
Les frontières de traduction affaiblissent encore la jointure. Si plusieurs appareils partageaient déjà une adresse source avant votre point d'observation, le mieux que vous puissiez identifier est la session de passerelle partagée plutôt qu'un appareil unique. Un certificat ou un compte utilisé par plusieurs personnes a le même effet.
Enregistrez les fuseaux horaires, les sources d'horloge, les points d'observation et chaque saut de traduction. Des enregistrements manquants peuvent signifier qu'une entrée de flux a expiré, qu'un capteur a été contourné ou qu'un journal d'application était désactivé. L'absence n'est pas la preuve que rien ne s'est produit.
Définissez ensuite les champs minimaux, les lecteurs autorisés et la durée de conservation pour la finalité déclarée. La corrélation et la mauvaise attribution sont des questions de conception et non une réflexion après coup, et les métadonnées qui identifient des personnes méritent la même protection que la correspondance d'identité dont elles dépendent.
Testez l'audit avec une activité que vous contrôlez
Générez du trafic autorisé dont vous connaissez déjà la session et l'application, puis vérifiez ce que chaque enregistrement a réellement capturé. Faites une requête sans charger la page, chargez une page depuis le cache et ouvrez une connexion via un mandataire, et regardez quels événements apparaissent.
Rapportez l'événement que les preuves soutiennent et dites ce qu'elles ne couvrent pas. Un enregistrement modeste avec une portée déclarée survit à la revue ; un historique de navigation ambitieux assemblé à partir de suppositions n'y survit pas.