Có an toàn cho một máy chủ sản xuất đã cài đặt không?


42

Trong quá trình thiết lập các phiên bản máy chủ ảo của tôi, tôi yêu cầu một số ứng dụng được xây dựng bằng cách sử dụng make. Có bất kỳ rủi ro bảo mật liên quan đến việc makecài đặt? Hoặc tôi nên dọn sạch nó trước khi cá thể được triển khai?

Tôi cũng có gcctrình biên dịch trên máy chủ mà tôi sử dụng để xây dựng các ứng dụng trước khi triển khai.


4
Nếu nó làm cho bạn cảm thấy tốt hơn, bất kỳ phần mềm nào được cài đặt ở bất cứ đâu cũng tạo ra lỗ hổng.
MDMoore313

1
Và một người có quyền truy cập shell không root vào máy chủ có thể tải xuống gói trình biên dịch "distro độc lập" (.tar.gz) không cần cài đặt nên ...

1
Là tôi, hay là sự kết hợp của "nó có an toàn không?" và "truy cập root" khá khó chịu ?
DNA

2
Nếu bạn đã cài đặt gcc, thực tế không có cách nào có thể làm cho bất kỳ vấn đề bảo mật tiềm ẩn nào trở nên tồi tệ hơn.
Shadur

1
@Shadur GCC có gì khác biệt? Nếu người dùng đã có quyền truy cập vào máy, họ có thể tải lên bất kỳ bản sao nào của gcc một cách tầm thường. Dù sao, gcc có thể hữu ích cho người dùng không có đặc quyền và không phải là rủi ro bảo mật miễn là không có người dùng đặc quyền nào chạy nó.
Vality

Câu trả lời:


50

Một số người sẽ lập luận rằng sự hiện diện của các công cụ phát triển trên một máy sản xuất sẽ giúp cuộc sống của kẻ tấn công dễ dàng hơn. Tuy nhiên, đây là một rào cản nhỏ đối với kẻ tấn công, rằng bất kỳ đối số nào khác bạn có thể tìm thấy hoặc chống lại việc cài đặt các công cụ phát triển sẽ nặng hơn.

Nếu một kẻ tấn công có thể xâm nhập hệ thống cho đến nay, chúng có thể gọi bất kỳ công cụ nào có trên máy chủ, thì bạn đã vi phạm an ninh nghiêm trọng. Không có các công cụ phát triển, có nhiều cách khác để ghi dữ liệu nhị phân vào một tệp và sau đó chạy một chmod trên tệp đó. Kẻ tấn công muốn sử dụng một bản dựng thực thi tùy chỉnh trên hệ thống tại thời điểm này cũng có thể xây dựng nó trên máy của chính họ và chuyển nó đến máy chủ.

Có nhiều thứ khác có liên quan hơn nhiều để tìm kiếm. Nếu một phần mềm được cài đặt có lỗi bảo mật, có một số cách nó có thể bị phơi bày trước kẻ tấn công:

  • Gói có thể chứa một thực thi suid hoặc sgid.
  • Các gói có thể được bắt đầu dịch vụ trên hệ thống.
  • Gói có thể cài đặt các tập lệnh được gọi tự động trong một số trường hợp nhất định (điều này bao gồm các công việc định kỳ, nhưng các tập lệnh có thể được gọi bởi các sự kiện khác, ví dụ như khi trạng thái của giao diện mạng thay đổi hoặc khi người dùng đăng nhập).
  • Gói có thể cài đặt inodes thiết bị.

Tôi sẽ không mong đợi các công cụ phát triển phù hợp với một trong những điều trên và như vậy không phải là một gói rủi ro cao.

Nếu bạn có các quy trình công việc mà bạn sẽ sử dụng các công cụ phát triển, thì trước tiên bạn phải quyết định xem đó có phải là các quy trình công việc hợp lý hay không và nếu có, bạn nên cài đặt các công cụ phát triển.

Nếu bạn thấy rằng bạn không thực sự cần những công cụ đó trên máy chủ, bạn nên hạn chế cài đặt chúng vì nhiều lý do:

  • Tiết kiệm không gian đĩa, cả trên máy chủ và sao lưu.
  • Phần mềm ít được cài đặt giúp dễ dàng theo dõi những gì phụ thuộc của bạn.
  • Nếu bạn không cần gói, sẽ không có rủi ro bảo mật bổ sung nào từ việc cài đặt nó, ngay cả khi rủi ro bảo mật đó là rất nhỏ.

