Désactiver le forwarding TCP SSH
Force AllowTcpForwarding no afin que les clients SSH authentifiés ne puissent pas tunneliser de connexions TCP arbitraires à travers le serveur.
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 TCP (ssh -L/-R/-D) permet à un utilisateur authentifié de transformer le serveur SSH en relais : il peut servir à rebondir vers des hôtes internes autrement inaccessibles, contourner la segmentation pare-feu ou monter un tunnel dérobé pour l'exfiltration. Sauf besoin opérationnel, désactiver le forwarding TCP supprime cette capacité de tunnelisation et de mouvement latéral.
Ce que vérifie Pavois
Pavois lit la valeur effective via sshd -T, après tous les Include, drop-ins de /etc/ssh/sshd_config.d/ et blocs Match. Un bloc Match peut réactiver le forwarding pour des utilisateurs précis ; seule la sortie résolue le révèle, contrairement à une lecture de /etc/ssh/sshd_config.
describe command('sshd -T') do
its('stdout') { should match(/^allowtcpforwarding\s+no$/i) }
endComment vérifier qu’elle est appliquée
Exécutez sshd -T | grep -i '^allowtcpforwarding'. La sortie attendue est allowtcpforwarding no.
Inspecter et investiguer
Les demandes de forwarding refusées sont journalisées via journalctl -u sshd ou dans /var/log/secure, par exemple des lignes mentionnant refused local port forward lorsqu'un client tente un tunnel.
Remédiation
Le plan harden de Pavois écrit la directive sshd_setting AllowTcpForwarding no 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 | allowtcpforwarding |
|---|---|
| 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
Avant d'appliquer, vérifiez qu'aucun flux ne dépend des tunnels SSH : accès base de données via ssh -L, proxy SOCKS via ssh -D, rappels en remote-forward via ssh -R, ou outils transitant par un hôte de rebond. Si l'un est nécessaire, ouvrez une exception ciblée via un bloc Match plutôt que de réactiver globalement. Les connexions shell simples ne sont pas affectées et le rechargement maintient les sessions en cours.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| PCI DSS | 2.2.6 | support | 4.0.1 | moyenne |
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.