Tại sao chạy có tên (bind) trong chroot lại quan trọng đối với bảo mật? Hoặc có thể nó không phải là?

Tôi đang chơi với bind và bắt đầu tự hỏi tại sao phần mềm này, ví dụ, trong CentOS chạy trong chroot. Đừng hiểu lầm tôi, tôi biết ràng buộc là gì và chroot (tù) là để làm gì. Nhưng câu hỏi chính của tôi là đó là liên kết chạy whithout chroot nên rất không an toàn?

Có thực sự có hại khi thiết lập nó mà không có nhà tù (hơn bất kỳ dịch vụ hoặc phần mềm nào khác). Trong các hệ thống có nhiều bộ xử lý chạy mà không có chroot và tôi nghĩ rằng sự thỏa hiệp của bất kỳ trong số chúng là rất nguy hiểm nhưng điều gì làm cho nó trở nên nguy hiểm hơn thì phần mềm khác chạy không có chroot?

Như @Some Guy đã đề cập, bạn phải suy nghĩ về điều này trong quan điểm lịch sử.

Viễn cảnh lịch sử là một phần cứng duy nhất là hàng tá dịch vụ khác nhau trong một hệ điều hành. Nếu một dịch vụ bị xâm phạm thì mọi thứ trên phần cứng đó đều bị xâm phạm.

Với ảo hóa, đây là một vấn đề ít hơn nhiều. Mặc dù không thể thoát ra khỏi VM nhưng nó không phải là chuyện nhỏ. Chắc chắn khó khăn hơn để thoát ra khỏi VM sau đó là một quá trình đang chạy với các đặc quyền gốc để thoát ra khỏi một chroot. Vì vậy, các máy chủ liên kết của tôi đang chạy trên VM của riêng họ. Thực sự không có nhiều điểm cho một chroot trong trường hợp đó vì thiệt hại đã bị hạn chế chỉ đơn giản bởi thực tế nó là một VM.

Một chroot là một nỗ lực rất yếu trong việc tạo ra một cái gì đó như VM. Chroots có thể được thoát khỏi mặc dù bởi bất kỳ quá trình với các đặc quyền gốc. Một chroot không có ý định và không hoạt động như một cơ chế bảo mật. Một chroot với một BSD jail, hoặc LXC cung cấp cho bạn ảo hóa cấp độ hệ điều hành và cung cấp các tính năng bảo mật. Nhưng ngày nay, việc dễ dàng tạo ra một VM mới của toàn bộ máy, có thể không đáng để nỗ lực thiết lập hoặc tìm hiểu cách sử dụng các công cụ ảo hóa cấp hệ điều hành cho mục đích này.

Các phiên bản trước đó của ràng buộc đã không bỏ đặc quyền. Trên Unix, chỉ tài khoản root mới có thể mở các cổng dưới 1024 và Bind vì tất cả chúng ta đều cần nghe trên udp / 53 và tcp / 53. Vì Bind bắt đầu với quyền root và không bỏ đặc quyền nên bất kỳ thỏa hiệp nào cũng có nghĩa là toàn bộ hệ thống có thể bị xâm phạm. Hầu như bất kỳ phần mềm nào ngày nay sẽ bắt đầu mở ổ cắm của họ và thực hiện bất kỳ nội dung nào khác yêu cầu quyền root, sau đó họ sẽ thay đổi người dùng mà họ đang chạy như một tài khoản không có đặc quyền. Một khi các đặc quyền bị loại bỏ, tác động của việc bị xâm phạm sẽ thấp hơn rất nhiều đối với hệ thống máy chủ.

Các câu trả lời khác là khá tốt nhưng không đề cập đến khái niệm bảo mật trong các lớp. Mỗi lớp bảo mật bạn thêm vào hệ thống của bạn là một lớp khác mà một kẻ thù phải vượt qua. Đặt BIND trong một chroot thêm một trở ngại.

Giả sử có một lỗ hổng có thể khai thác trong BIND và ai đó có thể thực thi mã tùy ý. Nếu họ ở trong một chroot, họ cần phải thoát ra khỏi điều đó trước khi đến bất kỳ thứ gì khác trong hệ thống. Như các đặc quyền gốc đã đề cập là cần thiết để phá vỡ chroot. BIND không chạy với quyền root và được cho là có các công cụ tối thiểu có sẵn trong chroot, hạn chế thêm các tùy chọn và về cơ bản chỉ để lại các cuộc gọi hệ thống. Nếu không có cuộc gọi hệ thống để leo thang đặc quyền thì đối thủ sẽ bị kẹt khi xem các bản ghi DNS của bạn.

