Désactiver le forwarding SSH
Force DisableForwarding yes, l'interrupteur maître qui désactive tout forwarding SSH (TCP, X11, agent, StreamLocal, tun).
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.
Pavois vérifie la configuration effective, l’état résolu et réellement appliqué, pas un fichier. Les scanners basés fichier (OVAL/SCAP, Lynis) ratent les Include, drop-ins et défauts runtime ; ce check voit ce qui est réellement en vigueur.
Un mapping est une référence croisée vers l’endroit où chaque norme situe cette exigence, ancrée et recoupée, pas une affirmation d’équivalence. Un check réussi est une preuve vers ces références, comment le lire.
Pourquoi cette règle
Le forwarding SSH permet à un client authentifié de tunneliser un trafic arbitraire à travers le serveur : le forwarding TCP peut servir à rebondir vers le réseau interne ou contourner la segmentation pare-feu, le forwarding X11 et agent peut fuiter des identifiants vers un poste compromis. Sauf besoin opérationnel, DisableForwarding yes ferme tous les types de forwarding en une seule directive, supprimant un puissant vecteur de mouvement latéral et d'exfiltration.
Ce que vérifie Pavois
Pavois lit la valeur effective via sshd -T. DisableForwarding interagit avec AllowTcpForwarding, X11Forwarding, AllowAgentForwarding et des surcharges Match par utilisateur ; seule la sortie résolue montre le résultat réel après tous les includes et drop-ins, ce qu'une lecture brute de /etc/ssh/sshd_config ne peut pas faire.
describe command('sshd -T') do
its('stdout') { should match(/^disableforwarding\s+yes$/i) }
endComment vérifier qu’elle est appliquée
Exécutez sshd -T | grep -i '^disableforwarding'. La sortie attendue est disableforwarding yes.
Inspecter et investiguer
Les tentatives de forwarding refusées sont journalisées dans /var/log/auth.log (Debian/Ubuntu) ou journalctl -u sshd (famille RHEL), par exemple des lignes mentionnant refused local port forward lorsqu'un client tente d'ouvrir un tunnel.
Remédiation
Le plan harden de Pavois écrit la directive sshd_setting DisableForwarding yes dans un drop-in géré, valide avec sshd -t, puis recharge le service ssh. Appliquez-le avec pavois harden apply.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| directive | disableforwarding |
|---|---|
| notify | action: reload, service: ssh.service |
| resource | sshd_setting |
| value | yes |
| 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
Avant d'appliquer, vérifiez qu'aucun flux de travail ne dépend des tunnels SSH : forwarding de ports ssh -L/-R/-D, git/rsync via des hôtes de rebond, applications graphiques en X11 (ssh -X), ou ForwardAgent pour les connexions chaînées. Si l'un d'eux est nécessaire, ouvrez une exception ciblée via un bloc Match plutôt que d'autoriser le forwarding globalement. Ce changement n'affecte pas les connexions shell simples et le rechargement maintient les sessions en cours.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 5.1.8, 5.1.10 | direct | per OS, see the benchmark table | haute |
Chaque référence est une référence croisée ancrée dans le benchmark amont et recoupée avec le SCAP Security Guide et ansible-lockdown, pas une affirmation d’équivalence. Direct = une exigence prescriptive au niveau de la ligne ; support = une famille de contrôle abstraite (NIST) vers laquelle le check apporte une preuve. Comment lire un mapping.