Đó là cách an toàn nhất để có được quyền root: sudo, su hoặc đăng nhập?

Tôi muốn có tài khoản root an toàn ngay cả khi người dùng không có quyền của tôi bị xâm phạm.

Trên Ubuntu, bạn chỉ có thể sử dụng sudo vì "lý do bảo mật" theo mặc định. Tuy nhiên tôi không chắc chắn rằng nó an toàn hơn bất kỳ việc sử dụng đăng nhập trên bảng điều khiển chế độ văn bản. Có quá nhiều thứ có thể sai nếu kẻ tấn công có thể chạy mã như người dùng bình thường của tôi. Ví dụ: thêm bí danh, thêm nội dung vào PATH của tôi, đặt các keylogger LD_PRELOAD và X11 chỉ để đề cập đến một vài. Ưu điểm duy nhất tôi có thể thấy là thời gian chờ vì vậy tôi không bao giờ quên đăng xuất.

Tôi có cùng nghi ngờ về su nhưng nó thậm chí không có giới hạn thời gian. Một số hoạt động (đặc biệt là chuyển hướng IO) thuận tiện hơn với su nhưng bảo mật thông minh thì điều này dường như tồi tệ hơn.

Đăng nhập vào bảng điều khiển chế độ văn bản dường như là an toàn nhất. Vì nó được bắt đầu bởi init nếu kẻ tấn công có thể kiểm soát PATH hoặc LD_PRELOAD, anh ta đã root. Các sự kiện nhấn phím không thể bị chặn bởi các chương trình chạy trên X. Tôi không biết liệu các chương trình chạy trên X có thể chặn [ctrl] + [alt] + [f1] (và mở cửa sổ toàn màn hình trông giống như bảng điều khiển) hoặc nó an toàn như [ctrl] + [alt] + [del] trên Windows. Bên cạnh đó, vấn đề duy nhất tôi thấy là thiếu thời gian chờ.

Vì vậy, tôi đang thiếu một cái gì đó? Tại sao các chàng trai Ubuntu quyết định chỉ cho phép sudo? Tôi có thể làm gì để cải thiện tính bảo mật của bất kỳ phương pháp nào?

Còn SSH thì sao? Theo truyền thống, root không thể đăng nhập thông qua SSH. Nhưng sử dụng logic trên đây sẽ không phải là điều an toàn nhất để làm:

• cho phép root thông qua SSH
• chuyển sang chế độ văn bản
• đăng nhập bằng root
• ssh sang máy khác
• đăng nhập bằng root?

An ninh luôn là về việc đánh đổi. Giống như máy chủ hoạt động trong một nơi an toàn, không được cắm điện, ở dưới đáy đại dương, rootsẽ an toàn nhất nếu không có cách nào để truy cập nó.

Các cuộc tấn công LD_PRELOAD và PATH giống như các cuộc tấn công mà bạn mô tả cho rằng đã có kẻ tấn công có quyền truy cập vào tài khoản của bạn hoặc ít nhất là vào các dotfiles của bạn. Sudo hoàn toàn không bảo vệ chống lại điều đó - nếu họ có mật khẩu của bạn, sau tất cả, không cần phải cố gắng lừa bạn sau này ... họ có thể sử dụng sudo ngay bây giờ .

Điều quan trọng là phải xem xét những gì Sudo được thiết kế ban đầu: ủy thác các lệnh cụ thể (như những lệnh để quản lý máy in) cho "quản trị viên phụ" (có lẽ là học sinh tốt nghiệp trong phòng thí nghiệm) mà không bỏ hoàn toàn root. Sử dụng sudo để làm mọi thứ là cách sử dụng phổ biến nhất tôi thấy bây giờ, nhưng nó không nhất thiết là vấn đề mà chương trình có nghĩa là phải giải quyết (do đó cú pháp tệp cấu hình phức tạp một cách lố bịch).

Nhưng, sudo-for-unrestricted-root lại giải quyết một vấn đề bảo mật khác: khả năng quản lý mật khẩu gốc. Tại nhiều tổ chức, những xu hướng này được truyền đi như kẹo, được viết trên bảng trắng và để nguyên như vậy mãi mãi. Điều đó để lại một lỗ hổng lớn, vì việc thu hồi hoặc thay đổi quyền truy cập trở thành một số lượng sản xuất lớn. Ngay cả việc theo dõi những gì máy có mật khẩu là một thách thức - hãy để một mình theo dõi ai biết cái nào.

Hãy nhớ rằng hầu hết "tội phạm mạng" đến từ bên trong. Với tình huống mật khẩu gốc được mô tả, thật khó để theo dõi ai đã làm gì - một cái gì đó sudo với các giao dịch đăng nhập từ xa khá tốt.

