Comment désactiver le transfert de port local SSH?


20

J'ai un serveur sous Ubuntu et le démon OpenSSH. Appelons cela S1.

J'utilise ce serveur depuis des machines clientes (appelons l'un d'eux C1) pour effectuer un tunnel inverse SSH en utilisant un transfert de port distant, par exemple:

ssh -R 1234:localhost:23 login@S1

Sur S1, j'utilise le fichier sshd_config par défaut. D'après ce que je peux voir, toute personne disposant des informations d'identification appropriées {login, pwd} sur S1 peut se connecter à S1 et effectuer un transfert de port distant et un transfert de port local. De telles informations d'identification pourraient être un certificat dans le futur, donc si je comprends bien, toute personne qui récupère le certificat peut se connecter à S1 depuis n'importe où (pas nécessairement C1) et ainsi créer des redirections de ports locaux.

Pour moi, autoriser le transfert de port local est trop dangereux, car cela permet de créer une sorte de proxy public. Je cherche un moyen de ne désactiver que les transferts.

J'ai essayé ce qui suit, mais cela désactive le transfert local et distant:

AllowTcpForwarding No

J'ai aussi essayé ce qui suit, cela ne permettra que -L à SX: 1. C'est mieux que rien, mais ce n'est toujours pas ce dont j'ai besoin, c'est une option "aucune".

PermitOpen SX:1

Je me demande donc s'il existe un moyen pour interdire à tous les transmetteurs de port locaux d'écrire quelque chose comme:

PermitOpen none:none

La suite est-elle une bonne idée?

PermitOpen localhost:1

donc, comme toujours, allons à la racine de ceci: quel est votre vrai problème, pourquoi voulez-vous configurer quelque chose comme ceci pour les appareils mobiles / embarqués, que voulez-vous résoudre?
Akira

Le problème à résoudre ici est de pouvoir ouvrir une session Telnet, depuis Internet, vers un périphérique mobile / intégré connecté à Internet, en tenant compte du fait que le périphérique peut être doté d’un NAT ou d’un pare-feu, et donc inaccessible. de l'Internet.
SCO

telnet .. pour quoi? pour percer des trous dans le pare-feu google pour 'stun'
akira

Réponses:


15

N'importe qui avec des identifiants de connexion peut créer sa propre instance de sshd, s'exécutant sur un port aléatoire et autoriser ce qu'il veut, y compris les redirections locales -L:

% /usr/sbin/sshd -d -f mysshd.config -p 12345

si vous ne faites pas confiance aux utilisateurs pour qu'ils fassent quelque chose avec votre machine, vous ne devriez pas leur permettre de se connecter en premier lieu.

