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

편집 2 : TL; DR : 대답은 2013 년 예, 그러나이 결함이 vagrantup.com에 시작하기 지침에 따라기본적으로 방랑자가 안전하지 않습니까?

를 수정되었습니다, 나는 가상 머신으로 끝날 것 같다 누군가가 내 VM에 대한 루트 액세스 권한을 얻고 기본 자격 증명 (username = password = vagrant 또는 vagrant_insecure_private_key)을 사용하여 내 호스트 작업 디렉토리를 읽을 수 있도록 포트 2222에서 SSH 연결을 수락합니다.

사실인가요? 그렇다면 왜 격렬한 보안 취약점으로 간주되지 않습니까? 민감한 데이터를 VM에 복사 한 경우 어떻게해야합니까?

편집 : 그리고 당신의 소스를 읽을 수와 VM에서 임의의 코드를 실행 인터넷에서 사람을 생각하는 사람들을 위해 내가이 블로그 게시물에서 "밖으로 속보"절을 읽어 보시기 바랍니다, 그 나쁘지 않다 http://blog.ontoillogical.com/blog/2012/10/31/breaking-in-and-out-of-vagrant/

간단히 말해, "의도 한대로"실행중인 Vagrant를 사용하면 누구든지 호스트/개발 시스템에 침입 할 수 있습니다 (예 : 악의적 인 git 후속 커밋 훅 사용).

출처

2013-02-05 oseiskar

vagrant_에서 _breaking에 대한 링크가 끊어졌습니다. 다음은 현재 작동합니다. http://blog.ontoillogical.com/blog/2012/10/31/breaking-in-and-out-of-vagrant/ – pnd

http://web.archive.org/web/20160714220643/ http://blog.ontoillogical.com/blog/2012/10/31/breaking-in-and-out-of-vagrant –

짧은 대답은 예입니다.

왜?

(수동 또는 Veewee는 자동화와 같은 도구를 사용하여) 방랑 기본 상자를 구축 할 때, 빌더는 다음과 같은 정의 vagrant base boxes specifications 따르

사용자 root 및 vagrant 사용하는 암호와 방랑을
공개 사용자의 키 인증 (암호 없음)은 vagrant입니다.

Vagrant 프로젝트는 이 작동하도록 SSH 공개 키 인증에 대해 안전하지 않은 key pair을 제공합니다. 모든 사람이 개인 키에 대한 액세스 권한을 가지고 있기 때문에

는 사람이 당신의 VM (그들은 포트가 장소에 전달 규칙과 같은 기본 2222입니다, 호스트 시스템의 사용자의 IP를 알고 가정합니다.)

에 로그인하기 위해 개인 키를 사용할 수 있습니다

OOTB는 안전하지 않습니다. 그러나 신뢰할 수있는 키를 ~vagrant/.ssh/authorized_keys에서 삭제하고 vagrant 및 root에 대해 비밀번호를 변경하면 비교적 안전한 것으로 간주됩니다.

업데이트 기본 SSH 전송 포트가 너무 로컬 연결을 127.0.0.1에 결합에 의해

방랑 1.2.3 이후, 수 있습니다 [GH-1785].

중요 업데이트 무작위로 첫 vagrant up에 키 쌍 생성과 방랑 기본 안전하지 않은 SSH 키 쌍을 대체 할 방랑 1.7.0 (PR #4707) 이후

CHANGELOG에서 참조하십시오. 기본 안전하지 않은 키 쌍이 사용되는 경우 Vagrant가 처음에 무작위로 생성 된 키 쌍으로 자동 대체합니다 (vagrant up). GH-2608

출처

2013-02-05 23:55:58

OOTB 구성이 완전히 손상되지는 않지만 OOTB는 실행중인 사용자에게 효과적으로 액세스하는 것을 포함합니다 virtualbox를 호스트 환경에있는 모든 사용자에게 배포합니다. 이는 상당히 심각한 결함이지만 호스트 자체를 손상시키기에 충분하지 않습니다. – mc0e

그리고 암호가없는 sudo! 그걸 무시할 수없는 것 같습니까? – CMCDragonkai

나는 이것을 방황을위한 github 저장소의 문제로 제기했습니다. 개발자는 전달 된 포트를 외부에서 사용할 수있게하여 문제를 해결할 것이라고 말했습니다. 그러나 개발자는 VM에서 호스트 환경을 손상시키는 문제는 허용하지 않습니다. 위험하다고 생각합니다. VM의에서 실연

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

링크 된 블로그 게시물이 시사하는 것보다 쉽다. git hook을 사용하여 호스트를 손상시킬 필요는 없습니다. 임의의 루비 코드를 Vagrant 파일에 넣기 만하면됩니다.

가능한 경우 VM 샌드 박스에서 방랑을 실행합니다. 나는 할 수 없기 때문에 방화벽으로 만한다.

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

출처

2013-06-04 13:57:55 mc0e

Vagrant 1.2.3에서 기본값은 외부 연결 문제를 피하면서 공용 인터페이스 대신 로컬 호스트에 바인딩하는 것입니다.

출처

2013-09-18 17:49:37 jerm

나는 id_rsa.pub와 함께 authorized_keys를 바꾸기 위해이 간단한 인라인 쉘 프로비저를 작성했습니다. 일단 프로비저닝되면 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

출처

2014-02-01 01:21:10 donnoman

개인 키가 좋아 보인다. 그러나 이것은 "방랑자"와 "뿌리"라는 계정에 "방랑자"라는 암호가 있다는 사실과 아무런 관련이 없습니다. 맞습니까? –

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

출처

2014-12-03 20:48:43

좋은 물건. 감사. 방제 상자에 대한 호스트 환경의 노출은 다른 취약점이있는 경우에도 남아 있습니다. – mc0e

FYI :이 기능은 현재 Vagrant 1.7+에 포함되어 있습니다. 플러그인은 더 이상 사용되지 않습니다. – James

왜 방글라데시가 당신이 생각하는 것처럼 반드시 안전하지는 않은지 설명하고 싶습니다.

저는 대부분의 사람들이 이미 알고 있다고 확신하기 때문에 이러한 상자가 공유되는 방식 때문에 Vagrant 상자에 대한 공개 액세스를 유지해야합니다. 따라서 기본 보안 문제는 상자를 다운로드 한 후에 기본 자격 증명을 변경하지 않는다고 생각됩니다. 브리징 모드에서 이러한 시스템을 실행하면 네트워크에있는 누군가가 기본 신임장으로 ssh 할 수 있습니다.

이 상자의이면에있는 아이디어는 누구나 다운로드하여 자신의 소유로 확보 할 수 있다는 것입니다. 방랑용 설치가 기본 키를 새로운 임의로 생성 된 ssh 키로 바꿉니다. 나는 이것이 플러그인으로 처리되고 있는지 확실하지 않지만, 암호가없는 sudo와 기본 암호가 보안상의 위험을 안고 있는지 궁금합니다.

출처

2015-11-09 17:33:56 Coffee123

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

답변

관련 문제