Trên hệ thống nhà của bạn, tôi nghĩ đó thực sự là vấn đề thuận tiện hơn khi không phải nhớ hai mật khẩu. Có thể nhiều người chỉ đơn giản là đặt chúng giống nhau - hoặc tệ hơn, đặt chúng giống nhau ban đầu và sau đó để chúng không đồng bộ, khiến mật khẩu gốc bị thối.

Sử dụng tất cả mật khẩu cho SSH rất nguy hiểm, vì các trình nền ssh trojan đánh hơi mật khẩu được đưa vào vị trí giống như 90% các thỏa hiệp trong hệ thống trong thế giới thực mà tôi từng thấy. Sử dụng các khóa SSH tốt hơn nhiều và đây cũng có thể là một hệ thống hoàn toàn khả thi để truy cập root từ xa.

Nhưng vấn đề hiện tại là bạn đã chuyển từ quản lý mật khẩu sang quản lý khóa và các khóa ssh không thực sự rất dễ quản lý. Không có cách nào để hạn chế các bản sao và nếu ai đó tạo ra một bản sao, họ có tất cả những nỗ lực mà họ muốn để chế tạo cụm mật khẩu. Bạn có thể đưa ra chính sách nói rằng các khóa phải được lưu trữ trên các thiết bị di động và chỉ được gắn khi cần, nhưng không có cách nào để thực thi điều đó - và bây giờ bạn đã giới thiệu khả năng thiết bị di động bị mất hoặc bị đánh cắp.

Bảo mật cao nhất sẽ đến thông qua các khóa một lần hoặc mã thông báo mã hóa dựa trên thời gian / truy cập. Chúng có thể được thực hiện trong phần mềm, nhưng phần cứng chống giả mạo thậm chí còn tốt hơn. Trong thế giới nguồn mở, có WiKiD , YubiKey hoặc LinOTP , và tất nhiên cũng có RSA SecurID hạng nặng độc quyền . Nếu bạn đang ở trong một tổ chức từ trung bình đến lớn, hoặc thậm chí là một tổ chức nhỏ có ý thức bảo mật, tôi khuyên bạn nên xem xét một trong những cách tiếp cận này để truy cập quản trị.

Tuy nhiên, điều đó có thể quá mức cần thiết cho gia đình, nơi bạn không thực sự gặp rắc rối về quản lý - miễn là bạn tuân theo các thực tiễn bảo mật hợp lý.

Đây là một câu hỏi rất phức tạp. mattdm đã bao gồm nhiều điểm .

Giữa su và sudo, khi bạn xem xét một người dùng, su an toàn hơn một chút ở chỗ kẻ tấn công đã tìm thấy mật khẩu của bạn không thể có được quyền root ngay lập tức. Nhưng tất cả chỉ cần cho kẻ tấn công tìm lỗ hổng cục bộ (tương đối không phổ biến) hoặc cài đặt trojan và chờ bạn chạy su.

Sudo có lợi thế ngay cả khi đăng nhập bảng điều khiển khi có nhiều người dùng. Ví dụ: nếu một hệ thống được cấu hình với nhật ký chống giả mạo từ xa, bạn luôn có thể tìm ra ai đã chạy sudo lần cuối (hoặc tài khoản của ai bị xâm phạm), nhưng bạn không biết ai đã nhập mật khẩu gốc trên bảng điều khiển.

Tôi nghi ngờ quyết định của Ubuntu một phần là vì sự đơn giản (chỉ cần nhớ một mật khẩu) và một phần vì lợi ích bảo mật và dễ dàng phân phối thông tin xác thực trên các máy dùng chung (doanh nghiệp hoặc gia đình).

Linux không có khóa chú ý an toàn hoặc giao diện người dùng an toàn khác để xác thực. Theo như tôi biết thì ngay cả OpenBSD cũng không có. Nếu bạn lo lắng về quyền truy cập root, bạn có thể vô hiệu hóa quyền truy cập root từ hệ thống đang chạy hoàn toàn: nếu bạn muốn là root, bạn sẽ cần phải nhập một cái gì đó tại dấu nhắc của bộ tải khởi động. Điều này rõ ràng là không phù hợp cho tất cả các trường hợp sử dụng. (* Bảo mật của BSD hoạt động như thế này: ở mức bảo mật cao, có những điều bạn không thể làm mà không khởi động lại, chẳng hạn như hạ thấp bảo mật hoặc truy cập trực tiếp các thiết bị thô được gắn.)

Hạn chế những cách người ta có thể trở thành root không phải lúc nào cũng là lợi ích cho bảo mật. Hãy nhớ thành viên thứ ba của bộ ba bảo mật : bảo mật , liêm chính , sẵn có . Khóa mình khỏi hệ thống của bạn có thể ngăn bạn phản ứng với một sự cố.

