Question Existe-t-il un moyen sûr de stocker les mots de passe utilisés pour ssh par un script?


Donc d’abord, je sais que je devrais utiliser l’authentification de clé avec SSH. Pas besoin de m'expliquer ça.

Le problème ici est que j'ai un (gros) groupe de serveurs et que je dois avoir un script capable de connecter chacun de ceux-ci.

J'utilise une clé d'authentification chaque fois que je le peux, mais ce n'est pas possible sur tous les serveurs (je n'ai aucun contrôle sur cela). Donc, SSH avec login, ou parfois telnet.

Donc, pour certains, je viens de stocker les mots de passe dans une base de données, et mon script va le prendre en cas de besoin. Le problème est que cela ne semble pas vraiment sûr de le faire. Y a-t-il un moyen de le rendre un peu plus sûr?

Vous aimez un moyen spécifique de le stocker?


16
2018-02-09 13:27


origine


Variables Env. Dupliquer de SO: stackoverflow.com/a/4410137/2579527 - Travis Stoll
Les variables d'environnement @ TravisStoll ne sont pas sécurisées. - Jenny D
Je crains que, pour votre configuration, stocker les mots de passe dans une base de données soit aussi sécurisé que possible. Vous pouvez en faire une base de données chiffrée, comme un fichier keepass (je pense qu’il existe au moins un module perl pour accéder à la base de données keepass), mais vous devrez quand même enregistrer le mot de passe quelque part dans la base de données, si vous ne voulez pas entrer. c'est chaque fois que vous invoquez votre script. Peut-être un peu mieux IFF vous entrez simplement le mot de passe principal chaque fois que vous appelez votre script. - Isaac
Même si vous utilisez des clés d’authentification SSH au lieu de mots de passe, c’est une garantie de sécurité - quiconque peut voler votre base de mots de passe pourrait tout simplement voler votre clé privée. Vous pouvez chiffrer votre clé privée de la même manière que votre base de données de mots de passe, mais comme votre script doit déverrouiller la clé (ou la base de données de mots de passe), il est toujours vulnérable aux attaques. Utiliser des mots de passe au lieu de clés augmente légèrement votre vulnérabilité car cela ouvre plus de possibilités pour voler le mot de passe, mais même utiliser des clés au lieu de mots de passe n'est pas une sécurité parfaite. - Johnny
"parfois telnet" semble impliquer que le mot de passe sera parfois même transféré en clair sur le fil ...? - Hagen von Eitzen


Réponses:


Si votre script peut se connecter à l'un de ces serveurs, toute personne ayant accès au script (ou à un accès privilégié à la machine sur laquelle le script est exécuté) peut se connecter à l'un de ces serveurs.

Si le script doit fonctionner de manière autonome, tous les paris sont ouverts. La réponse ici est non, il n'y a pas de moyen absolument sûr de stocker les mots de passe dans un tel environnement. Il n'y a pas de coffre-fort et manière pratique de faire n'importe quoi.

Au lieu d'essayer d'éviter l'inévitable, vous devriez vous concentrer sur la défense en profondeur.

Fristement, bien sûr, vous devriez protéger les mots de passe de manière adéquate. Cela signifie généralement les conserver dans un fichier séparé de votre script et configurer des autorisations restrictives du système de fichiers. C'est à peu près tout ce que vous pouvez faire sur ce front, du point de vue de la sécurité.

D'autres mesures peuvent très certainement ajouter obscurité au processus. Le chiffrement des mots de passe obligera l'attaquant à rechercher la clé de déchiffrement. L'utilisation d'une sorte de système de stockage protégé par le système d'exploitation protège généralement contre autres utilisateurs accéder à votre clé (elle n’offre donc aucun avantage par rapport aux autorisations du système de fichiers, mais elle est complexe à attaquer et à utiliser). Ces mesures vont retard une attaque, mais certainement pas l'empêcher contre un attaquant déterminé.


Maintenant traiter les mots de passe comme public pour un moment. Que pouvez-vous faire pour limiter les dégâts?

