Que sont les journaux de communication ?
Les communications sur Internet ne disparaissent pas forcément complètement sur le moment.
Des enregistrements peuvent rester sur sites web, serveurs, DNS, opérateurs, routeurs, pare-feu et systèmes similaires.
Ces enregistrements de communication sont généralement appelés journaux de communication.
Ils peuvent inclure non seulement le contenu, mais aussi l'heure, l'adresse IP source, la destination, l'URL consultée, les informations de navigateur, les cookies, les requêtes DNS et d'autres informations périphériques.
Pour réfléchir à l'anonymat, il ne suffit pas de demander si le contenu est chiffré. Même quand le contenu n'est pas lisible, les métadonnées associées peuvent devenir des indices de suivi.
Où restent les journaux de communication ?
Un journal de communication est un enregistrement relatif à une communication.
Quand vous accédez à un site, le serveur web peut enregistrer quand l'accès a eu lieu, depuis quelle adresse IP, vers quelle URL et avec quelles informations de navigateur.
Les journaux ne sont pas identiques dans tous les environnements. Les informations enregistrées dépendent des réglages serveur, de l'application, du cloud utilisé, de la configuration réseau et de la politique de conservation.
Le point important est qu'il existe plusieurs points d'observation : site web, DNS, opérateur, routeurs, réseau interne, infrastructure cloud.
| Lieu où des journaux peuvent rester | Informations pouvant être enregistrées | Objectif principal |
|---|---|---|
| Serveur web | Heure d'accès, IP, URL, User-Agent, référent | Analyse d'accès, incident, détection d'attaque |
| Application | Historique de connexion, opérations, erreurs, ID de compte | Prévention des abus, exploitation du service |
| Résolveur DNS | Domaine demandé, heure, informations sur le demandeur | Résolution de noms, gestion réseau |
| FAI ou opérateur réseau | Heure de connexion, IP attribuée, volume, partie des destinations | Exploitation réseau, gestion des connexions |
| Routeur et pare-feu | Destination, volume, communications bloquées, appareils internes | Gestion réseau, sécurité |
Pourquoi des journaux restent-ils ?
Les journaux n'existent pas seulement pour surveiller les utilisateurs. Ils servent souvent à exploiter de manière stable services et réseaux.
Lorsqu'une erreur survient, l'administrateur vérifie les journaux pour savoir quelle URL, à quelle heure et avec quel type d'erreur.
Ils sont aussi importants pour enquêter sur connexions non autorisées, accès massifs, scans de vulnérabilité, infections par malware ou soupçons de fuite d'information.
| Objectif | Utilisation des journaux | Exemple |
|---|---|---|
| Gestion d'incident | Chercher les causes d'erreurs ou d'arrêt | Vérifier si les erreurs 500 augmentent sur une URL |
| Sécurité | Détecter les accès suspects | Vérifier de nombreuses tentatives de connexion en peu de temps |
| Prévention des abus | Chercher des indices d'attaque ou de violation | Examiner requêtes anormales ou sources inhabituelles |
| Amélioration du service | Comprendre l'utilisation | Voir pages fréquentes et horaires de forte visite |
Les journaux sont un mécanisme de base pour protéger les services. Mais comme ils peuvent contenir des informations sur le comportement, ils deviennent aussi un risque de vie privée selon leur gestion.
Journaux restant côté site web
Lorsqu'un site est consulté, des journaux d'accès peuvent rester sur le serveur web.
Ils contiennent souvent adresse IP source, heure, méthode HTTP, URL, code de statut, User-Agent, référent et informations similaires.
Exemple d'URL :
URL d'exemple : https[:]//example.com/article/network-log
example.com est ici un domaine d'exemple.
Même en HTTPS, le site reçoit le chemin et la requête de l'URL, les cookies et les informations envoyées. HTTPS rend le contenu difficile à lire sur le trajet, mais n'empêche pas le site de destination de recevoir la requête.
Ce que le serveur reçoit et ce qu'il enregistre réellement peuvent différer. s et corps de requête peuvent être enregistrés ou non selon les réglages.
| Information | Contenu | Attention |
|---|---|---|
| Heure d'accès | Quand l'accès a eu lieu | Peut être recoupée avec d'autres journaux |
| Adresse IP source | Quelle adresse IP a connecté | Avec CDN ou proxy, la source directe peut être un intermédiaire |
| URL | Page ou API consultée | La chaîne de requête peut contenir des identifiants |
| User-Agent | Navigateur, OS, application | Sert à déduire l'environnement |
| Cookie | Identifiant enregistré et renvoyé par le navigateur | Peut reconnaître revisite ou état de connexion |
| Référent | Page précédente | Peut être absent ou partiel selon Referrer-Policy |
| Code de statut | Résultat de la requête | 200, 301, 403, 404, 500 indiquent le traitement |
Avec CDN, équilibreur de charge ou reverse proxy, le serveur web peut voir l'IP de l'intermédiaire. L'IP client originale peut alors se trouver dans des en-têtes comme X-Forwarded-For ou dans les journaux du CDN.
Journaux dans les applications et systèmes d'authentification
Les journaux serveur ne se limitent pas aux journaux d'accès web.
Les fonctions de connexion, les fonctions de paiement, les consoles d'administration, les API, les bases de données, les outils de surveillance d'erreurs, etc. peuvent aussi conserver des enregistrements sur les opérations des utilisateurs et le comportement du système.
Par exemple, un service doté d'une fonction de connexion peut enregistrer les informations suivantes.
- Connexion réussie
- Connexion échouée
- Changement de mot de passe
- Tentative d'authentification à deux facteurs
- Émission d'une session
- Modification des paramètres du compte
- Accès à la console d'administration
Une API peut enregistrer quel endpoint a été appelé, par quel compte ou adresse IP et à quelle heure.
Ces journaux servent à détecter connexion frauduleuse, prise de compte, abus de droits et usage anormal d'API.
Enregistrements possibles côté opérateur
Pour accéder à Internet, la communication passe généralement par un opérateur ou fournisseur de ligne.
Celui-ci peut conserver des enregistrements sur les moments de connexion, les adresses IP attribuées et le volume de trafic.
Les adresses des lignes domestiques ou mobiles peuvent changer avec le temps. Savoir quelle ligne utilisait une adresse à un moment donné dépend donc des enregistrements opérateur.
Avec mobile ou CGNAT, de nombreux utilisateurs peuvent partager une adresse IP globale. L'heure et les numéros de port peuvent alors compter pour distinguer les connexions.
L'existence de journaux opérateur ne signifie pas que tout le monde peut les consulter librement. Ils ne sont normalement pas accessibles au public.
Enregistrements liés au DNS
Pour accéder à un site, le navigateur ou l'OS doit convertir le nom de domaine en adresse IP. Ce mécanisme s'appelle DNS.
Pour https[:]//example.com, l'appareil recherche l'adresse IP de example.com.
Un journal DNS peut indiquer quel domaine a été demandé, depuis quel terminal ou réseau et à quelle heure.
Le DNS n'enregistre pas le corps de la page. Mais il peut révéler le domaine que quelqu'un a tenté de consulter.
Le lieu où ces journaux restent dépend des réglages. Si le DNS du FAI est utilisé, le résolveur du FAI peut recevoir la requête. Si le navigateur ou l'OS utilise un autre résolveur ou un DNS chiffré, le point d'observation change.
Il faut donc demander : quel résolveur DNS a reçu la requête ?
Journaux de routeurs et pare-feu
Les journaux ne restent pas seulement côté site ou opérateur.
Routeurs domestiques, équipements d'entreprise ou d'école, pare-feu cloud, serveurs proxy, passerelles et systèmes similaires peuvent aussi enregistrer des communications.
Dans un réseau d'organisation, il peut être enregistré quel appareil s'est connecté à quel serveur extérieur et quand. Cela sert à enquêter sur malware, accès non autorisé, fuite d'information ou abus interne.
Côté serveur aussi, journaux d'authentification, pare-feu, SSH, application et audit cloud peuvent coexister.
| Type de journal | Contenu possible | Utilisation |
|---|---|---|
| Journal d'authentification | Connexions réussies ou échouées, IP source | Vérification d'attaques par force brute |
| Journal pare-feu | Communications autorisées ou bloquées, ports, destinations | Détection de trafic suspect |
| Journal proxy | Accès de terminaux internes vers des sites extérieurs | Gestion ou enquête réseau interne |
| Journal d'audit cloud | Actions d'administration, API, changements de droits | Suivi des modifications et abus de droits |
| Journal applicatif | Erreurs, opérations, résultats | Incident et enquête d'abus |
Les journaux de communication s'étendent donc à tout le réseau et aux systèmes, pas seulement au site consulté.
Relation entre HTTPS et journaux
HTTPS est un mécanisme important pour chiffrer le contenu de la communication et vérifier que l'interlocuteur est bien celui prévu.
Cependant, le fait d'utiliser HTTPS ne signifie pas que toutes les informations de communication deviennent invisibles pour tout le monde.
Les principaux éléments protégés par HTTPS sont les contenus visibles par des tiers situés sur le trajet de communication. Par exemple, le contenu saisi dans un formulaire, le corps de la page, beaucoup d'en-têtes HTTP, le chemin et la requête de l'URL deviennent normalement difficiles à lire sur le trajet.
En revanche, le serveur web de destination déchiffre la communication et traite la requête. Le site web reçoit donc l'URL consultée, les cookies, le User-Agent, les informations de connexion, les contenus de formulaire envoyés, etc.
De plus, même sur le trajet de communication, l'heure de connexion, l'adresse IP source, l'adresse IP de destination, le volume de communication et certaines informations liées à la connexion TLS peuvent être observés.
Autrement dit, HTTPS est très important, mais ce n'est pas un mécanisme qui fait disparaître tous les problèmes de journaux.
| Observateur | Informations pouvant être visibles | Informations plus difficiles à voir |
|---|---|---|
| Site web | URL, Cookie, User-Agent, contenu envoyé, actions de connexion | Contenu que les tiers du trajet ne doivent pas lire |
| Tiers sur le trajet | IP source, IP destination, heure, volume | Corps de page, formulaires, chemin et requête de l'URL |
| Résolveur DNS | Domaine demandé, heure | Corps de page et opérations précises |
| Routeur ou pare-feu | Destination, volume, autorisation ou blocage | Corps HTTPS et nombreux en-têtes HTTP |
Les journaux ne sont pas forcément mauvais
Du point de vue de l'anonymat et de la vie privée, les journaux méritent attention. Mais ils ne sont pas mauvais en eux-mêmes.
Sans journaux, il serait difficile d'analyser pannes, accès non autorisés, prises de compte, infections par malware et exploitation stable du service.
Le point important est de savoir dans quel but les journaux sont conservés, dans quelle étendue ils sont enregistrés, pendant combien de temps ils sont conservés, et qui peut y accéder.
Le fait que des journaux existent et le fait que n'importe qui puisse les consulter librement sont deux choses différentes. Des journaux correctement gérés sont des informations importantes pour protéger un service, mais des journaux conservés de façon excessive ou mal administrés deviennent un risque pour la vie privée.
Dans l'anonymat, les journaux deviennent des indices
Pour l'anonymat, regarder seulement si le contenu est chiffré est insuffisant.
Même si le contenu de la communication ne peut pas être lu, l'heure de communication, l'adresse IP source, la destination, les requêtes DNS, les cookies, le User-Agent, le référent et d'autres informations peuvent être enregistrés sous d'autres formes.
Ces informations ne permettent pas toujours, prises séparément, d'identifier directement une personne. Toutefois, lorsque plusieurs enregistrements sont combinés, ils peuvent servir à déduire qu'il s'agit probablement du même utilisateur, le chemin d'accès, la chronologie des actions, le réseau d'origine, etc.
| Information | Ce qu'elle peut indiquer | Attention pour l'anonymat |
|---|---|---|
| Heure d'accès | Quand la communication a eu lieu | Peut être recoupée avec d'autres enregistrements |
| Adresse IP | Depuis quel réseau | Peut indiquer ligne, région ou organisation |
| Requête DNS | Domaine recherché | Donne un indice de destination même sans corps de page |
| Cookie | Même navigateur | Sert à reconnaître revisite ou connexion |
| User-Agent | Navigateur et OS | Devient un trait de l'environnement |
| Référent | Page précédente | Peut révéler une partie du trajet |
| Requête d'URL | Terme de recherche, identifiant, session possible | Peut rester dans les logs côté serveur |
Dans l'anonymat, « le contenu de la communication n'est pas lu » et « aucune trace de communication ne reste » ne sont pas la même chose.
Même si le contenu de la communication est chiffré, des informations périphériques à cette communication peuvent rester. Pour réfléchir à l'anonymat, il faut donc organiser non seulement le chiffrement, mais aussi les endroits où des journaux peuvent rester et le type de journaux concernés.
Résumé
Les journaux de communication sont des enregistrements liés aux communications.
Sites web, applications, DNS, opérateurs, routeurs, pare-feu et infrastructures cloud peuvent conserver diverses informations : heure, IP source, URL, User-Agent, cookies, référent, DNS, destination, volume, authentification et opérations.
Ces journaux servent aux incidents, à la sécurité, aux enquêtes d'abus et à l'amélioration du service. Ils sont donc importants pour exploiter Internet de manière sûre.
Mais pour l'anonymat, ils peuvent devenir des indices de suivi. Même avec chiffrement, source, destination, heure, DNS, cookies et User-Agent peuvent rester enregistrés sous d'autres formes.
Comprendre les journaux aide à ne pas limiter l'analyse à « le contenu est-il visible ? » et à regarder aussi où les informations périphériques peuvent rester.