Các nhà thiết kế của bản phân phối OpenWall GNU / * / Linux được bảo mật cũng đã bày tỏ ý kiến ​​phê phán về su(để trở thành root) và sudo. Bạn có thể thích đọc chủ đề này:

... Thật không may, cả su và sudo đều tinh tế nhưng thiếu sót về cơ bản.

Ngoài việc thảo luận về những sai sót suvà những thứ khác, Solar Designer còn nhắm đến một lý do cụ thể để sử dụng su:

Vâng, nó từng là trí tuệ sysadmin phổ biến để "su root" chứ không phải đăng nhập với quyền root. Một vài người, khi được hỏi, thực sự có thể đưa ra một lý do hợp lệ cho sở thích này sẽ đề cập đến trách nhiệm giải trình tốt hơn đạt được với phương pháp này. Vâng, đây thực sự là một lý do tốt để ủng hộ phương pháp này. Nhưng đó cũng là người duy nhất. ...(đọc thêm)

Trong bản phân phối của họ, họ đã "loại bỏ hoàn toàn các chương trình gốc SUID trong cài đặt mặc định" (nghĩa là bao gồm su; và họ không sử dụng các khả năng cho việc này):

Đối với máy chủ, tôi nghĩ mọi người cần xem xét lại và, trong hầu hết các trường hợp, không cho phép người dùng sử dụng su và sudo. Không có bảo mật bổ sung từ "đăng nhập là không root", sau đó su hoặc sudo để root "sysadmin" khôn ngoan ", so với đăng nhập là không root và trực tiếp root (hai phiên riêng biệt). Ngược lại, cách tiếp cận sau là cách duy nhất đúng, theo quan điểm bảo mật:

http://www.openwall.com/lists/owl-users/2004/10/20/6

(Đối với trách nhiệm giải trình của nhiều hệ thống, hệ thống cần hỗ trợ có nhiều tài khoản đặc quyền gốc, giống như Owl.)

(Đối với máy tính để bàn có X, điều này trở nên khó khăn hơn.)

Bạn cũng hoàn toàn phải đối phó với ...

BTW, họ đã thay thế suloginbằng msulogincách cho phép thiết lập bằng nhiều tài khoản root: msulogincho phép một người cũng nhập tên người dùng khi chuyển sang chế độ người dùng (và duy trì "trách nhiệm") (thông tin này xuất phát từ cuộc thảo luận này bằng tiếng Nga ) .

Bạn dường như đang giả định rằng việc sử dụng sudoluôn bảo tồn các biến môi trường, nhưng điều này không phải lúc nào cũng đúng. Đây là một đoạn trích từ trang sudo:

Có hai cách riêng biệt để đối phó với các biến môi trường. Theo mặc định, tùy chọn sudoers env_reset được bật. Điều này khiến các lệnh được thực thi với môi trường tối thiểu có chứa TERM, PATH, HOME, SHELL, LOGNAME, USER và USERNAME ngoài các biến từ quy trình gọi được cho phép bởi các tùy chọn sudoers env_check và env_keep. Có một danh sách trắng cho các biến môi trường.

Tuy nhiên, nếu tùy chọn env_reset bị vô hiệu hóa trong sudoers, bất kỳ biến nào không bị từ chối rõ ràng bởi các tùy chọn env_check và env_delete đều được kế thừa từ quá trình gọi. Trong trường hợp này, env_check và env_delete hoạt động như một danh sách đen. Vì không thể đưa vào danh sách đen tất cả các biến môi trường nguy hiểm tiềm tàng, nên việc sử dụng hành vi env_reset mặc định được khuyến khích.

Trong mọi trường hợp, các biến môi trường có giá trị bắt đầu bằng () được loại bỏ vì chúng có thể được hiểu là các hàm bash. Danh sách các biến môi trường mà sudo cho phép hoặc từ chối được chứa trong đầu ra của sudo -V khi chạy dưới dạng root.

Vì vậy, nếu env_resetđược bật (mặc định), kẻ tấn công không thể ghi đè PATHcác biến môi trường của bạn hoặc các biến môi trường khác (trừ khi bạn đặc biệt thêm chúng vào danh sách trắng các biến cần được bảo tồn).

Cách tiếp cận an toàn nhất là đăng nhập ssh bằng cách sử dụng (ít nhất) khóa dài 2048 (đã tắt đăng nhập mật khẩu) bằng thiết bị vật lý để lưu trữ khóa.

Tôi chỉ muốn thêm một chút ngoài chủ đề. (đối với chủ đề một kiểm tra '/ bin / su -' ở đây sau)

