2013-02-05 31 views
67

EDIT 2: TL; DR: câu trả lời đã có trong năm 2013, nhưng lỗ hổng này đã được cố địnhÂm thanh không an toàn theo mặc định?

Bằng cách làm theo các hướng dẫn Getting Started trên vagrantup.com, tôi dường như kết thúc với một máy ảo đó là chấp nhận kết nối SSH trên cổng 2222 để bất kỳ ai cũng có thể truy cập root vào máy ảo của tôi và đọc thư mục làm việc của máy chủ của tôi bằng thông tin đăng nhập mặc định (username = password = vagrant hoặc vagrant_insecure_private_key).

Điều này có đúng không? Nếu có, tại sao nó không được coi là một lỗ hổng bảo mật hổng? Nếu tôi sao chép dữ liệu nhạy cảm vào máy ảo thì sao?

EDIT: và cho những người nghĩ rằng mọi người trên Internet là có thể đọc các nguồn tin của bạn và thực thi mã tùy ý trên máy ảo của bạn không phải là xấu, tôi khuyên bạn nên đọc "Breaking out" phần trong bài đăng blog này http://blog.ontoillogical.com/blog/2012/10/31/breaking-in-and-out-of-vagrant/

Tóm lại: chạy Vagrant "như dự định" cũng có thể kích hoạt bất cứ ai để đột nhập vào máy chủ/phát triển của bạn (ví dụ, bằng cách sử dụng một git độc hại sau cam kết nối).

+1

Liên kết đến _breaking vào và ra khỏi vagrant_ bị hỏng. Công việc hiện tại sau đây: http://blog.ontoillogical.com/blog/2012/10/31/breaking-in-and-out-of-vagrant/ – pnd

+1

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

Trả lời

91

Câu trả lời ngắn gọn là YES.

Tại sao?

Khi xây dựng hộp cơ sở Vagrant (bằng tay hoặc sử dụng các công cụ như Veewee để tự động), các nhà xây dựng theo các vagrant base boxes specifications trong đó xác định như sau:

  1. tài rootvagrant sử dụng lang thang như mật khẩu
  2. Công xác thực khóa (ít mật khẩu) cho người dùng vagrant.

Dự án âm đạo cung cấp không an toàn key pair để xác thực khóa công khai SSH để vagrant ssh hoạt động.

Bởi vì mọi người đều có quyền truy cập vào các khóa bí mật, bất cứ ai có thể sử dụng khóa riêng để đăng nhập vào máy ảo của bạn (giả sử họ biết IP của bạn của máy chủ, cổng là theo mặc định 2222 như quy tắc chuyển tiếp tại chỗ.)

KHÔNG AN TOÀN OOTB. Tuy nhiên, bạn có thể loại bỏ chìa khóa đáng tin cậy từ ~vagrant/.ssh/authorized_keys và thêm riêng của bạn, thay đổi mật khẩu cho vagrantroot, sau đó nó được coi là tương đối an toàn.

Cập nhật

Kể từ Vagrant 1.2.3, bởi SSH mặc định cổng chuyển tiếp liên kết với 127.0.0.1 vì vậy chỉ kết nối địa phương được phép [GH-1785].

Cập nhật QUAN TRỌNG

