방랑자는 기본적으로 안전하지 않습니까?

방랑자는 기본적으로 안전하지 않습니까?

---

편집 2 : TL; DR : 대답은 2013 년에 예 였지만이 결함이 수정되었습니다.

vagrantup.com의 시작하기 지침을 따르면 누구나 내 VM에 대한 루트 액세스 권한을 얻고 기본 자격 증명 (사용자 이름)을 사용하여 내 호스트 작업 디렉터리를 읽을 수 있도록 포트 2222에서 SSH 연결을 허용하는 가상 머신으로 끝나는 것 같습니다. = password = vagrant 또는 vagrant_insecure_private_key).

이것이 사실입니까? 그렇다면 왜 보안 취약점으로 간주되지 않습니까? 중요한 데이터를 VM에 복사 한 경우 어떻게됩니까?

편집 : 그리고 인터넷상의 누구든지 소스를 읽을 수 있고 VM에서 임의의 코드를 실행할 수 있다고 생각하는 사람들을 위해이 블로그 게시물 http : //blog.ontoillogical 의 "Breaking out"섹션을 읽는 것이 좋습니다 . com / blog / 2012 / 10 / 31 / breaking-in-and-out-of-vagrant /

간단히 말해서, Vagrant를 "의도 한대로"실행하면 누구나 호스트 / 개발 시스템에 침입 할 수 있습니다 (예 : 악성 git post-commit hook 사용).

---

짧은 대답은 YES 입니다.

왜?

Vagrant 기본 상자를 빌드 할 때 (수동으로 또는 Veewee와 같은 도구를 사용하여 자동화) 빌더 는 다음을 정의 하는 vagrant 기본 상자 사양 을 따릅니다 .

1. 사용자 root및 vagrant사용 방랑 암호
2. 사용자에 대한 공개 키 인증 (비밀번호 없음) vagrant.

Vagrant 프로젝트는 SSH 공개 키 인증을위한 안전하지 않은 키 쌍 을 제공 하므로 vagrant ssh작동합니다.

모든 사람이 비공개 키에 액세스 할 수 있기 때문에 누구나 비공개 키를 사용하여 VM에 로그인 할 수 있습니다 (호스트 머신의 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

---

나는 이것을 방랑자의 github 저장소에서 문제로 제기했습니다. 개발자는 전달 된 포트를 외부에서 사용할 수있는 문제를 해결할 것이라고 말했습니다. 그러나 개발자는 VM의 호스트 환경 손상과 관련된 문제를 수락하지 않습니다. 나는 그들이 위험 할 정도로 틀렸다고 생각합니다.

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

VM에서 벗어나는 것은 링크 된 블로그 게시물이 제안하는 것보다 쉽습니다. 호스트를 손상시키기 위해 git 후크에 의존 할 필요가 없습니다. 임의의 루비 코드를 Vagrant 파일에 넣으면됩니다.

가능하다면 VM 샌드 박스에서 vagrant를 실행했습니다. 할 수 없기 때문에 방화벽을 사용합니다.

보안 ssh 키를 추가하고 안전하지 않은 키와 기본 비밀번호를 제거하는 프로비저닝 규칙을 갖는 것이 좋습니다.

---

나는이 간단한 인라인 쉘 프로 비저 너를 작성하여 authorized_keys를 내 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

---

Vagrant 1.2.3에서 기본값은 외부 연결 문제를 방지하기 위해 공용 인터페이스 대신 localhost에 바인딩하는 것입니다.

---

이 문제를 해결하는 Vagrant 플러그인 인 vagrant-rekey-ssh 를 추가하고 싶었습니다 . VM의 기본 비밀번호를 변경하고 안전하지 않은 SSH 키를 제거합니다.

---

Vagrant가 생각만큼 안전하지 않은 이유를 설명하고 싶습니다.

나는 여러분 대부분이 이미 알고 있다고 확신하므로, 이러한 상자가 공유되는 방식 때문에 Vagrant 상자에 대한 열린 액세스를 유지할 필요가 있다고 말하면서 시작하고 싶습니다. 따라서 기본 보안 문제는 상자를 다운로드 한 후 기본 자격 증명을 변경하지 않는 것이라고 생각합니다. 브리지 모드에서 이러한 머신을 실행하면 네트워크의 누군가가 기본 자격 증명으로 SSH를 사용할 수 있습니다.

It appears to me that the idea behind these boxes is that anyone can download it, and secure it once it is in their possession. My vagrant installation replaces default keys with a new, randomly generated ssh key. I am not sure if this is being done with a plugin, however I am curious to know if the password-less sudo and default password also present a security risk.

참고URL : https://stackoverflow.com/questions/14715678/vagrant-insecure-by-default