Insécurité vagrante par défaut?

EDIT 2 : TL; DR: la réponse était oui en 2013, mais ce défaut a été corrigé

En suivant les instructions de mise en route sur vagrantup.com, il semble que je me retrouve avec une machine virtuelle qui accepte les connexions SSH sur le port 2222 afin que tout le monde puisse obtenir un access root à ma VM et lire mon répertoire de travail hôte = mot de passe = vagrant ou vagrant_insecure_private_key).

Est-ce vrai? Si oui, pourquoi n’est-il pas considéré comme une faille de sécurité béante? Et si j’avais copié des données sensibles sur la machine virtuelle?

EDIT : et pour ceux qui pensent que n’importe qui sur Internet est capable de lire vos sources et d’exécuter du code arbitraire sur votre VM n’est pas si mal, je vous recommande de lire la section “Breaking Out” de ce blog http: //blog.ontoillogical. com / blog / 2012/10/31 / effraction /

En résumé, exécuter Vagrant «comme prévu» peut également permettre à quiconque d’entrer par effraction dans votre ordinateur hôte / de développement (par exemple, en utilisant un hook post-commit malveillant).

La réponse courte est OUI .

Pourquoi?

Lors de la création de boîtes de base Vagrant (manuellement ou à l’aide d’outils tels que Veewee pour automatiser), les constructeurs suivent les spécifications des boîtes de base erratiques qui définissent les éléments suivants:

  1. Utilisateur root et vagrant utiliser le mot de passe comme mot de passe
  2. Authentification par clé publique (sans mot de passe) pour l’utilisateur vagrant .

Le projet Vagrant fournit une paire de clés non sécurisée pour l’authentification par clé publique SSH afin que vagrant ssh fonctionne.

Comme tout le monde a access à la clé privée, tout le monde peut utiliser la clé privée pour se connecter à vos ordinateurs virtuels (supposez qu’ils connaissent votre adresse IP de la machine hôte, le port étant par défaut 2222 en tant que règles de transfert).

Ce n’est pas sécurisé OOTB. Cependant, vous pouvez supprimer la clé de confiance de ~vagrant/.ssh/authorized_keys et append les vôtres, changer le mot de passe pour vagrant et root , puis il est considéré comme relativement sûr.

Mettre à jour

Depuis que Vagrant 1.2.3, par défaut, le port SSH transmis se lie à 127.0.0.1, seules les connexions locales sont autorisées [GH-1785].

Mise à jour importante

Depuis Vagrant 1.7.0 ( PR # 4707 ), Vagrant remplacera la paire de clés ssh non sécurisée par défaut par une paire de clés générées aléatoirement sur le premier vagrant up .

Voir dans le CHANGELOG : la paire de touches non sécurisée par défaut est utilisée, Vagrant le remplacera automatiquement par une paire de clés générées aléatoirement sur le premier vagrant up . GH-2608

Je l’ai soulevé comme un problème sur le repository github pour vagrants. Le développeur a déclaré qu’il résoudrait le problème avec les ports transférés disponibles en externe. Le développeur n’accepte cependant pas le problème de compromission de l’environnement hôte de la VM. Je pense qu’ils sont dangereusement faux.

https://github.com/mitchellh/vagrant/issues/1785

Sortir de la vm est plus facile que ne le suggère la publication de blog liée. Vous n’avez pas besoin de dépendre de git hooks pour compromettre l’hôte, vous venez de mettre du code Ruby arbitraire dans le fichier Vagrant.

Si je le pouvais, je courrais vagrant dans un sandbox VM. Comme je ne peux pas, je me débrouille avec un pare-feu.

Il est conseillé d’avoir des règles de provisioning pour append une clé ssh sécurisée et de supprimer la clé non sécurisée et le mot de passe par défaut.

J’ai écrit ce simple fournisseur de shell en ligne pour échanger les authorized_keys avec mon id_rsa.pub. Une fois provisionnée, la clé insecure_private_key ne peut pas être utilisée pour s’authentifier.

 VAGRANTFILE_API_VERSION = "2" Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| # ... config.ssh.shell = "bash -c 'BASH_ENV=/etc/profile exec bash'" # avoids 'stdin: is not a tty' error. config.ssh.private_key_path = ["#{ENV['HOME']}/.ssh/id_rsa","#{ENV['HOME']}/.vagrant.d/insecure_private_key"] config.vm.provision "shell", inline: < <-SCRIPT printf "%s\n" "#{File.read("#{ENV['HOME']}/.ssh/id_rsa.pub")}" > /home/vagrant/.ssh/authorized_keys chown -R vagrant:vagrant /home/vagrant/.ssh SCRIPT end 

À partir de Vagrant 1.2.3, la valeur par défaut est de se connecter à localhost au lieu de l’interface publique, en évitant le problème de connexion externe.

Je voulais juste append qu’il existe un plugin Vagrant qui résout ce problème: vagrant-rekey-ssh . Il modifie le mot de passe par défaut de la machine virtuelle et supprime la clé SSH non sécurisée.

J’aimerais expliquer pourquoi Vagrant n’est pas nécessairement aussi peu sûr que vous pourriez le penser.

Je voudrais commencer par dire que, comme je suis sûr que la plupart d’entre vous le savent déjà, il est nécessaire de maintenir un access ouvert à la boîte Vagrant en raison de la façon dont ces boîtes sont partagées. Pour cette raison, je pense que le principal problème de sécurité ne concerne pas la modification des informations d’identification par défaut après le téléchargement de la boîte. L’exécution d’une telle machine en mode pont permettrait à une personne du réseau d’entrer ssh avec les informations d’identification par défaut.

Il me semble que l’idée derrière ces boîtes est que tout le monde peut le télécharger et le sécuriser une fois en sa possession. Mon installation errante remplace les clés par défaut par une nouvelle clé ssh générée aléatoirement. Je ne suis pas sûr que cela se fasse avec un plugin, mais je suis curieux de savoir si le mot de passe sudo et le mot de passe par défaut sans mot de passe présentent également un risque de sécurité.