WireGuard compromis :
pourquoi les logs ne parlent presque pas
En cas de compromission d'un accès VPN WireGuard — leak de clé privée, pair malveillant ou prise de contrôle du serveur — la quantité d'information exploitable dans les journaux système est structurellement très faible. Ce n'est pas un bug. C'est une conséquence directe du design du protocole.
// 01 — WireGuard : pas de démon, pas de logs de session
La majorité des VPN classiques (OpenVPN, IPsec, L2TP) fonctionnent avec un démon en espace utilisateur qui gère les connexions et peut écrire dans un fichier de log. C'est là que se retrouvent les IP sources, les timestamps de connexion, les identifiants de certificat.
WireGuard fonctionne différemment. Il est implémenté comme un
module kernel Linux (wireguard.ko). Il n'y a pas de processus
userspace chargé de logger les événements réseau. Les handshakes cryptographiques (basés sur
Noise Protocol + Curve25519) se font directement dans le noyau, de manière silencieuse.
Point clé : WireGuard n'a pas de concept de "session" au sens où OpenVPN l'entend. Chaque échange de clés est stateless du point de vue du journal — il n'est tracé nulle part par défaut.
// 02 — Ce que contient réellement journald
Quand on tourne journalctl -u wg-quick@wg0 après un incident,
voici ce qu'on trouve en réalité :
Si le service a été arrêté et redémarré plusieurs fois, on verra une succession de blocs
identiques — uniquement les commandes ip link et wg setconf.
Rien qui permette de savoir qui s'est connecté.
// 03 — L'état en RAM : volatile par nature
La commande wg show affiche en temps réel l'état des pairs connectés :
Ces données sont purement volatiles — elles vivent en mémoire kernel, dans la structure interne de l'interface réseau. Au prochain redémarrage du service ou de la machine, elles disparaissent. Aucun fichier n'est écrit sur disque.
Conséquence forensic : si un attaquant prend le contrôle du serveur,
fait un systemctl restart wg-quick@wg0 ou redémarre la machine, la liste des
pairs actifs — et surtout leurs IP endpoints — est définitivement perdue.
// 04 — Ce que dmesg peut contenir (rarement)
Le module kernel WireGuard utilise le niveau KERN_DEBUG pour
ses messages internes de trace cryptographique. Ce niveau est désactivé sur tous les kernels
de production. Même en activant dyndbg manuellement :
En configuration production standard, dmesg ne contiendra au mieux que des
erreurs de configuration (mauvaise clé, interface inconnue) — jamais les handshakes normaux.
// 05 — Comparaison : OpenVPN vs WireGuard
Pour mesurer l'écart, voici ce qu'OpenVPN logue par défaut dans
/var/log/openvpn/openvpn.log :
| Élément loggué | OpenVPN | WireGuard |
|---|---|---|
| IP source du client | ✗ oui (dans log) | ✓ non |
| Heure de connexion | ✗ oui | ✓ non |
| Heure de déconnexion | ✗ oui | ✓ non |
| Identifiant utilisateur / CN cert | ✗ oui | ✓ non (clé publique uniquement) |
| Volume de données échangées | ✗ oui (bytes in/out) | ✓ non (volatile RAM) |
| Fichier log persistant sur disque | ✗ oui par défaut | ✓ aucun par défaut |
// 06 — La seule trace exploitable : netfilter
Il existe un cas où des traces peuvent apparaître : si vous avez configuré iptables ou nftables avec du logging explicite sur l'interface WireGuard.
Ces règles ne sont pas activées par défaut. wg-quick ne les crée pas. Et même si elles existent, elles ne tracent que le trafic forwardé (ce qui sort du VPN vers Internet) — pas les handshakes d'établissement de tunnel.
Point d'attention : si votre fournisseur cloud ou votre hébergeur active des logs netfilter de son côté (via iptables de l'hyperviseur ou flow logs réseau), ces traces existent en dehors de votre serveur WireGuard. Ce que WireGuard ne log pas, la couche réseau sous-jacente peut le faire.
// 07 — Implications pratiques en cas de compromission
Scénario concret : un attaquant vole la clé privée du serveur WireGuard. Il peut alors déchiffrer les paquets futurs interceptés passivement. Mais pour les sessions passées :
- Pas de forward secrecy sur les clés statiques — si la clé privée du serveur est compromise, un attaquant qui aurait enregistré le trafic chiffré auparavant peut le déchiffrer. C'est la limite de WireGuard sur ce point spécifique.
- Mais aucun log de qui s'est connecté — l'attaquant sait ce qui a circulé (si il avait le trafic réseau), pas qui l'a envoyé ni quand, sauf à avoir les métadonnées réseau de son côté.
- Forensic post-mortem très limité — un audit du serveur compromis ne permettra pas de reconstituer la liste des clients connectés sur les 30 derniers jours, ni les plages horaires d'utilisation.
Pour une organisation cherchant à minimiser l'exposition des utilisateurs en cas d'incident serveur, c'est un avantage structurel par rapport à OpenVPN.
// En résumé
WireGuard est privacy-first par architecture, pas par configuration. Pas de démon userspace, pas de log de session, pas de fichier sur disque, état volatile en RAM. En cas de compromission du serveur, un forensic post-mortem trouvera très peu de choses exploitables dans les journaux — c'est un choix délibéré du protocole, et une raison sérieuse de le préférer dans les contextes où la minimisation des traces est une exigence. La seule vraie surface de log reste netfilter, si vous l'avez activé, et les flow logs éventuels de votre fournisseur réseau.