По умолчанию бродяга небезопасна?

EDIT 2: TL; DR: ответ был да в 2013 году, но этот недостаток был исправлен

Следуя инструкциям Getting Started на vagrantup.com, я, кажется, получаю виртуальную машину, принимающую SSH-соединения на порту 2222, чтобы каждый мог получить root-доступ к моей виртуальной машине и прочитать рабочий каталог моего хоста по умолчанию credentials (username = password = vagrant или vagrant_insecure_private_key).

Это правда? Если да, то почему это не считается уязвимой уязвимостью безопасности? Что делать, если я скопировал конфиденциальные данные в виртуальную машину?

EDIT: и для тех, кто считает, что кто-то из Интернета, способный читать ваши источники и выполнять произвольный код на вашей виртуальной машине, не так уж плохо, я рекомендую прочитать раздел "Разбивка" в этом сообщение в блоге http://blog.ontoillogical.com/blog/2012/10/31/breaking-in-and-out-of-vagrant/

Вкратце: запуск Vagrant "по назначению" также может позволить любому пользователю проникнуть на ваш компьютер для хоста/разработки (например, с помощью вредоносного git коммита post-commit).

ОТВЕТЫ

Ответ 1

Короткий ответ ДА.

Почему?

При создании базовых блоков Vagrant (вручную или с использованием таких инструментов, как Veewee для автоматизации), строители следуют спецификации бродячих базовых ящиков, которые определяют следующее:

  • Пользователь root и vagrant использует бродягу как пароль
  • Аутентификация открытого ключа (без пароля) для пользователя vagrant.

Проект Vagrant предоставляет небезопасную пару ключей для аутентификации открытого ключа SSH, чтобы vagrant ssh работал.

Поскольку каждый имеет доступ к закрытому ключу, любой пользователь может использовать закрытый ключ для входа в ваши виртуальные машины (предположим, что они знают ваш IP-адрес хост-машины, по умолчанию 2222 используется как правила пересылки).

Это НЕ безопасный OOTB. Однако вы можете удалить доверенный ключ из ~vagrant/.ssh/authorized_keys и добавить свой собственный, изменить пароль для vagrant и root, тогда он считается относительно безопасным.

Обновление

Так как Vagrant 1.2.3, по умолчанию переадресованный порт SSH привязывается к 127.0.0.1, поэтому разрешены только локальные соединения [GH-1785].

ВАЖНО Обновить

Так как Vagrant 1.7.0 (PR # 4707) Vagrant заменит незащищенную ssh-клавиатуру по умолчанию со случайно сгенерированной ключевой парой на первом vagrant up.

Смотрите в CHANGELOG: используется небезопасная ключевая пара по умолчанию, Vagrant автоматически заменит ее случайным образом сгенерированной ключевой парой на первом vagrant up. GH-2608

Ответ 2

Я поднял это как проблему в репозитории github для бродяг. Разработчик сказал, что они исправят проблему, если пересылаемые порты будут доступны извне. Однако разработчик не согласен с проблемой компрометации среды хоста из виртуальной машины. Я думаю, что они опасно ошибаются.

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

Извлечение из vm проще, чем предполагает связанное сообщение в блоге. Вам не нужно зависеть от git hooks для компрометации хоста, вы просто помещаете произвольный код ruby ​​в файл Vagrant.

Я мог бы использовать бродягу в песочнице VM, если бы мог. Поскольку я не могу, я делаю это с брандмауэром.

Хорошая идея иметь правила обеспечения для добавления безопасного ключа ssh и удаления небезопасного ключа и пароля по умолчанию.

Ответ 3

Я написал это простую встроенную программу обеспечения очереди, чтобы поменять ее с помощью id_rsa.pub. После инициализации insecure_private_key не может использоваться для аутентификации.

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

Ответ 4

Как и в случае с Vagrant 1.2.3, по умолчанию используется привязка к localhost вместо открытого интерфейса, что позволяет избежать проблемы с внешним подключением.

Ответ 5

Просто хотел добавить, что есть плагин Vagrant, который решает эту проблему: vagrant-rekey-ssh. Он изменяет пароль по умолчанию для VM и удаляет небезопасный SSH-ключ.

Ответ 6

Я хотел бы объяснить, почему Вагрант не обязательно такой же неуверенный, как вы думаете.

Я хотел бы начать, сказав, что, поскольку я уверен, что большинство из вас уже известно, необходимо поддерживать открытый доступ к коробке Vagrant из-за способа совместного использования этих ящиков. По этой причине я считаю, что основная проблема безопасности не изменяет учетные данные по умолчанию после загрузки окна. Запуск такой машины в мостовом режиме позволит кому-то из сети подключиться к ssh с учетными данными по умолчанию.

Мне кажется, что идея этих ящиков заключается в том, что любой может загрузить ее и защитить ее, когда она находится в их распоряжении. Моя бродячая установка заменяет ключи по умолчанию на новый, случайно сгенерированный ключ ssh. Я не уверен, что это делается с плагином, однако мне любопытно узнать, не содержит ли пароль без пароля и пароль по умолчанию риск для безопасности.