Une solution ancienne et testée consiste à limiter ce que ces informations d'identification peuvent faire. Sur un système UNIX, un bon moyen de le faire est de: configurer un utilisateur distinct pour votre script et limiter les capacités de cet utilisateur, à la fois sur les serveurs accédant et accédés. Vous pouvez limiter les capacités de l'utilisateur sur le niveau SSH, sur le niveau de la coquille ou éventuellement en utilisant un Mécanisme de contrôle d'accès obligatoire comme SELinux.

Vous voudrez peut-être aussi envisager de déplacer la logique de script dans les serveurs. De cette façon, vous obtenez une interface plus petite, plus facile à contrôler, et surtout à ...

Moniteur. Surveillez toujours l'accès aux serveurs. De préférence, enregistrez l'authentification et les commandes exécutées sur un N'ajouter que le journal. N'oubliez pas de surveiller les modifications du fichier de script à l'aide de auditd, par exemple.


Bien entendu, bon nombre de ces mécanismes ne sont pas utiles si vous n’avez aucun contrôle sur les serveurs, comme le suggère votre question. Si tel est le cas, je vous conseillerais de entrer en contact avec les personnes administrant les serveurs et leur faire connaître votre script et les pièges de sécurité potentiels.


24
2018-02-09 15:44





La réponse courte est non.

La réponse longue est: non, il n'y a pas de moyen complètement sûr. (Cela inclut les variables d'environnement, qui peuvent être consultées par d'autres sur le serveur.) Le plus proche que vous puissiez obtenir est de les stocker dans un format crypté - Keepass, un fichier crypté par GPG ou quelque chose du genre. Mais à un moment donné, vous devez déchiffrer le mot de passe pour que votre script puisse l'utiliser et vous serez alors vulnérable.

En d'autres termes, vous devez examiner de près la sécurité en profondeur, à la fois sur le serveur à partir duquel le script est exécuté, sur le réseau et sur les serveurs cibles.


14
2018-02-09 14:12



Je ne suis pas sûr que ce soit un NON définitif. Sa session est sécurisée. le système de fichiers peut être sécurisé, avec les autorisations appropriées définies; Donc, s'il peut obtenir des éléments du système de fichiers (un mot de passe stocké) et les transférer par le biais de stdin à la commande ssh, il devrait être d'accord, n'est-ce pas? S'il vous plaît voir les liens que j'ai donné sur un autre commentaire ci-dessus. Qu'est-ce que tu penses? - pgr
S'il les achemine via stdin, il y a une vulnérabilité. Avec vos suggestions, la sécurité sera meilleure, mais ce ne sera pas complètement le cas. Surtout que certaines sessions se font par telnet. - Jenny D


Vous pouvez chiffrer les mots de passe de votre base de données avec un deuxième mot de passe et stocker ce mot de passe sur une autre machine (3ème). Vous devez également mettre en place un système dans lequel le script qui doit extraire les mots de passe de la base de données connecte cette 3ème machine pour obtenir le mot de passe de déchiffrement. , déchiffre le mot de passe dans la base de données avec le mot de passe qu'il a obtenu de la 3ème machine et fait son travail.

Bien sûr, cela n’ajoute pas vraiment de sécurité supplémentaire, un attaquant disposant de privilèges suffisants pourrait également simplement demander le mot de passe à la 3ème machine.

Mais le fait est qu’une tierce partie pourrait contrôler la troisième machine, par exemple. votre patron, votre responsable de la sécurité ou la 3ème partie contrôlant les serveurs que vous ne contrôlez pas.

De cette façon, vous pouvez leur dire, s'ils ont un problème, si vous quittez votre travail et qu'ils ne font pas confiance au gars qui vous remplace, ou s'ils veulent juste que vos scripts cessent d'accéder à leurs machines, ils peuvent débrancher la 3ème machine, et vos scripts n'auront plus accès aux mots de passe.


0
2018-02-24 10:39