Dans quelle mesure SSH ForceCommand est-il sécurisé sur un hôte de saut?


8

J'ai la configuration suivante sur mon réseau:

Internet <--> Bastion <--> Local Network

J'ai plusieurs utilisateurs et chaque utilisateur est affecté à une machine spécifique. Ou en d'autres termes: chaque utilisateur ne doit avoir accès qu'à l'un de ces serveurs. Par exemple: User1 -> Machine1, User2 -> Machine2 et ainsi de suite.

Ces utilisateurs se connecteront de l'extérieur de mon réseau et j'ai envisagé de nombreuses options pour transférer leurs connexions via mon hôte bastion vers mon réseau.

Finalement, j'ai opté pour Match Blocks et forcecommand.

Ainsi, mon / etc / ssh / sshd_config sur bastion ressemble à ceci:

Match User User1
        ForceCommand ssh User1@Machine1 $SSH_ORIGINAL_COMMAND

User1 se connecte à l'hôte bastion qui établit automatiquement une connexion avec Machine1.

Pour autant que je comprenne ForceCommand, User1 n'aura aucun accès réel à l'hôte bastion, car toutes ses opérations seront d'abord gérées par le bloc de correspondance, donc redirigées vers Machine1. Mais est-ce vraiment vrai? Est-ce déjà suffisant pour être une configuration sécurisée? L'utilisateur est de toute façon emprisonné sur Machine1, il n'aura donc pas beaucoup de possibilités.


2
N'oubliez pas d'obtenir IPv6, vous n'aurez donc plus besoin de boîtes de saut.
Michael Hampton

Réponses:


6

La façon dont j'utilise un hôte bastion utilise ProxyCommandet le -Wdrapeau comme dans cet exemple:

ssh -o ProxyCommand='ssh -W %h:%p user@bastion' user@machine

J'utilise cette approche pour des raisons de sécurité. La communication entre le client et la machine cible est chiffrée et authentifiée de bout en bout, ce qui signifie qu'elle reste sécurisée même si le bastion est compromis. Un hôte bastion compromis ne fournirait pas moins de sécurité que l'utilisation de ssh de bout en bout sans bastion.

Il élimine également la nécessité d'utiliser n'importe quel transfert d'agent. Le client peut utiliser l'authentification basée sur une clé d'abord pour accéder au bastion, puis à nouveau pour accéder à l'hôte cible sans qu'aucun de ceux-ci ne dispose d'une connexion d'agent qui pourrait être utilisée pour abuser de la clé privée présente sur le client.

Cela limite également le code dont je dépend sur l'hôte bastion. Je n'ai pas besoin d'exécuter de commande sur le bastion. -Wimplique aucun indicateur de commande ainsi qu'une seule redirection de port, cette redirection de port est tout ce que l'hôte bastion doit autoriser.

Avec cette approche à l'esprit, ma recommandation serait de verrouiller l'hôte bastion autant que possible en n'utilisant que les commandes de la structure ci-dessus.

Le ~/.ssh/authorized_keysfichier sur le bastion pourrait appartenir à root (comme tous les répertoires sur le chemin de la racine du système de fichiers à celui-ci), cela réduit le risque qu'il puisse être modifié même si quelqu'un réussissait à s'introduire en tant qu'utilisateur non privilégié sur le hôte bastion.

Dans authorized_keyspeuvent être limités les privilèges du client en utilisant les options command, no-agent-forwarding, no-pty, no-user-rc, no-X11-forwarding, ainsi que l' utilisation permitopenau port limite réexpéditions d'autoriser l' accès au port 22 sur l'hôte que cet utilisateur est autorisé à accéder.

En principe, cette approche serait sécurisée même si plusieurs utilisateurs partagent le même nom d'utilisateur sur le bastion. Mais vous obtenez un peu plus de séparation en utilisant des noms d'utilisateurs distincts sur le bastion.


Il semble que vous invoquiez le binaire ssh au bastion lui-même. Dans ce cas, si le bastion est compromis, l'attaquant peut remplacer ce binaire ssh par un qui viderait vos communications. Puisque vous n'utilisez pas de chemin dans votre ligne de commande (comme / usr / bin / ssh), l'attaquant peut le faire même sans avoir un accès root sur bastion, en le plaçant dans votre répertoire personnel et en changeant PATH (ou en utilisant un alias ssh). Juste mes 2 cents.
George Y.

