web-dev-qa-db-ja.com

Vagrantはデフォルトでは安全ではありませんか？

EDIT 2：TL; DR：答えは2013年にはいでしたが、この欠陥は修正されました

Vagrantup.comの「Getting Started」の指示に従うと、ポート2222でSSH接続を受け入れている仮想マシンになり、だれでもmy VMにrootアクセスしてmyデフォルトの資格情報（username = password = vagrantまたはvagrant_insecure_private_key）を使用して作業ディレクトリをホストします。

これは本当ですか？ 「はい」の場合、セキュリティの脆弱性の脆弱性と見なされないのはなぜですか？機密データをVMにコピーした場合はどうなりますか？

[〜＃〜] edit [〜＃〜]：インターネット上の誰でもソースを読み取って任意のコードを実行できると考えている人向けyour VMはそれほど悪くありません。このブログ投稿の「ブレイクアウト」セクションを読むことをお勧めします http://blog.ontoillogical.com/blog/2012/10/31/breaking-in-and-out-of-vagrant /

一言で言えば：「意図したとおりに」Vagrantを実行すると、だれでもホスト/開発マシンに侵入できるようになります（たとえば、悪意のあるgit post-commitフックを使用して）。

securityvagrant
70
oseiskar

短い答えは[〜＃〜] yes [〜＃〜]です。

なぜ？

Vagrantベースボックスを（手動で、またはVeeweeなどのツールを使用して自動化して）構築する場合、ビルダーは vagrant base box specification に従い、以下を定義します。

  1. ユーザーrootおよびvagrantは、パスワードとしてvagrantを使用します
  2. ユーザーvagrantの公開キー認証（パスワードなし）。

Vagrantプロジェクトは、vagrant sshが機能するように、SSH公開キー認証用に安全でない key pair を提供します。

誰でもプライベートキーにアクセスできるため、誰でもプライベートキーを使用して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は、最初のvagrant upでデフォルトの安全でないsshキーペアをランダムに生成されたキーペアに置き換えます。

[〜＃〜] changelog [〜＃〜] を参照してください。デフォルトの安全でないキーペアが使用され、Vagrantは最初のvagrant upでランダムに生成されたキーペアに自動的に置き換えます。 GH-2608

96
Terry Wang

これは、vagrantのgithubリポジトリの問題として提起しました。開発者は、転送されたポートが外部で利用可能になるという問題を修正すると述べています。ただし、開発者は、VMからのホスト環境の侵害に関する問題を受け入れません。それらは危険なほど間違っていると思います。

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

Vmから抜け出すことは、リンクされたブログの投稿が示唆するよりも簡単です。ホストを危険にさらすためにgitフックに依存する必要はなく、任意のRubyコードをVagrantファイルに入れるだけです。

可能であれば、VMサンドボックスでvagrantを実行します。できないため、ファイアウォールで対処します。

安全なsshキーを追加し、安全でないキーとデフォルトのパスワードを削除するプロビジョニングルールを設定することをお勧めします。

10
mc0e

この単純なインラインシェルプロビジョニングツールを作成して、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
9
donnoman

Vagrant 1.2.3の時点では、デフォルトではパブリックインターフェイスではなくローカルホストにバインドされ、外部接続の問題を回避します。

7
jerm

この問題を解決するVagrantプラグインがあることを追加したかっただけです： vagrant-rekey-ssh 。 VMのデフォルトのパスワードを変更し、安全でないSSHキーを削除します。

1
Luca Invernizzi

Vagrantが必ずしもあなたが考えるほど安全ではない理由を説明したいと思います。

私はあなたのほとんどがすでに知っていると確信しているように、これらのボックスが共有されている方法のためにVagrantボックスへのオープンアクセスを維持する必要があると言って始めたいと思います。そのため、主なセキュリティ上の懸念は、ボックスのダウンロード後にデフォルトの資格情報を変更しないことだと思います。このようなマシンをブリッジモードで実行すると、ネットワーク上の誰かがデフォルトの資格情報でsshできるようになります。

これらのボックスの背後にあるアイデアは、だれでもダウンロードでき、所有したら安全にできるということです。 Vagrantをインストールすると、デフォルトのキーが、ランダムに生成された新しいsshキーに置き換えられます。これがプラグインで実行されているかどうかはわかりませんが、パスワードなしのSudoとデフォルトのパスワードにもセキュリティ上のリスクがあるかどうか知りたいです。

0
Coffee123