Tình huống đã nói ở trên có vẻ khó xảy ra vì một số người đã đề cập, BIND có khá ít lỗ hổng trong những ngày này và chúng hầu như bị hạn chế trong các kịch bản loại DoS thay vì thực thi từ xa. Điều đó nói rằng, chạy trong một chroot là cấu hình mặc định trên khá nhiều HĐH, do đó, không có bất kỳ nỗ lực nào từ phía bạn để giữ bảo mật được tăng lên một chút.

lời mở đầu

Tôi tiếp tục nghe mọi người nhắc lại những quan niệm sai lầm từ khắp nơi trên internet .. vì vậy, tôi sẽ cố gắng làm rõ

đầu tiên; có bao nhiêu khám phá tình cờ đã có, mà đơn giản là .. do nguyên nhân và kết quả , cuối cùng đã được sử dụng cho mục đích khác ngoài mục đích của nó?

cái gì là và cái gì là nhà tù Chroot

Chroot ban đầu được thiết kế để thay đổi thư mục gốc cho quy trình hoặc người dùng (tuyệt vời để biên dịch phần mềm từ các nguồn không xác định). điều này cung cấp bảo mật cho hệ thống cơ sở, cũng như một thiết bị thử nghiệm nhanh, bao gồm cả việc dọn dẹp dễ dàng. đã nhiều năm trôi qua, và khái niệm và cách sử dụng ngụ ý chắc chắn đã thay đổi.

chroot đã được sử dụng một cách hiệu quả và trực tiếp trong cơ sở mã cho một số chương trình và thư viện (ví dụ: openSSHd, apache2 + mod_security2 / mod_chroot, dovecot, sendmail, openVPN, pam_chroot, và nhiều hơn nữa ). giả sử rằng tất cả các ứng dụng chính này đã triển khai các giải pháp bảo mật bị lỗi là không đúng

chroot là một giải pháp để ảo hóa hệ thống tập tin: không hơn không kém. giả định rằng bạn có thể dễ dàng thoát ra khỏi một chiếc chroot cũng không đúng ... miễn là bạn tuân thủ các nguyên tắc chạy các quy trình bên trong nhà tù chroot.

Một số bước để bảo vệ nhà tù chroot của bạn

tức là KHÔNG chạy các tiến trình như ROOT. điều này có thể mở ra một vectơ leo thang gốc (điều này cũng đúng trong hoặc ngoài chroot). không chạy một tiến trình bên trong chroot, sử dụng cùng một người dùng như một tiến trình khác bên ngoài chroot. tách riêng từng quy trình và người dùng thành Chroot của riêng mình để hạn chế các bề mặt tấn công và cung cấp quyền riêng tư. chỉ gắn các tệp, thư viện và thiết bị cần thiết. cuối cùng, chroot KHÔNG phải là sự thay thế cho bảo mật hệ thống cơ sở. bảo mật toàn bộ hệ thống.

Một lưu ý quan trọng khác: nhiều người nghĩ rằng OpenVZ bị hỏng hoặc không bằng so với ảo hóa toàn hệ thống. họ đưa ra giả định này vì thực chất nó là Chroot, với một bảng quy trình đã được khử trùng. với các biện pháp bảo mật tại chỗ trên phần cứng và thiết bị. hầu hết trong số đó bạn có thể thực hiện trong một chroot.

không phải mọi quản trị viên đều có mức độ kiến ​​thức cần thiết để bảo mật tất cả các tham số kernel cần thiết trên một máy chủ chuyên dụng hoặc dưới hệ thống ảo hóa toàn bộ. điều này có nghĩa là việc triển khai OpenVZ có nghĩa là khách hàng của bạn sẽ có ít bề mặt tấn công hơn để thử và bảo vệ và bảo mật trước khi triển khai các ứng dụng của họ. một máy chủ tốt sẽ làm tốt công việc bảo mật các tham số này và đến lượt nó, điều này tốt hơn cho không chỉ tất cả mọi người trên Node, hoặc trong trung tâm dữ liệu, mà cho cả internet ...

như đã nêu, chroot cung cấp ảo hóa hệ thống tập tin. bạn phải đảm bảo rằng không có tệp thực thi setuid ', ứng dụng không an toàn, thư viện, liên kết không có chủ sở hữu, v.v. trong một số cách khác, thỏa hiệp một cái gì đó bên trong nhà tù - thoát khỏi nhà tù thường thông qua việc leo thang đặc quyền hoặc bơm trọng tải của anh ta hoặc cô ta vào hệ thống cơ sở.