(d'ailleurs, le drapeau -D est aussi un peu "problématique par rapport au proxy")


Eh bien, je suppose que je peux configurer un compte très restrictif à cette fin (par exemple, coller l’utilisateur à son emplacement, aucune liste, aucune navigation dans le système de fichiers), de sorte qu’il ne puisse pas démarrer et sshd (ou installer et démarrer un fichier binaire sshd). Le fait est que les clients sont supposés être des périphériques intégrés. Mais comme ils vont probablement incorporer des certificats et que leur mémoire flash peut être vidée, il est possible que les certificats fuient, permettant ainsi à quiconque de se connecter à S1.
SCO

Utiliser ChrootDirectory pour cet utilisateur particulier fera l'affaire, essayera ça!
SCO

1
Dans allowed_keys, définissez command="/sbin/nologin". Cela devrait les empêcher d’exécuter des commandes sur le serveur.
Justis

L'affirmation "toute personne disposant d'informations d'identification de connexion peut afficher son propre <que ce soit>" est fausse sshpeut être utilisé pour se connecter à des comptes dont le shell de connexion est strictement limité et qui ne le permettent pas. La redirection de port est un trou de sécurité dans ces coquilles restreintes. En plus d'exécuter une commande autorisée, l'utilisateur peut créer des tunnels.
Kaz

3
Extrait de la sshd_configpage de manuel: notez que la désactivation du transfert TCP n'améliore pas la sécurité sauf si les utilisateurs se voient également refuser l'accès au shell , car ils peuvent toujours installer leurs propres redirecteurs. (Souligné par moi).
Kaz

17

Une autre solution serait d’autoriser uniquement la redirection de port à des utilisateurs spécifiques:

De SSH: Le guide définitif

Le transfert de port peut être activé ou désactivé globalement dans sshd. Cela se fait avec le mot-clé de configuration au niveau du serveur AllowTcpForwarding dans / etc / sshd_config. Le mot clé peut avoir la valeur oui (valeur par défaut, activation du transfert) ou non (désactivation du transfert):

# SSH1, SSH2, OpenSSH
AllowTcpForwarding no

De plus, SSH2 offre les options suivantes:

# SSH2 only
AllowTcpForwardingForUsers
AllowTcpForwardingForGroups

La syntaxe de ceux-ci est la même que pour les options AllowUsers et AllowGroups. [Section 5.5.2.1, "Contrôle d'accès au compte"] Ils spécifient une liste d'utilisateurs ou de groupes autorisés à utiliser le transfert de port; le serveur refuse d'honorer les demandes de redirection de port pour quiconque. Notez qu'ils font référence au compte cible de la session SSH, pas au nom d'utilisateur du client (qui est souvent inconnu).

...

Il est important de réaliser que les directives de cette section n'empêchent pas le transfert de port, à moins que vous ne désactiviez également les connexions interactives et que vous limitiez les programmes pouvant être exécutés du côté distant. Sinon, les utilisateurs avertis peuvent simplement exécuter leur propre application de transfert de port sur la session SSH. Ces paramètres à eux seuls pourraient constituer un moyen de dissuasion suffisant dans une communauté non technique, mais ils n'arrêteront pas une personne qui sait ce qu'elle fait.


1
Fondamentalement, je n'aurai qu'un seul utilisateur mis en disponibilité sur S1. AFAIU, dans ce cas précis, utiliser AllowTcpForwardingForUsers / AllowTcpForwardingForGroups ne fera pas l'affaire, non? Interdire la connexion interactive est une bonne idée car cela empêchera les utilisateurs de démarrer des fichiers binaires. Mais tout client sera toujours autorisé à utiliser la syntaxe -L, n'est-ce pas? Donc, pour le moment, les meilleures options seraient: 1 / Désactiver la connexion interactive, 2 / PermitOpen avec un faux nom d’hôte: port. Ai-je oublié quelque chose ?
SCO

Le meilleur moyen de vérifier cela serait d’essayer la configuration.
Christian

Je ne vois pas ces options dans le logiciel gratuit OpenSSH. Un Google pour AllowTcpForwardingForUsersrévèle qu'il est configuré dans un sshd2_config, qui est utilisé dans certains programmes commerciaux. Voir une des réponses à: superuser.com/questions/384643/…
Kaz

^ OpenSSH a des Matchblocs dans la configuration. Vous pouvez Matchsur les utilisateurs et les groupes, et inclure le AllowTcpForwardingdans.
Kaz

2

Il existe maintenant une option pour autoriser uniquement le transfert local / distant.

AllowTcpForwarding Spécifie si le transfert TCP est autorisé. Les options disponibles sont “oui” ou “tout” pour autoriser le transfert TCP, “non” pour empêcher tout transfert TCP, “local” pour autoriser le transfert local (du point de vue de ssh (1)) ou “distant” pour autoriser le transfert à distance. expédition seulement . La valeur par défaut est "oui". Notez que la désactivation du transfert TCP n'améliore pas la sécurité sauf si les utilisateurs se voient également refuser l'accès au shell, car ils peuvent toujours installer leurs propres redirecteurs.

Ainsi, comme indiqué précédemment, vous devez également définir le shell sur nologin.


0

Ma solution à ce problème a été d'ajouter: PermitOpen fo.local: 80 dans la section principale de sshd_config.

Ceci refuse simplement toute demande de transfert local en dehors de fo.local: 80.


0

Je cherche un moyen de ne désactiver que les transferts

Si je vous ai bien compris, vos utilisateurs disposent d’un accès complet au shell, mais vous ne voulez pas qu’ils puissent ouvrir des connexions vers le reste du réseau.

La "redirection de port locale" autorisée par SSH n'est qu'un des moyens possibles de le faire. D' autres incluent le lancement d' une instance de socat, netcatou tout autre nombre d'outils.

Le meilleur moyen de contrôler les connexions entrantes et sortantes sous Linux est Netfilter, alias IPTables.

Il possède un module spécial appelé owner ( ipt_owner) qui vous permet de faire correspondre différentes caractéristiques du créateur de paquets, pour les paquets générés localement. Il est valable dans les chaînes OUTPUTet POSTROUTING.

Vous pouvez l'utiliser pour refuser les paquets sortants générés par certains groupes d'utilisateurs, interdisant ainsi tout type de transfert de port, pas seulement l' -Loption SSH.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.