Tunneling SSH et techniques de transfert de ports

La redirection de port locale (ssh -L local_port:destination_host:destination_port user@ssh_server) associe un port sur votre machine locale. Le trafic envoyé vers ce port local passe par la connexion SSH chiffrée jusqu’au serveur SSH, qui se connecte ensuite à la destination. Votre application locale communique avec localhost tandis que SSH achemine le trafic en toute sécurité vers la destination distante.

Un cas d’usage courant de la redirection de port locale consiste à accéder à une base de données interne située derrière un pare-feu. Avec ssh -L 5432:db.internal:5432 user@bastion, votre client PostgreSQL local se connecte à localhost:5432. L’hôte bastion achemine ce trafic vers le serveur de base de données interne, qui est autrement inaccessible depuis Internet.

La redirection de port distante (ssh -R remote_port:local_host:local_port user@ssh_server) associe un port sur le serveur SSH distant. Lorsque des clients externes se connectent à ce port distant, le trafic revient par le tunnel SSH jusqu’à votre machine locale. Cela vous permet de rendre accessible au monde entier un service exécuté localement, par l’intermédiaire d’un serveur exposé sur Internet.

La redirection distante est particulièrement utile lorsque votre machine se trouve derrière un NAT et ne peut pas recevoir directement de connexions entrantes. En créant un tunnel inversé vers un serveur public, vous permettez à des clients externes d’atteindre votre service local par l’intermédiaire de ce serveur public. Cette technique est également utilisée par certains outils d’accès à distance et systèmes de gestion d’appareils IoT.

La redirection de port dynamique (ssh -D local_port user@ssh_server) crée un proxy SOCKS5 sur votre machine locale. Toute application compatible avec SOCKS5 peut acheminer son trafic par l’intermédiaire de ce proxy, qui semblera provenir du serveur SSH. Cela achemine efficacement votre navigation à travers le réseau distant, ce qui est utile pour accéder à des ressources soumises à des restrictions géographiques ou contourner les filtres du réseau local.

Les tunnels inversés sont puissants, mais ils introduisent des risques de sécurité. Si un serveur autorise GatewayPorts, les ports redirigés à distance deviennent accessibles depuis Internet public, et pas uniquement depuis localhost. Un attaquant qui compromet une machine dotée d’un tunnel inversé peut potentiellement atteindre des services internes. Les organisations doivent surveiller les tunnels inversés non autorisés et restreindre GatewayPorts dans les configurations SSH.

La configuration du serveur SSH contrôle les possibilités de tunnellisation. AllowTcpForwarding contrôle si la redirection de port locale et distante est autorisée. AllowStreamLocalForwarding contrôle la redirection de sockets Unix. Définir ces options sur no désactive la tunnellisation pour tous les utilisateurs ; vous pouvez également les restreindre par utilisateur ou par groupe. La désactivation des redirections inutiles réduit la surface d’attaque.

SSH permet de créer des interfaces réseau tun pour effectuer une tunnellisation IP complète (ssh -w). SSH devient ainsi un VPN léger dans lequel des paquets IP entiers sont acheminés par tunnel, et pas uniquement des connexions TCP spécifiques. PermitTunnel doit être activé sur le serveur. Bien que cette approche soit moins efficace qu’un logiciel VPN dédié, elle ne nécessite aucun logiciel supplémentaire et s’appuie sur l’infrastructure SSH existante.

Le multiplexage des connexions SSH (paramètres ControlMaster et ControlPath) réutilise une connexion SSH existante pour les nouvelles sessions. Cela accélère considérablement les connexions suivantes vers le même hôte, ce qui est particulièrement utile dans les environnements scriptés. Les tunnels peuvent également rester actifs entre plusieurs sessions SSH grâce à la connexion partagée.

Les administrateurs réseau peuvent détecter la tunnellisation SSH grâce à des schémas de trafic inhabituels : des connexions TCP de longue durée sur le port 22, des volumes de données étonnamment élevés pour des connexions censées transporter uniquement du trafic de terminal, ou des connexions vers des destinations connues comme sensibles après leur établissement. L’inspection approfondie des paquets ne permet pas de voir le contenu SSH, mais l’analyse des métadonnées peut signaler un comportement de tunnellisation suspect.

Pour tout usage autorisé, documentez tous les tunnels et leurs objectifs. Utilisez -N (aucune commande) avec les tunnels pour éviter d’ouvrir inutilement un interpréteur de commandes, et -f (arrière-plan) pour les exécuter sans bloquer votre terminal. Pour les tunnels persistants, utilisez AutoSSH ou l’activation de socket de systemd, qui redémarre automatiquement le tunnel si la connexion est interrompue.

Vous souhaitez exposer votre serveur de développement local (exécuté sur le port 3000) sur Internet par l’intermédiaire d’un serveur SSH public. Quel type de redirection devez-vous utiliser ?

Récapitulatif de la tunnellisation SSH : la redirection locale (-L) permet d’accéder de manière sécurisée aux services internes depuis votre machine, la redirection distante (-R) expose des services locaux par l’intermédiaire d’un serveur public, la redirection dynamique (-D) crée un proxy SOCKS5 pour acheminer le trafic au niveau des applications, la redirection tun permet de créer un VPN IP complet, et AllowTcpForwarding sur le serveur contrôle ces fonctionnalités.