VPS sans logs : configurer un serveur VPN qui ne retient rien

Ce qui est réellement enregistré sur un serveur

L'attrait de gérer son propre VPN est simple : aucune entreprise ne se trouve entre vous et internet pour noter ce que vous faites. Mais un serveur Linux standard conserve tout de même ses propres traces, et si vous voulez une configuration réellement sans logs, vous devez savoir lesquelles :

• WireGuard lui-même ne conserve aucun journal de trafic. Par défaut, il n'écrit rien sur le disque à propos de vos connexions. Il garde seulement en mémoire l'heure du dernier handshake et votre endpoint actuel, que vous voyez avec wg show - et cela est effacé au redémarrage. La couche VPN est donc déjà propre.
• Le système d'exploitation est la partie bruyante. Le journal de systemd (journald) enregistre les événements des services. Si rsyslog est installé, il écrit aussi des fichiers en texte clair comme /var/log/syslog et /var/log/auth.log - et auth.log enregistre chaque connexion SSH. Des fichiers séparés (wtmp, btmp, lastlog) suivent qui s'est connecté et quand, et votre shell conserve un ~/.bash_history.
• Et quelques chemins plus discrets vers le disque. Si le serveur a le swap activé, le noyau peut déverser des pages de RAM - clés comprises - sur le disque. Un programme qui plante peut laisser un core dump de sa mémoire. Et le gestionnaire de paquets écrit des journaux de mise à jour sous /var/log/apt. Une configuration rigoureuse ferme ces chemins aussi.

La limite honnête : ce que le sans-logs peut et ne peut pas faire

Avant de toucher à quoi que ce soit, soyez clair sur ce que vous obtenez réellement. Désactiver les logs empêche votre propre serveur de conserver des traces - donc si le disque est un jour saisi, copié, ou lu par quelqu'un qui parvient à entrer, il y a bien moins à trouver. C'est un gain réel et appréciable.

Ce que cela ne fait pas, c'est vous cacher de l'entreprise qui vous loue le serveur. Votre fournisseur VPS sait toujours qu'une machine existe à cette IP, peut voir combien de bande passante elle consomme, et pourrait en principe observer le trafic au niveau du réseau ou de l'hyperviseur - aucun réglage à l'intérieur de votre serveur n'y change rien. Le sans-logs consiste à minimiser votre propre empreinte, pas à devenir invisible pour l'hébergeur. Choisissez un fournisseur avec lequel vous êtes à l'aise, et considérez les étapes ci-dessous comme une réduction du risque, pas comme son effacement.

Le sans-logs n'est pas une garantie d'anonymat. Deux limites qu'aucun réglage serveur ne peut changer :

• Votre fournisseur voit les IP qui se connectent. Le contenu est chiffré, mais il peut voir que votre IP domestique a atteint le port WireGuard, et à quel moment.
• Votre fournisseur peut faire un instantané de la RAM. Un VPS est une machine virtuelle ; l'hôte contrôle l'hyperviseur et peut capturer la mémoire vive (les clés WireGuard actives et les pairs connectés) et peut être contraint de la remettre à la police sur demande légale valide.

En résumé : vous possédez le logiciel, pas la machine. Le sans-logs abaisse votre risque, il ne l'efface pas.

Étape 1 : Déplacer le journal systemd en RAM

D'abord, dites à journald de garder son journal uniquement en mémoire, afin qu'il n'atterrisse jamais sur le disque et disparaisse à chaque redémarrage. Ouvrez sa configuration :

nano /etc/systemd/journald.conf