Tôi nghĩ rằng "bảo mật" ở trên cũng nên được liên kết với dữ liệu thực tế mà chúng tôi muốn bảo mật.

Nó sẽ và nó sẽ khác nếu chúng ta muốn bảo mật: my_data, my_company_data, my_company_network.

Thông thường, nếu tôi nói về bảo mật, tôi cũng nói về "bảo mật dữ liệu" và sao lưu. Chúng tôi cũng có thể thêm các hệ thống chịu lỗi và tương tự.

Vì điều này, tôi nghĩ rằng bảo mật nói chung là một điểm cân bằng giữa khả năng sử dụng, "bảo mật dữ liệu" và nỗ lực cần thiết để thực hiện một hệ thống an toàn.

Mục tiêu của Ubuntu là, và chủ yếu vẫn là, người dùng cuối cùng: Sudo là mặc định.

Fedora là phiên bản miễn phí của RedHat, lần lượt được nhiều máy chủ định hướng hơn: Sudo từng bị vô hiệu hóa.

Đối với các bản phân phối khác, tôi không có thông tin trực tiếp.

Tôi đang sử dụng ngay bây giờ, chủ yếu, fedora. Và là một người dùng kiểu cũ, tôi không bao giờ gõ 'su'. Nhưng tôi có thể gõ "/ bin / su -" trong một thời gian rất ngắn ngay cả khi tôi không chính xác là một người đánh máy. Biến PATH .. không phải là một vấn đề (tôi gõ đường dẫn). Ngoài ra, về nguyên tắc "-" (trừ) sẽ loại bỏ các biến môi trường người dùng của tôi và chỉ tải các biến gốc. tức là tránh một số rắc rối có thể xảy ra. Có lẽ cũng là LS_PRELOAD.

Đối với phần còn lại tôi đoán rằng @mattdm khá chính xác.

Nhưng hãy đặt nó vào đúng ô. Giả sử rằng một bộ thông minh kịch bản có quyền truy cập vào dữ liệu của tôi. Bạn nghĩ anh ta sẽ làm cái quái gì với nó? - Công bố hình ảnh của tôi? của tôi - Cố gắng tìm ra tên bạn gái của tôi và nói với cô ấy rằng tôi truy cập các trang web khiêu dâm?

Trong ảnh một người dùng, hai tình huống xấu nhất là: - Đứa trẻ xóa tất cả dữ liệu của tôi: cho vui hoặc do nhầm lẫn - Đứa trẻ sử dụng máy của tôi để tạo thêm một cuộc tấn công vào một thực thể khác. Hoặc các mục tiêu tương tự.

Đối với trường hợp đầu tiên, tôi đã đề cập ở trên, nỗ lực sao lưu dự phòng tốt hơn là bảo mật mạng. Đúng, bạn đang tiết kiệm. Tôi có nghĩa là một sự cố phần cứng không phải là khác nhau.

Trường hợp thứ hai là tinh tế hơn. Nhưng có những tín hiệu về các hoạt động này. Trong mọi trường hợp, bạn có thể làm điều có thể, nhưng tôi sẽ không cấu hình PC nhà của tôi để được bảo vệ khỏi các cuộc tấn công khủng bố!

Tôi sẽ bỏ qua các kịch bản khác.

chúc mừng F

Nếu mối quan tâm là tài khoản người dùng bị xâm nhập có thể được sử dụng để đánh hơi mật khẩu được sử dụng cho sudohoặc susau đó sử dụng mật mã một lần cho sudovà su.

Bạn có thể buộc sử dụng các phím cho người dùng từ xa, nhưng điều đó có thể không vượt qua được các mục đích tuân thủ. Có thể hiệu quả hơn khi thiết lập hộp cổng SSH yêu cầu xác thực hai yếu tố, sau đó cho phép sử dụng khóa từ đó. Đây là tài liệu về thiết lập như vậy: Bảo mật triển khai SSH của bạn bằng xác thực hai yếu tố WiKID .

Bạn cũng có thể xem qua PrivacyIDEA , nó không chỉ cung cấp cho bạn khả năng sử dụng OTP để đăng nhập vào máy (hoặc để thực hiện su / sudo) mà còn có thể thực hiện OTP ngoại tuyến.

Hơn nữa, nó có khả năng quản lý các khóa SSH của bạn. Tức là nếu bạn có nhiều máy và một số người dùng root, tất cả các khóa SSH được lưu trữ tập trung. Do đó, thật dễ dàng để "thu hồi" / xóa khóa SSH, nếu khóa đó không thể tin cậy được nữa.

Tất nhiên có các nhiệm vụ tổ chức và quy trình làm việc, để bảo mật hệ thống.