1
@GeorgeY. Vous avez tort. Les deux sshcommandes s'exécutent sur le client. Et c'est exactement le point de le faire comme je le suggère. L'approche mentionnée dans la question se déroulerait sshsur le bastion, ce qui ouvre un large éventail de vecteurs d'attaque possibles.
kasperd

2

Vous pouvez facilement contourner ForceCommand car il intervient lorsque votre shell a démarré. Cela signifie essentiellement que votre fichier shell rc est traité en premier, puis ForceCommand si vous l'autorisez à y arriver. Simple exec shdans votre fichier shell rc va générer un autre shell et laisser ForceCommand attendre jusqu'à ce que vous quittiez ce shell.

Donc, en bout de ligne; si l'utilisateur peut en quelque sorte éditer son shell rc (par exemple .bashrc) via ftp, sftp, scp ou d'une autre manière, alors ForceCommand n'est pas vraiment quelque chose sur lequel s'appuyer.


Ok je vais essayer ça. Aucun de ces utilisateurs n'a accès à l'hôte bastion pour effectuer des modifications de fichier. Ils n'ont accès qu'à l'hôte de destination où ils peuvent modifier le .bashrc. Mais j'espère que je vous comprends bien, que vous vous rapportez à l'hôte bastion?
Dr.Elch

1
Ce n'est un problème que si l'utilisateur est en mesure de se connecter au système pour modifier le fichier bashrc. Si ces comptes ne sont pas destinés à être utilisés normalement, ils peuvent appartenir à root, le répertoire et presque tous les fichiers appartenant à root. Vérifiez les règles relatives à la propriété des fichiers .ssh, mais certaines choses comme .bashrc n'ont pas besoin d'être inscriptibles.
mc0e

Oui @ Dr.Elch en effet, je parlais de sécurité sur l'hôte bastion. Vous pouvez également envisager; chattr + i pour définir le shell rc comme immuable et empêcher les utilisateurs de changer de shell pour eux-mêmes en option.
Hrvoje Špoljar

1

J'imagine que c'est bien la plupart du temps, mais le problème avec la sécurité, c'est les choses auxquelles personne n'a encore pensé. Il n'y a aucune garantie.

Comme par exemple pendant longtemps, personne n'avait trop réfléchi à la façon dont les fonctions pouvaient être créées à partir de variables d'environnement dans bash, mais récemment, les gens ont réalisé que cela pouvait être inversé, et l'un des effets de cela était que ForceCommand pouvait être contourné (à moins implémenté dans le fichier authorized_keys) si le shell des utilisateurs était bash. Bash a été corrigé, et j'espère que votre version est à jour, mais des choses comme cela se produisent.

Je ne suis pas tout à fait sûr que la définition de ForceCommand soit effectivement la même chose que la définition de ces commandes dans les fichiers authorized_keys. Je n'ai pas regardé ça de près.


0

Rendez le sshd .bashrcdétenu par root:usergrpmais toujours lisible par le sshd qui s'exécute lorsque l'utilisateur se connecte. Définissez perms / owner sur $ HOME en interdisant la création de nouveaux fichiers par l'utilisateur. De cette façon, root contrôle le contenu de .bashrc, le laissant faire ce dont il a besoin, mais l'utilisateur lui-même ne peut pas modifier ces paramètres ou les autorisations sur les fichiers / répertoires qui leur permettraient indirectement de modifier le contenu de .bashrc.


que diriez-vous de ne pas attribuer de répertoire personnel à cet utilisateur sur le serveur bastion?
Dr.Elch

Où allez-vous stocker les .bashrccommandes que vous souhaitez exécuter ensuite?
Marcin

Sur le serveur bastion, la commande forcée qui transmet la connexion à l'hôte réel est définie dans sshd_config. Par conséquent, je n'ai pas besoin de spécifier d'autres commandes sur cet hôte bastion, non?
Dr.Elch

0

J'ai une autre idée. Pour chaque utilisateur sur le serveur bastion, vous pouvez définir leur shell dans / etc / passwd comme un script bash qui exécute simplement ssh user1 @ machine1, user2 @ machine2, etc. De cette façon, vous vous assurerez qu'ils n'ont pas de shell sur le serveur lui-même et qu'ils se connectent simplement à la machine à laquelle ils doivent se connecter.


L'avez-vous essayé? Cette idée m'est venue à l'esprit et je me demande dans quelle mesure cela fonctionne.
William Pietri
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.