security - vagrant virtualbox

¿Vagabundo inseguro por defecto?

Question

EDIT 2 : TL; DR: la respuesta fue sí en 2013, pero este error se ha solucionado

Al seguir las instrucciones de Getting Started en vagrantup.com, parezco terminar con una máquina virtual que acepta conexiones SSH en el puerto 2222 para que cualquiera pueda obtener acceso raíz a mi VM y leer el directorio de trabajo de mi host utilizando las credenciales predeterminadas (nombre de usuario) = password = vagrant o vagrant_insecure_private_key).

¿Es esto cierto? En caso afirmativo, ¿por qué no se considera una vulnerabilidad de seguridad enorme? ¿Qué pasa si hubiera copiado datos confidenciales a la VM?

EDITAR : y para aquellos que piensan que alguien en Internet puede leer tus fuentes y ejecutar código arbitrario en tu VM no es tan malo, te recomiendo leer la sección "Breaking out" en esta publicación del blog http://blog.ontoillogical.com/blog/2012/10/31/breaking-in-and-out-of-vagrant/

En pocas palabras: ejecutar Vagrant "como se pretende" también puede permitir que cualquiera entre en su host / máquina de desarrollo (por ejemplo, usando un gancho git post-commit malicioso).

Answer 1

A partir de Vagrant 1.2.3, el valor predeterminado es vincularse a localhost en lugar de a la interfaz pública, evitando el problema de la conexión externa.

Answer 2

Escribí este proveedor de shell en línea simple para intercambiar las authorized_keys con mi id_rsa.pub. Una vez aprovisionado, insegcure_private_key no se puede usar para autenticarse.

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 3

He planteado esto como un problema en el repositorio github para vagabundo. El desarrollador ha dicho que solucionará el problema con los puertos reenviados que están disponibles externamente. Sin embargo, el desarrollador no acepta el problema relacionado con el compromiso del entorno de host desde la máquina virtual. Creo que están peligrosamente equivocados.

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

Salir de la vm es más fácil de lo que sugiere la publicación de blog vinculada. No tienes que depender de ganchos de git para comprometer el host, simplemente colocas un código de rubí arbitrario en el archivo de Vagrant.

Me gustaría ejecutar vagabundo en una caja de arena de VM si pudiera. Como no puedo, me las arreglo con un firewall.

Es una buena idea tener reglas de aprovisionamiento para agregar una clave ssh segura y eliminar la clave no segura y la contraseña predeterminada.

Answer 4

La respuesta corta es SÍ .

¿Por qué?

Al construir cajas base Vagrant (manualmente o utilizando herramientas como Veewee para automatizar), los constructores siguen las especificaciones de cajas base vagabundas que definen lo siguiente:

1. Usuario root y vagrant vagabundo como contraseña
2. Autenticación de clave pública (sin contraseña) para el vagrant usuario.

El proyecto Vagrant proporciona un par de claves inseguras para la Autenticación de clave pública SSH para que vagrant ssh funcione.

Debido a que todos tienen acceso a la clave privada, cualquiera puede usar la clave privada para iniciar sesión en sus VM (supongamos que conocen su IP de la máquina host, el puerto es 2222 como reglas de reenvío en forma predeterminada).

NO es seguro OOTB. Sin embargo, puede eliminar la clave de confianza de ~vagrant/.ssh/authorized_keys y agregar la suya propia, cambiar la contraseña de vagrant y root , y luego se considera relativamente segura.

Actualizar

Desde Vagrant 1.2.3, el puerto reenviado SSH se enlaza a 127.0.0.1 por lo que solo se permiten las conexiones locales [GH-1785].

Actualización importante

Desde Vagrant 1.7.0 ( PR # 4707 ) Vagrant reemplazará el par de claves ssh inseguro por defecto con par de llaves generado aleatoriamente en el primer vagrant up .

Ver en CHANGELOG : se usa el par de claves inseguro por defecto, Vagrant lo reemplazará automáticamente con un par de llaves generado aleatoriamente en el primer vagrant up . GH-2608

Answer 5

Me gustaría explicar por qué Vagrant no es necesariamente tan inseguro como podría pensar.

Me gustaría comenzar diciendo que, como estoy seguro de que la mayoría de ustedes ya saben, es necesario mantener el acceso abierto al cuadro Vagrant debido a la forma en que se comparten estos cuadros. Por esa razón, creo que la preocupación principal de seguridad no es cambiar las credenciales predeterminadas después de que se descargue la caja. Ejecutar dicha máquina en modo puente permitiría que alguien en la red ingrese con credenciales predeterminadas.

Me parece que la idea detrás de estos cuadros es que cualquiera puede descargarlo y asegurarlo una vez que esté en su poder. Mi instalación vagabunda reemplaza las claves predeterminadas con una nueva clave ssh generada aleatoriamente. No estoy seguro de si esto se está haciendo con un complemento, sin embargo, tengo curiosidad por saber si el sudo sin contraseña y la contraseña predeterminada también presentan un riesgo de seguridad.

Answer 6

Solo quería agregar que hay un complemento Vagrant que resuelve este problema: vagrant-rekey-ssh . Cambia la contraseña predeterminada de la máquina virtual y elimina la clave insegura SSH.