TCP Forwarding, definition ?

Support Debian
#1

Bonjour,

Je pose une question certainement très conne, mais au lieu de penser que c’est cela je préfère en avoir la certitude.

J’ai pu voir dans la documentation ssh :

[quote]AllowTcpForwarding
Specifies whether TCP forwarding is permitted. The default is “yes”. Note that disabling TCP forwarding does not improve security unless users are also denied shell access, as they can always install their own forwarders.[/quote]

Le Port Forwarding est bien identique au NAT ? La possibilité de redirigé un port par exemple le port 22 d’une connexion entrante (connexion publique donc) vers une machine spécifique (coté privé) sur le même port. Le port Triggering est la même chose, sauf que le port de redirection est différent (connexion via le port 6374 redirigé vers le 22, par exemple).

Déjà est-ce que je me trompe ??

Si non, pourquoi dans la documentation il est spécifié que le TCP Forwarding ne permet pas une sécurité plus accrue ?

Dans quel cas l’utilise t-on avec ssh ? Pour ma part c’est directement via le Firewall.

Merci d’éclairer ma lanterne :slightly_smiling: et désolé si la question est un peu conne…

#2

Le port-forwarding en SSH permet de faire un tunnel TCP entre ta machine cliente et le serveur.

Exemple simple :

  • sur le serveur, tu as un service qui écoute sur localhost:1234 => impossible d’y accéder depuis l’extérieur
  • tu fais un port-forwarding en SSH depuis serveur:1234 vers client:2345 => tu peux maintenant accéder au service sur ton client “comme si tu y étais” tout en bénéficiant de l’authentification et du chiffrage de connexion de SSH

Note bien qu’il n’y a aucune obligation d’utiliser le même numéro de port sur le client que sur le serveur (bref, ça n’a pas grand chose à voir avec le port-forwarding/triggering du NAT).

Quant à la question sur la sécurité, ça paraît assez évident que si les utilisateurs ont un accès shell sur ton serveur, ils peuvent utiliser un autre logiciel de forwarding que SSH s’ils le souhaitent. Donc dans ce cas, désactiver le port-forwarding SSH n’apporte aucune sécurité supplémentaire.

Un exemple plus concret de port-forwarding SSH :

  • X serveurs, chacun avec un MySQL qui écoute sur localhost:3306
  • si je veux utiliser phpMyAdmin pour accéder à ces X MySQL, j’ai plusieurs solutions :
    • installer phpMyAdmin sur chaque serveur => problèmes de maintenance et de sécurité (phpMyAdmin est accessible publiquement, connexions non chiffrées sauf si SSL, authentification fragile par utilisateur / mot de passe)
    • un seul phpMyAdmin sur ma machine locale, et faire écouter les MySQL sur toutes les interfaces pour pouvoir y accéder de l’extérieur => maintenance simplifiée, mais pas mieux niveau sécurité
    • un seul phpMyAdmin sur ma machine locale, et faire du port-forwarding pour “rapatrier” le port MySQL du serveur sur lequel je veux bosser vers ma machine locale => la connexion bénéficie de l’authentification (clés asymétriques 16kbit :mrgreen:) et du chiffrage SSH, le port MySQL du serveur n’est pas accessible de l’extérieur, un seul point de maintenance pour phpMyAdmin, bref… que du bonheur.
#3

Non, le “TCP port forwarding” de SSH n’est pas du NAT.

Le NAT au sens large consiste à modifier les adresses et/ou ports source et/ou destination des paquets IP puis à les retransmettre. Dans le cas du NAT la redirection de port comme sur une box internet (aussi appelée “port forwarding”, d’où probablement ta confusion), consiste à modifier l’adresse destination des paquets entrants qui ont un port destination donné, et éventuellement le port destination aussi, et à faire les transformations inverses sur les paquets sortants. En général la redirection de port par NAT ne modifie pas l’adresse source du client, donc le serveur final voit l’adresse du client originel.

Le “TCP port forwarding” de SSH est plutôt un relais de port TCP, avec deux connexions TCP bien distinctes : une première entre le client originel et le client (ou serveur) SSH qui ouvre le port, et une seconde entre le serveur (ou client) SSH et le serveur final. Il n’y a pas de transformation des paquets TCP/IP. Les données passent d’une connexion à l’autre à travers le tunnel SSH. Le serveur final ne voit que l’adresse du serveur SSH, pas celle du client originel. Cela ne fonctionne que pour les ports TCP, alors que le NAT peut fonctionner avec à peu près n’importe quel protocole IP.

Quant à la sécurité, c’est simple : le fait d’ouvrir un shell à distance entre le client et le serveur SSH permet de faire passer des données entre l’un et l’autre via l’entrée et la sortie standard, donc même sans utiliser le “port forwarding” de SSH il ne devrait pas être difficile de faire un relais de port.

#4

Coucou,

Désolé de ne pas avoir donné de nouvelles plus tôt.

Merci pour ces explications, je pense que cela sera complètement claire quand j’aurai mis en application avec un petit peu de documentation à coté :smiley:

Merci à vous deux