Serveur bastion :utilisez le transfert TCP plutôt que de placer la clé privée sur le serveur

Utilisez ProxyCommand ou ProxyJump

Je recommanderais d'utiliser ProxyCommand (ou encore mieux ProxyJump car la syntaxe est plus simple mais nécessite openssh 7.3+ je pense 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 poste 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 faire 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 de votre hôte Bastion et srvC est un alias de votre serveur C. Dans le HostName vous devez mettre soit des adresses IP, soit un vrai nom de domaine complet pour vos hôtes. Pour les utilisateurs, vous devez mettre à jour le User pour le bon nom de connexion 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 n'est pas en cours d'exécution, il fonctionnera également et vous demandera chaque mot de passe clé.

Déploiement des clés publiques

Bien sûr, vous devez déployer le public les clés du bastion et du 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 après avoir vérifié 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), puis remplacez :

ProxyJump bastion

par

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

D'après ce que j'ai compris, c'est similaire.

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

-Se connecter à l'hôte bastion

ssh bast

-Connecter le serveur d'application depuis le bastion

 ssh [email protected] -p PORT

Piratage !

Vous pouvez, eh 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 qu'il est considéré comme nuisible.

• Pourquoi ?

  • Expliquons tout à l'envers :lorsque vous vous connectez à l'hôte bastion, votre glorieux agent ssh est transféré. Cela signifie que le socket sera configuré de manière à ce que quelqu'un puisse utiliser ces données de socket pour accéder à vos serveurs. Imaginez que votre serveur bastion est compromis, si quelqu'un a des autorisations suffisantes sur votre serveur Linux, il utilisera simplement vos informations de socket. De ce fait, tout votre serveur est accessible. Je sais que la fenêtre de compromis est très petite car elle dépend de combien de temps vous êtes connecté à l'hôte bastion. Mais voulez-vous vraiment courir 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 :

[[email protected] tmp]# ll
total 12
drwx------  2 bastion bastion 4096 Sep  7 17:35 ssh-mKX88v0Vlo

Ouvrons le fichier temporaire

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

Voyons les 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 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 ce qui se passe quand le client sera connecté au serveur distant ? voyons :

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 sur le socket et l'adresse IP

Nous devons maintenant voler les informations de socket pendant que la session de l'hôte bastion est ouverte . Oh, nous avons également besoin de l'IP du serveur de destination , alors utilisez simplement netstat :

netstat -tn

La étape finale pour utiliser le fichier socket transmis

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

Vérifier 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 un hôte bastion, 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.
• Utiliser 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 sudo à l'utilisateur
• Surveillez votre serveur
• Mettre à jour votre serveur pour les correctifs de sécurité

Plus d'informations, voir mon blog. De plus, j'ai quelques captures d'écran, elles peuvent donc vous être utiles.

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

• Les clés seront dans l'agent ssh sur votre ordinateur portable.
• Vous vous connectez au bastion, authentifié via l'agent.
• À partir de là, connectez-vous à votre hôte cible, avec la demande d'authentification transférée vers votre ordinateur portable .

Avantage :il n'y a pas de clés stockées sur le bastion qui peuvent être utilisées à mauvais escient.

J'espère que ça aide :)