nếu điều này xảy ra, nó thường là kết quả của một bản cập nhật xấu, khai thác không ngày hoặc lỗi con người thành ngữ .

Tại sao chroot vẫn được sử dụng, trái ngược với ảo hóa toàn hệ thống

hãy xem xét kịch bản này: bạn đang chạy Máy chủ riêng ảo, với nút máy chủ đang chạy OpenVZ. bạn chỉ đơn giản là không thể chạy bất cứ thứ gì hoạt động ở cấp độ kernel. điều này cũng có nghĩa là bạn không thể sử dụng ảo hóa hệ điều hành để phân tách các quy trình và cung cấp bảo mật bổ sung. do đó, bạn PHẢI sử dụng chroot cho mục đích này.

hơn nữa, chroot là bền vững trên bất kỳ hệ thống nào, bất kể tài nguyên có sẵn. Nói một cách đơn giản, nó có chi phí tối thiểu của bất kỳ loại ảo hóa nào. điều này có nghĩa là nó vẫn còn quan trọng trên nhiều hộp cấp thấp.

xem xét một kịch bản khác: bạn có apache chạy trong môi trường ảo hóa. bạn muốn tách riêng từng người dùng. cung cấp một hệ thống tệp ảo hóa thông qua một chroot thêm vào apache (mod_chroot, mod_security, v.v.) sẽ là lựa chọn tốt nhất để đảm bảo quyền riêng tư tối đa giữa người dùng cuối. điều này cũng giúp ngăn chặn thu thập thông tin và cung cấp một lớp bảo mật khác.

Nói một cách đơn giản, điều quan trọng là phải thực hiện bảo mật trong các lớp . Chroot có khả năng là một trong số họ. không phải tất cả mọi người và mọi hệ thống đều có quyền truy cập vào Hạt nhân, do đó, chroot VẪN phục vụ một mục đích. có rất nhiều ứng dụng trong đó tính năng hệ thống đầy đủ về cơ bản là quá mức cần thiết.

Trả lời câu hỏi của bạn

Tôi không đặc biệt sử dụng CentOS, nhưng tôi biết rằng Bind hiện đã bỏ các đặc quyền của nó trước khi hoạt động. tuy nhiên, tôi cho rằng liên kết đó bị phá hủy do lịch sử của các vectơ tấn công và các lỗ hổng tiềm ẩn.

Ngoài ra ... sẽ có ý nghĩa hơn khi tự động chroot ứng dụng này, hơn là không, bởi vì MỌI NGƯỜI không có quyền truy cập vào ảo hóa cấp hệ thống / hệ điều hành đầy đủ. đến lượt nó, và trên lý thuyết, giúp cung cấp bảo mật cho cơ sở người dùng CentOS:

Các nhà cung cấp hệ điều hành chỉ đơn giản là không đi xung quanh giả sử mọi người đều chạy cùng một hệ thống. bằng cách này, họ có thể giúp cung cấp thêm một lớp bảo mật ...

có một lý do tại sao rất nhiều ứng dụng sử dụng điều này và tại sao rõ ràng hệ điều hành của bạn làm theo mặc định: bởi vì nó được sử dụng như một tính năng bảo mật và nó KHÔNG hoạt động. với sự chuẩn bị kỹ lưỡng, như đã nói trước đây, đó là một trở ngại khác mà kẻ tấn công tiềm năng phải vượt qua - hầu hết thời gian, hạn chế thiệt hại chỉ được thực hiện đối với nhà tù chroot.

Điều này một phần là do các lý do lịch sử, khi các phiên bản cũ của Bind có các lỗ hổng bảo mật nghiêm trọng, thường xuyên. Tôi đã không thực sự cập nhật về chủ đề này, nhưng tôi cá rằng nó đã được cải thiện rất nhiều kể từ những ngày tồi tệ.

Một lý do khác, thực tế hơn, chỉ là nó thường được triển khai trong vai trò đối mặt với Internet, và như vậy, nó mở ra cho nhiều cuộc tấn công, thăm dò và lừa đảo nói chung.

Do đó, như thường là quy tắc ngón tay cái trong các vấn đề bảo mật: an toàn tốt hơn xin lỗi, đặc biệt là nỗ lực của chroot-ing nó là tương đối ít.