Kể từ Vagrant 1.7.0 (PR #4707) Vagrant sẽ thay thế mặc định cặp khóa ssh không an toàn với tạo ngẫu nhiên cặp khóa trên vagrant up đầu tiên.

Xem trong CHANGELOG: cặp khóa không an toàn mặc định được sử dụng, Vagrant sẽ tự động thay thế bằng cặp khóa được tạo ngẫu nhiên vào ngày vagrant up đầu tiên. GH-2608

+0

Cấu hình OOTB không bị xâm phạm hoàn toàn, nhưng OOTB bao gồm việc cấp quyền truy cập hiệu quả cho người dùng đang chạy VirtualBox trong môi trường máy chủ cho bất kỳ ai có quyền truy cập root trong VM. Đó là một lỗ hổng khá nghiêm trọng, nhưng không đủ để thỏa hiệp chủ nhà. – mc0e

+1

Và sudo không mật khẩu! Có vẻ như bạn không thể bỏ qua điều đó? – CMCDragonkai

10

Tôi đã nêu vấn đề này như một vấn đề trên kho lưu trữ github cho người lang thang. Nhà phát triển đã cho biết họ sẽ khắc phục sự cố với các cổng được chuyển tiếp có sẵn bên ngoài. Tuy nhiên, nhà phát triển không chấp nhận vấn đề liên quan đến sự thỏa hiệp của môi trường máy chủ từ máy ảo. Tôi nghĩ rằng họ đang gặp nguy hiểm sai.

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

Breaking ra khỏi vm là dễ dàng hơn so với các bài đăng blog liên kết gợi ý. Bạn không cần phải phụ thuộc vào git hooks để thỏa hiệp host, bạn chỉ cần đặt mã ruby ​​tùy ý vào file Vagrant.

Tôi sẽ chạy lang thang trong hộp cát VM nếu có thể. Vì tôi không thể, tôi thực hiện với tường lửa.

Bạn nên có quy tắc cấp phép để thêm khóa ssh bảo mật và để xóa khóa không an toàn và mật khẩu mặc định.

7

Theo Vagrant 1.2.3, mặc định là liên kết với localhost thay vì giao diện công cộng, tránh sự cố kết nối bên ngoài.

9

Tôi đã viết trình cung cấp vỏ nội tuyến đơn giản này để hoán đổi các authorized_keys bằng id_rsa.pub của tôi. Sau khi được cung cấp, insecure_private_key không thể được sử dụng để xác thực.

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 
+2

Điều này có vẻ tuyệt vời cho khóa riêng tư. Nhưng điều này sẽ không làm bất cứ điều gì với thực tế là tài khoản "vagrant" và "root" có mật khẩu "vagrant", phải không? –

1

Chỉ muốn thêm rằng có một plugin Vagrant giải quyết vấn đề này: vagrant-rekey-ssh. Nó thay đổi mật khẩu mặc định của VM và loại bỏ khóa SSH không an toàn.

+0

Nội dung hay. Cảm ơn. Tuy nhiên, việc tiếp xúc môi trường máy chủ với hộp âm thanh vẫn còn, trong trường hợp có bất kỳ lỗ hổng nào khác ở đó. – mc0e

+2

FYI: Chức năng này hiện được bao gồm trong Vagrant 1.7+. Plugin đã lỗi thời. – James

0

Tôi muốn giải thích tại sao Vagrant không nhất thiết là không an toàn như bạn nghĩ.

Tôi muốn bắt đầu bằng cách nói rằng như tôi chắc chắn hầu hết các bạn đã biết, cần duy trì quyền truy cập mở vào hộp Vagrant vì cách các hộp này đang được chia sẻ. Vì lý do đó, tôi tin rằng mối quan tâm bảo mật chính không thay đổi thông tin đăng nhập mặc định sau khi hộp được tải xuống. Việc chạy một máy như vậy trong chế độ bắc cầu sẽ cho phép một người nào đó trên mạng truy cập bằng thông tin xác thực mặc định.

Dường như với tôi ý tưởng đằng sau các hộp này là bất kỳ ai cũng có thể tải xuống và bảo mật nó sau khi sở hữu. Cài đặt lang thang của tôi thay thế các khóa mặc định bằng khóa ssh mới được tạo ngẫu nhiên. Tôi không chắc chắn nếu điều này đang được thực hiện với một plugin, tuy nhiên tôi tò mò muốn biết nếu mật khẩu ít sudo và mật khẩu mặc định cũng trình bày một nguy cơ bảo mật.

Các vấn đề liên quan