Nếu bạn quyết định rằng vì lý do bảo mật, bạn sẽ không cho phép người dùng không có đặc quyền đặt tệp thực thi của riêng họ lên máy chủ, thì điều bạn nên tránh không phải là các công cụ phát triển mà là các thư mục có thể ghi đối với những người dùng trên hệ thống tệp được gắn quyền thực thi. Có thể vẫn còn sử dụng cho các công cụ phát triển ngay cả trong những trường hợp đó, nhưng nó không có khả năng lắm.


6
Tôi sẽ nói thêm rằng một số hệ thống sản xuất dựa trên mã được giải thích (ví dụ: PHP, Perl, Python, ...). Cấm các công cụ phát triển trong bối cảnh này sẽ không có ý nghĩa. Tôi sẽ xem xét các trình biên dịch như gcckhông có rủi ro cao hơn các trình biên dịch này. Như bạn nói, kẻ tấn công ở vị trí sử dụng trình biên dịch được cài đặt trên hệ thống thường sẽ ở một vị trí để làm những việc tồi tệ hơn, chẳng hạn như tải lên tệp thực thi (có thể được liên kết tĩnh) của riêng chúng.
Bruno

3
Có liên quan: Một phiên bản nhỏ của wget (51 byte?) . Một ví dụ thực tế về kẻ tấn công di chuyển nhị phân đến máy chủ bằng cách sử dụng các echocâu lệnh tiếp theo vào một tệp. Toàn bộ quá trình được tự động hóa với một tập lệnh được tìm thấy trong cùng một liên kết.
Adi

2
@Ad Nam, thú vị. Theo như tôi có thể nói, lỗ hổng bảo mật chính trong ví dụ về DVR này là việc kẻ tấn công có thể telnet đến nó với quyền root bằng mật khẩu 123456 ngay từ đầu. Có hoặc không có wget hoặc các công cụ khác (trước cuộc tấn công) thì thực sự không liên quan.
Bruno

15

makelà một shell có cú pháp khác với bash.

Một trình biên dịch như gcclà một awkcấu hình mạnh mẽ với một tập hợp các thay thế mà tiêu chuẩn awkkhông hỗ trợ. Đây là một sản phẩm không tuân thủ POSIX sorthoặc catbơm rác vào đầu ra. Nó là một trình soạn thảo văn bản tương tác (think vi) được cấu hình để thực hiện một số chỉnh sửa khi khởi động, sau đó thoát ra trước khi hiển thị giao diện người dùng.

Không có gì là không an toàn trong chúng, chúng không làm cho máy của bạn không an toàn hơn máy mà bạn có bash + cat+ chuyển hướng vỏ.


2
Một câu trả lời vì vậy tôi không biết cách đánh giá nó.
kasperd

4
@kasperd Câu trả lời này nhằm mục đích nghiêm túc. Tôi nghĩ rằng việc đưa quan điểm của một lập trình viên có thể hữu ích. Một chức năng chuyển đầu vào thành đầu ra không gây ra lỗ hổng chỉ vì đầu ra của nó ở định dạng dễ hiểu với CPU.
Ignis

1
Tôi đồng ý với quan điểm bạn đang thực hiện. Tôi nghĩ rằng câu trả lời của bạn là một bài đọc tuyệt vời cho bất cứ ai đã đồng ý với nó. Tôi chỉ lo lắng rằng câu trả lời của bạn có thể đi qua như một trò đùa với ai đó không đồng ý với nó.
kasperd

Tôi thích câu trả lời này hơn nhiều so với câu trả lời được chấp nhận :)
Ruslan

15

makebản thân nó là tốt makechỉ đơn thuần là một khung theo dõi phụ thuộc và tự động hóa. Tuy nhiên, nó thường được sử dụng cùng với các trình biên dịch và những trình biên dịch tốt nhất không nên có sẵn trên một hệ thống sản xuất, vì chúng hoàn toàn không cần thiết. Điều tương tự cũng đúng với tất cả các gói không cần thiết, cho dù đó là các thư viện dùng chung, thông dịch viên, v.v. Phần mềm được cài đặt trên các hệ thống sản xuất nên được kiểm soát chặt chẽ và chỉ có các gói được yêu cầu bởi ứng dụng.

Bạn nên xây dựng ứng dụng của mình trên một máy chủ xây dựng, đóng gói nó và sau đó triển khai gói nhị phân cho các hệ thống sản xuất của bạn.

Lưu ý: công cụ đóng gói bản địa hút . Đừng bận tâm đến việc cố gắng mò mẫm chúng. Thay vào đó, hãy kiểm tra Jordan Sissel's fpm. Nó làm cho bao bì là một niềm vui tuyệt đối.


