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

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

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

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

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

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

6 70
security vagrant

6 ответов:

короткий ответ:да.

почему?

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

  1. пользователей root и vagrant использовать залетный пароль
  2. аутентификация с открытым ключом (без пароля) для пользователя 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.

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

95

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

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

выход из виртуальной машины проще, чем предлагает связанный пост в блоге. Вы не приходится зависеть от Git-крючков, чтобы скомпрометировать хост, вы просто помещаете произвольный код ruby в файл Vagrant.

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

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

10

Я написал эту простую встроенную оболочку provisioner для замены authorized_keys с моим id_rsa.паб. После подготовки 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
9

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

7

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

1

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

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

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

0