Vagrant non protetto per impostazione predefinita?

Question

EDIT 2: TL; DR: la risposta era sì nel 2013, ma questo difetto è stato risolto

Seguendo le istruzioni introduttive sulla vagrantup.com, mi sembra di finire con una macchina virtuale che accetta le connessioni SSH sulla porta 2222 in modo che chiunque possa ottenere l'accesso di root alla mia VM e leggere la mia directory di lavoro host utilizzando le credenziali predefinite (username = password = vagrant o vagrant_insecure_private_key).

È vero? In caso affermativo, perché non è considerata una vulnerabilità di sicurezza spalancata? Cosa succede se ho copiato dati sensibili sulla VM?

EDIT: e per coloro che pensano che chiunque su Internet di essere in grado di leggere le vostre fonti e l'esecuzione di codice arbitrario sulla macchina virtuale non è così male, vi consiglio di leggere la sezione "Breaking out" in questo post del blog http://blog.ontoillogical.com/blog/2012/10/31/breaking-in-and-out-of-vagrant/

In breve: l'esecuzione di Vagrant "come previsto" può anche consentire a chiunque di penetrare nel computer host/sviluppo (ad esempio, utilizzando un hook git post-commit dannoso).

Answer 1

La risposta breve è SI.

Perché?

Quando si costruisce scatole di base Vagrant (manualmente o tramite strumenti come Veewee per automatizzare), costruttori seguono la vagrant base boxes specifications che definisce la seguente:

1. utente root e vagrant uso vagabondo come password di
2. pubblica autenticazione chiave (senza password) per l'utente vagrant.

Il progetto Vagrant fornisce un valore non sicuro key pair per l'autenticazione della chiave pubblica SSH in modo che vagrant ssh funzioni.

Perché ognuno ha accesso alla chiave privata, chiunque può utilizzare la chiave privata per accedere al tuo VM (supponiamo che conoscono il vostro IP della macchina host, la porta è per default 2222 come regole di inoltro in atto.)

NON è sicuro OOTB. Tuttavia, puoi rimuovere la chiave fidata da ~vagrant/.ssh/authorized_keys e aggiungere la tua, cambiare la password per vagrant e root, quindi è considerata relativamente sicura.

Aggiornamento

Dal Vagrant 1.2.3, per impostazione predefinita SSH porta inoltrata si lega a 127.0.0.1 in modo che solo le connessioni locali sono permessi [GH-1785].

importante aggiornamento

Dal Vagrant 1.7.0 (PR #4707) Vagrant sostituirà la coppia di chiavi SSH insicuro default con coppia di chiavi generata casualmente sulla prima vagrant up.

Vedere in CHANGELOG: viene utilizzata la coppia di chiavi non protetta di default, Vagrant la sostituirà automaticamente con una coppia di chiavi generata casualmente sul primo vagrant up. GH-2608

Answer 2

Ho sollevato questo come problema sul repository github per vagabondo. Lo sviluppatore ha dichiarato che risolverà il problema con le porte inoltrate che sono disponibili esternamente. Lo sviluppatore tuttavia non accetta il problema relativo alla compromissione dell'ambiente host dalla VM. Penso che siano pericolosamente sbagliati.

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

scoppio della VM è più facile che il post sul blog collegato suggerisce. Non devi dipendere dai git git per compromettere l'host, basta inserire un codice ruby ​​arbitrario nel file Vagrant.

Mi piacerebbe correre in una sandbox VM se potessi. Dal momento che non posso, mi accontento di un firewall.

È consigliabile disporre di regole di provisioning per aggiungere una chiave ssh protetta e per rimuovere la chiave non protetta e la password predefinita.

Answer 3

A partire da Vagrant 1.2.3 l'impostazione predefinita è il collegamento a localhost anziché all'interfaccia pubblica, evitando il problema di connessione esterna.

Answer 4

Ho scritto questo semplice gestore di shell inline per scambiare i authorized_keys con il mio id_rsa.pub. Una volta eseguito il provisioning, la chiave insecure_private_ non può essere utilizzata per l'autenticazione.

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 

Answer 5

Volevo solo aggiungere che esiste un plug-in Vagrant che risolve questo problema: vagrant-rekey-ssh. Cambia la password predefinita della VM e rimuove la chiave SSH non sicura.

Answer 6

Vorrei spiegare perché Vagrant non è necessariamente così insicuro come si potrebbe pensare.

Vorrei iniziare dicendo che, come sono sicuro che molti di voi sono già a conoscenza, è necessario mantenere l'accesso aperto alla casella Vagrant a causa del modo in cui queste caselle vengono condivise. Per questo motivo, credo che il principale problema di sicurezza non stia cambiando le credenziali predefinite dopo il download della scatola. L'esecuzione di una macchina di questo tipo in modalità a ponte consentirebbe a qualcuno sulla rete di eseguire l'accesso con credenziali predefinite.

Mi sembra che l'idea alla base di queste scatole sia che chiunque può scaricarlo e proteggerlo una volta che è in loro possesso. La mia vagabonda installazione sostituisce le chiavi predefinite con una nuova chiave ssh generata casualmente. Non sono sicuro se questo viene fatto con un plugin, tuttavia sono curioso di sapere se il sudo e la password di default senza password presentano anche un rischio per la sicurezza.