8
Tôi đang hỏi về sự tò mò và thiếu hiểu biết ở đây: Tại sao bạn nói rằng sự hiện diện của trình biên dịch là một "vấn đề bảo mật quan trọng?" Vấn đề bảo mật khi cài đặt trình biên dịch là gì? Có phải vấn đề là bạn không nên xây dựng mã của mình trên máy chủ sản xuất ngay từ đầu và do đó trình biên dịch là không cần thiết, hay thực sự có vấn đề bảo mật quan trọng với sự hiện diện của chính trình biên dịch?
thiệu lại vào

11
Mặc dù đó là một ý tưởng tốt để xây dựng các ứng dụng của bạn trên một máy chủ riêng biệt, nói rằng sự hiện diện của trình biên dịch trên hệ thống sản xuất là một vấn đề bảo mật quan trọng không có ý nghĩa gì. Còn các ngôn ngữ kịch bản và các hệ thống do JIT biên dịch (Perl, Python, Java, ...) thì sao?
Bruno

3
Sự hiện diện của trình biên dịch trên môi trường sản xuất không phải là "rủi ro bảo mật đáng kể". Tôi, bản thân tôi, đã chuyển nhị phân sang các hộp bị xâm nhập bằng cách sử dụng echobase64. Trong thực tế, bạn thậm chí có thể làm điều đó với một loạt các echocâu lệnh và không có công cụ nào khác .
Adi

1
Điểm tốt, tất cả. Tôi đã chỉnh sửa câu trả lời của mình để làm rõ.
EEAA

9

Ngược lại, vấn đề tiềm năng không makenằm ở máy chủ sản xuất, vấn đề tiềm ẩn là việc xây dựng các ứng dụng trên máy chủ sản xuất thay vì triển khai các hình ảnh dựng sẵn được thử nghiệm. Có thể có những lý do hợp lệ cho phương pháp này, nhưng đó là lý do tôi sẽ cố gắng chống lại vất vả khi tôi được yêu cầu áp dụng nó.


4

Bạn đang hỏi có makenên cài đặt trên máy chủ sản xuất không, nhưng câu hỏi thực sự của tôi sẽ là: Ai có quyền truy cập vào máy chủ sản xuất đó và bạn có biện pháp bảo vệ nào để đối phó với sự xâm nhập? Nếu makekhông được cài đặt nhưng ai đó có quyền roottruy cập, hãy đoán xem? Họ có thể tự cài đặt makevà bất cứ thứ gì họ muốn.

Thực tế khắc nghiệt về bảo mật máy tính cũng nhiều như bạn muốn ngăn chặn truy cập không mong muốn, bị ám ảnh bởi việc chặn truy cập không quan trọng bằng:

  1. Ai có quyền truy cập vào máy chủ?
  2. Bạn có thể làm gì để quay trở lại sau khi nghỉ ngơi?

Tất cả phụ thuộc vào loại công việc bạn làm. Tôi làm việc chủ yếu trong thế giới máy chủ web và thái độ của tôi về cơ bản, bất kỳ ai nhận được quyền truy cập máy chủ sản xuất từ ​​tôi đều cần chứng minh kỹ năng, kiến ​​thức & sự trưởng thành. Đó là nó. Đôi khi phải mất một vài ngày. Đôi khi phải mất vài tháng. Nhưng về cơ bản, dòng bảo mật tốt nhất của bạn trên các máy chủ sản xuất đang kiểm soát quyền truy cập trên đầu trang của những thứ lặt vặt khác mà chúng tôi làm để làm cứng máy chủ.


1

makebản thân nó là vô hại. Tất cả những gì nó làm là chạy các ứng dụng theo một trật tự đã đặt, tùy thuộc vào sự phụ thuộc mà bạn chỉ định và những tệp nào đã tồn tại trong hệ thống. Nó thậm chí có thể hữu ích như là một phần của quá trình cài đặt: bạn có thể sử dụng nó để đặt các tệp dựng sẵn ở nơi chúng cần đến hoặc chạy thử nghiệm đơn vị hoặc các thứ khác.

Tuy nhiên, bạn cần phải xem xét chính xác những gì bạn muốn sử dụng nó cho. Nó thường được sử dụng cùng với các trình biên dịch và các công cụ khác để xây dựng các ứng dụng và chúng có thể được sử dụng để phủ nhận một số dòng phòng thủ của bạn. Nhưng makekhông thể làm những điều này nếu các công cụ không có sẵn.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.