Désactiver le transfert X11 dans SSH
Interdit au serveur SSH de tunneliser des sessions graphiques vers le client (X11Forwarding no). Le protocole X11 n'isole pas ses clients entre eux : un serveur compromis qui reçoit un affichage transféré peut lire les frappes clavier et le contenu de l'écran de l'utilisateur sur son poste de travail.
Vérifié sur l’état résolu en cours d’exécution (ex. sshd -T, sysctl, systemctl show), attrape les drop-ins et Include qu’une lecture de fichier raterait. Réserve : runtime ≠ persistance ; une valeur correcte maintenant peut ne pas survivre à un redémarrage.
Ce que vérifie Pavois
Pavois exécute sshd -T et exige la ligne résolue x11forwarding no. sshd -T affiche la configuration réellement appliquée par le démon, après toutes les directives Include et tous les drop-ins de /etc/ssh/sshd_config.d/. Le point est important ici, car distributions et paquets de bureau livrent couramment des drop-ins positionnant X11Forwarding yes : ne scruter que /etc/ssh/sshd_config déclarerait l'hôte conforme alors que le démon transfère bel et bien X11.
describe command('sshd -T') do
its('stdout') { should match(/^x11forwarding\s+no$/i) }
endComment vérifier qu’elle est appliquée
Exécutez sshd -T | grep -i x11forwarding en root. Sortie attendue :
x11forwarding no
De bout en bout : ssh -X user@hote 'echo $DISPLAY' doit afficher une ligne vide, et le client signale X11 forwarding request failed on channel 0.
Inspecter et investiguer
Au niveau par défaut LogLevel INFO, une demande X11 refusée n'est pas journalisée. Passez le démon en LogLevel VERBOSE et sshd consigne, dans /var/log/auth.log (Debian/Ubuntu), /var/log/secure (RHEL) ou journalctl -u ssh :
sshd[1234]: X11 forwarding disabled in server configuration file.
Cette ligne est le moyen le plus simple de recenser les utilisateurs et les traitements qui réclament encore un affichage avant d'appliquer la règle à tout le parc.
Remédiation
Le plan de durcissement Pavois utilise la ressource sshd_setting pour forcer la directive x11forwarding à no dans le drop-in Pavois sous /etc/ssh/sshd_config.d/. Comme ce drop-in est lu après les fichiers de la distribution, il l'emporte sur un X11Forwarding yes livré par un paquet. Le fichier est validé par sshd -t -f <fichier>, puis tout changement déclenche un reload de ssh.service.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| directive | x11forwarding |
|---|---|
| notify | action: reload, service: ssh.service |
| resource | sshd_setting |
| value | no |
| verify | sshd -t -f %{path} |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Avec le transfert X11 actif, toute compromission root du serveur donne accès au $DISPLAY transféré de chaque utilisateur connecté : enregistrement des frappes et capture d'écran sur son poste, sans compter la socket d'écoute supplémentaire que sshd ouvre pour l'affichage mandataire. Avant d'appliquer, vérifiez qu'aucun administrateur ne lance d'outil graphique via SSH (virt-manager, xclock, installateurs, consoles constructeur) et qu'aucun script ne suppose $DISPLAY défini ; les solutions de repli sont un client local, une console web, ou une exception explicite par hôte. Le reload ne casse pas les sessions en cours : seules les nouvelles perdent l'affichage.