Vagrant standardmäßig unsicher?

EDIT 2 : TL; DR: Die Antwort war ja im Jahr 2013, aber dieser Fehler wurde behoben

Wenn ich den Anweisungen für die ersten Schritte auf vagrantup.com folge, habe ich anscheinend eine virtuelle Maschine, die SSH-Verbindungen an Port 2222 akzeptiert, sodass jeder Root-Zugriff auf meine VM erhalten und mein Host-Arbeitsverzeichnis mit den Standardanmeldeinformationen (Benutzername) lesen kann = password = vagrant oder vagrant_insecure_private_key).

Ist das wahr? Wenn ja, warum wird es nicht als klaffende Sicherheitslücke angesehen? Was wäre, wenn ich vertrauliche Daten auf die VM kopiert hätte?

BEARBEITEN : und für diejenigen, die glauben, dass jeder im Internet in der Lage ist, Ihre Quellen zu lesen und beliebigen Code auf Ihrer VM auszuführen, ist es empfehlenswert, den Abschnitt "Ausbruch" in diesem Blog-Beitrag unter http: //blog.ontoillogical zu lesen. com / blog / 2012/10/31 / Einbruch und Ausstieg aus dem Landstreicher /

Kurz gesagt: Wenn Sie Vagrant "wie beabsichtigt" ausführen, kann jeder in Ihren Host / Entwicklungscomputer eindringen (z. B. mithilfe eines böswilligen Git-Post-Commit-Hooks).

Die kurze Antwort lautet JA .

Warum?

Beim Erstellen von Vagrant-Basisboxen (manuell oder mithilfe von Tools wie Veewee zur Automatisierung) befolgen die Builder die Spezifikationen für Vagrant-Basisboxen, die Folgendes definieren:

1. Benutzer rootund vagrantVerwendung vagrant als Passwort
2. Authentifizierung mit öffentlichem Schlüssel (ohne Kennwort) für den Benutzer vagrant.

Das Vagrant-Projekt bietet ein unsicheres Schlüsselpaar für die Authentifizierung mit öffentlichem SSH-Schlüssel, damit dies vagrant sshfunktioniert.

Da jeder Zugriff auf den privaten Schlüssel hat, kann sich jeder mit dem privaten Schlüssel bei Ihren VMs anmelden (vorausgesetzt, er kennt Ihre IP-Adresse des Hostcomputers, Port ist standardmäßig 2222 als Weiterleitungsregel vorhanden.)

Es ist NICHT sicher OOTB. Sie können jedoch den vertrauenswürdigen Schlüssel entfernen ~vagrant/.ssh/authorized_keysund Ihren eigenen hinzufügen, das Kennwort für vagrantund ändern und es rootdann als relativ sicher betrachten.

Aktualisieren

Seit Vagrant 1.2.3 ist der weitergeleitete SSH-Port standardmäßig an 127.0.0.1 gebunden, sodass nur lokale Verbindungen zulässig sind [GH-1785].

WICHTIGES Update

Seit Vagrant 1.7.0 ( PR # 4707 ) ersetzt Vagrant zuerst das standardmäßige unsichere ssh-Schlüsselpaar durch zufällig generiertes Schlüsselpaar vagrant up.

Siehe im CHANGELOG : Das standardmäßige unsichere Schlüsselpaar wird verwendet. Vagrant ersetzt es zuerst automatisch durch ein zufällig generiertes Schlüsselpaar vagrant up. GH-2608

Ich habe dies als Problem im Github-Repository für Vagabunden angesprochen. Der Entwickler hat angekündigt, das Problem zu beheben, da die weitergeleiteten Ports extern verfügbar sind. Der Entwickler akzeptiert das Problem bezüglich der Gefährdung der Host-Umgebung durch die VM jedoch nicht. Ich denke, sie sind gefährlich falsch.

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

Das Ausbrechen aus dem VM ist einfacher als der verlinkte Blog-Beitrag vermuten lässt. Sie müssen sich nicht auf Git-Hooks verlassen, um den Host zu gefährden. Sie fügen einfach beliebigen Ruby-Code in die Vagrant-Datei ein.

Ich würde Vagrant in einer VM-Sandbox ausführen, wenn ich könnte. Da ich nicht kann, komme ich mit einer Firewall aus.

Es ist eine gute Idee, Bereitstellungsregeln zu haben, um einen sicheren SSH-Schlüssel hinzuzufügen und den unsicheren Schlüssel und das Standardkennwort zu entfernen.

Ich habe diesen einfachen Inline-Shell-Provisioner geschrieben, um die autorisierten Schlüssel mit meiner id_rsa.pub auszutauschen. Nach der Bereitstellung kann der unsichere_private_key nicht mehr zur Authentifizierung verwendet werden.

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

Ab Vagrant 1.2.3 wird standardmäßig anstelle der öffentlichen Schnittstelle an localhost gebunden, um das Problem der externen Verbindung zu vermeiden.

Ich wollte nur hinzufügen, dass es ein Vagrant-Plugin gibt, das dieses Problem löst: vagrant-rekey-ssh . Es ändert das Standardkennwort der VM und entfernt den unsicheren SSH-Schlüssel.

Ich möchte erklären, warum Vagrant nicht unbedingt so unsicher ist, wie Sie vielleicht denken.

Zunächst möchte ich sagen, dass es, wie die meisten von Ihnen sicher bereits wissen, notwendig ist, den offenen Zugang zur Vagrant-Box aufrechtzuerhalten, da diese Boxen gemeinsam genutzt werden. Aus diesem Grund glaube ich, dass das Hauptsicherheitsbedenken darin besteht, die Standardanmeldeinformationen nach dem Herunterladen der Box nicht zu ändern. Wenn Sie einen solchen Computer im Bridged-Modus ausführen, kann sich jemand im Netzwerk mit Standardanmeldeinformationen anmelden.

Es scheint mir, dass die Idee hinter diesen Boxen ist, dass jeder es herunterladen und sichern kann, sobald es in seinem Besitz ist. Meine vagabundierende Installation ersetzt Standardschlüssel durch einen neuen, zufällig generierten SSH-Schlüssel. Ich bin nicht sicher, ob dies mit einem Plugin durchgeführt wird, bin jedoch gespannt, ob das passwortlose sudo und das Standardkennwort ebenfalls ein Sicherheitsrisiko darstellen.