Sous la section [Journal], définissez ces deux lignes (retirez le # en tête s'il est présent) :

[Journal]
Storage=volatile
RuntimeMaxUse=16M

Appliquez-le et le journal réside maintenant dans /run (RAM), plafonné à 16 Mo et effacé au redémarrage :

systemctl restart systemd-journald

Étape 2 : Placer tout /var/log en RAM

Le journal est maintenant en mémoire, mais plusieurs outils déposent encore des fichiers en texte clair dans /var/log - rsyslog, le auth.log qui enregistre les connexions SSH, les journaux de mise à jour apt, et les enregistrements de connexion wtmp/btmp/lastlog (qui sont réécrits à chaque connexion, donc les supprimer simplement ne sert à rien). La solution propre et globale est de monter tout le répertoire /var/log comme un tmpfs - un système de fichiers en RAM qui est effacé à chaque redémarrage. Ajoutez une ligne à /etc/fstab :

echo "tmpfs /var/log tmpfs defaults,noatime,nosuid,nodev,mode=0755,size=50M 0 0" >> /etc/fstab

Maintenant tout ce qui se trouve sous /var/log réside en mémoire et se vide à chaque redémarrage. Redémarrez une fois pour que les services en cours rouvrent leurs fichiers de log dans le nouveau disque RAM :

reboot

Étape 3 : Désactiver le swap

Si le serveur a le swap activé, le noyau peut pousser des pages de RAM - incluant possiblement des clés actives - sur le disque quand la mémoire vient à manquer. Sur une machine sans logs, vous voulez que la mémoire reste en mémoire. Désactivez le swap maintenant et gardez-le désactivé au fil des redémarrages :

swapoff -a
sed -i.bak '/\sswap\s/s/^/#/' /etc/fstab

Beaucoup de petits VPS sont livrés sans aucun swap - dans ce cas swapoff -a ne fait tout simplement rien, ce qui est très bien.

Étape 4 : Désactiver les core dumps

Si un programme plante, systemd-coredump peut écrire un core dump - un instantané de la mémoire de ce programme - sur le disque sous /var/lib/systemd/coredump/. Désactivez-le :

mkdir -p /etc/systemd/coredump.conf.d
printf '[Coredump]Storage=none' > /etc/systemd/coredump.conf.d/99-nolog.conf
systemctl daemon-reload

Étape 5 : Désactiver l'historique du shell et de l'éditeur

Votre shell enregistre chaque commande dans ~/.bash_history, et les éditeurs laissent leurs propres traces (~/.viminfo, ~/.lesshst). Pointez-les tous vers /dev/null pour que rien ne soit jamais écrit. Pour l'utilisateur actuel :

ln -sf /dev/null ~/.bash_history
ln -sf /dev/null ~/.viminfo
ln -sf /dev/null ~/.lesshst

Ensuite, empêchez bash de conserver un fichier d'historique pour chaque shell de connexion sur le système, afin que les autres comptes soient couverts eux aussi :

printf 'unset HISTFILEexport HISTSIZE=0' > /etc/profile.d/00-nohistory.sh

Si vous avez d'autres comptes utilisateur, répétez les trois lignes ln -sf pour chacun de leurs répertoires personnels également.

Étape 6 : Gardez la protection contre les intrusions active - vous n'êtes pas aveugle

Un mythe répandu veut que désactiver les logs vous laisse sans défense. Ce n'est pas forcément le cas. fail2ban - l'outil qui bannit une IP après des connexions échouées répétées - peut lire directement depuis le journal systemd, qui réside désormais en RAM. Vous conservez donc une protection automatique contre la force brute tout en n'écrivant rien sur le disque. Installez-le :

apt install fail2ban -y

Pointez-le vers le journal en créant /etc/fail2ban/jail.local avec :

[DEFAULT]
backend = systemd

Puis redémarrez-le et, par-dessus, fermez les portes évidentes :

systemctl restart fail2ban

• Clés SSH uniquement. Désactivez la connexion par mot de passe dans /etc/ssh/sshd_config (PasswordAuthentication no) et redémarrez ssh. Une clé ne peut pas être devinée comme un mot de passe.
• Pare-feu fermé par défaut. Gardez ufw n'autorisant que SSH et votre port WireGuard (51820/udp), tout le reste étant refusé.
• Mises à jour de sécurité automatiques. Installez unattended-upgrades ; ses journaux résident maintenant dans le /var/log en RAM, donc ils disparaissent aussi au redémarrage.

Étape 7 : Vérifier que rien ne persiste

Redémarrez une dernière fois, reconnectez-vous, et vérifiez les quatre choses que vous avez changées :

mount | grep /var/log
swapon --show
journalctl --no-pager | wc -l
ls -lh /var/log

Vous devriez voir /var/log monté comme tmpfs, aucun swap actif, un journal presque vide, et un /var/log neuf et quasi vide. À partir de là, le serveur ne conserve pratiquement rien sur le disque à propos de ce qui transite par lui.

Quand vous pourriez vouloir conserver quelques logs

Le sans-logs n'est pas automatiquement le bon choix pour tout le monde. Si le serveur fait plus que faire tourner votre VPN personnel - héberge un site, gère le trafic d'autres personnes - vous pourriez vouloir un peu d'historique pour repérer les problèmes. Bonne nouvelle : la configuration ci-dessus conserve déjà des logs à court terme en RAM (dans le journal et le tmpfs /var/log), donc vous avez une visibilité sur la session en cours tout en n'écrivant rien de permanent sur le disque. Si vous avez besoin de plus, augmentez RuntimeMaxUse à l'étape 1 ou la size du tmpfs à l'étape 2. Ajustez l'agressivité à la manière dont vous utilisez réellement la machine.