Câu trả lời:
Tất cả các máy chủ của tôi có tài khoản root bị vô hiệu hóa ( sp_pwdpđược đặt thành *). Điều này là để yêu cầu sudotất cả quyền truy cập root. [1] Mục đích của việc này là để kiểm tra tất cả các hoạt động siêu người dùng, vì vậy mọi người có thể thấy những gì đã được thực hiện cho hệ thống.
Đối với một tùy chọn khó hơn, bạn có thể sudoghi vào tệp nhật ký (trái ngược với syslog) và làm cho tệp chỉ được nối thêm (sử dụng chattrtrên Linux hoặc chflagstrên BSD). Bằng cách này, không ai có thể chỉnh sửa kiểm toán sau đó.
[1] Tôi cũng có chính sách không chạy shell root hoặc thực hiện shell thoát khỏi tiến trình root. (Tuy nhiên, sử dụng sudo sh -c '...'để thực hiện các đường ống hoặc chuyển hướng là được.)
Tôi dứt khoát khuyên chống lại việc vô hiệu hóa người dùng root. Đăng nhập root vô hiệu hóa hoặc hạn chế (thông qua securetty và qua sshd_config và qua PAM và qua những gì có bạn) Nếu hệ thống của bạn cho phép nó, quyền hạn gốc hoặc chia tay vai trò root (giống như cách RSBAC hiện nó.) Nhưng xin vui lòng, xin vui lòng , làm không vô hiệu hóa tài khoản root bằng cách xóa mật khẩu, nếu không sẽ không thể đăng nhập vào hệ thống thông qua sulogin. suloginđược sử dụng bởi tất cả các bản inits tôi biết trong trường hợp lỗi nghiêm trọng được báo cáo bởi fsck - và điều đó có nghĩa là bạn sẽ bị khóa khỏi hệ thống nếu hệ thống tệp gốc bị hỏng.
Để làm rõ: Bằng cách "vô hiệu hóa tài khoản root bằng cách xóa mật khẩu", ý tôi là các cơ chế khác nhau kết thúc bằng a! hoặc * trong trường mật khẩu của / etc / bóng hoặc tương tự. Tôi không có nghĩa là "thay đổi cơ chế đăng nhập root để bạn không được nhắc nhập mật khẩu."
suhoặc sudotrong hệ thống của bạn có sẵn cho người dùng đồng nghĩa với nhiều rủi ro bảo mật hơn bạn có thể tránh nếu bạn chỉ có người dùng root chuyên dụng. Đó là một vị trí được ủng hộ bởi các tác giả của phân phối bảo mật Owl (và nhà thiết kế Solar trong số họ) - unix.stackexchange.com/questions/8581/, cố gắng trình bày vị trí của họ với các tài liệu tham khảo.
fastboottùy chọn, mở khóa tài khoản root và khởi động lại để cuối cùng chạy fsckthủ công.
Tôi đã kích hoạt tài khoản root trên tất cả các máy chủ của mình. Tất cả các quản trị viên có người dùng riêng của họ và phải đăng nhập thông qua đó. Từ đó họ chuyển sang root. (ssh gốc bị vô hiệu hóa)
Giữ cho quản trị viên đếm thấp. Chỉ những người thực sự cần quyền truy cập root trên máy chủ đó mới có mật khẩu.
Tôi không phải là một fan hâm mộ của sudo. Thật quá dễ dàng để làm 'sudo bash' cho một vỏ gốc. Tôi biết điều này có thể bị vô hiệu hóa nhưng tại sao phải bận tâm? Chỉ cần giới hạn người dùng có thể thực hiện các nhiệm vụ quản trị viên và nói chuyện với nhau. Chúng tôi có một chính sách không để các thiết bị đầu cuối gốc mở không giám sát. Vì vậy, nó đăng nhập, su, làm việc, đăng xuất.
Lưu ý: Tôi làm việc tại một công ty khá nhỏ (50 nhân viên) và chúng tôi xung quanh chỉ với 2 quản trị viên bán thời gian (1 windows / 1 linux). Cách làm này có thể không phải là tốt nhất khi bạn có nhiều đơn hàng hơn. Cá nhân tôi vẫn sẽ không sử dụng sudo. Có nhiều cách khác để đăng nhập hoạt động root.
Vô hiệu hóa mật khẩu root là một "ý tưởng tốt" sai. Ngày bạn sẽ cần nó, bạn sẽ thực sự cần nó. (theo cấu hình của bạn, bạn có thể cần nó để đăng nhập ở chế độ người dùng đơn lẻ)
Vô hiệu hóa đăng nhập từ xa gốc có thể có liên quan nhưng chỉ khi bạn có thể đăng nhập cục bộ.
Và vâng, sudo nên được cài đặt trên mỗi máy chủ của bạn. Nó rất hữu ích và dễ dàng để cấu hình. Tại sao bạn muốn không sử dụng nó?
Disabling root remote login might be relevant but only if you are able to log on locally.Đây chỉ là sai lầm trắng trợn. Bạn có thể đăng nhập từ xa với bất kỳ tài khoản nào ; vô hiệu hóa đăng nhập từ xa không giới hạn bạn truy cập cục bộ.
Tôi chỉ vô hiệu hóa quyền truy cập SSH cho root và yêu cầu người dùng (thường chỉ là nhà phát triển) sử dụng khóa ssh. Có quá nhiều cuộc tấn công từ điển và thay đổi cổng SSH không phải là một lựa chọn cho chúng tôi.
Bằng cách đó, bạn không cần phải tin tưởng vào khả năng viết mật khẩu tốt của bất kỳ ai. Một khi bên trong chỉ có quản trị viên có quyền cho sudo.
Tôi biết chủ đề này thực sự cũ nhưng có một số sai sót lớn trong logic bài viết được liên kết và tôi cảm thấy "rant'ie" - sudo cho phép cả danh sách trắng và danh sách đen. Không chỉ màu đen như họ chỉ định trong bài viết được liên kết - Điều này bỏ qua ý tưởng về AAA (Xác thực, Ủy quyền & Kiểm toán) - su & sudo cho phép cả xác thực được phân loại và trách nhiệm.
Kịch bản 1 Một quản trị viên vô tình giới thiệu một số mã giả mạo cho một hệ thống, đăng nhập với quyền root, mã này có quyền truy cập đầy đủ và quản trị viên có thể không bao giờ biết chuyện gì đã xảy ra. Ít nhất với các thông tin đăng nhập được phân loại (ví dụ su / sudo), quản trị viên sẽ được nhắc xác thực nếu mã giả mạo cố gắng sử dụng quyền nâng cao ... Nếu nó không nâng cao thì việc giới hạn quyền của người dùng sẽ dẫn đến thiệt hại tối thiểu.
Kịch bản 2 Một quản trị viên lừa đảo muốn nhận thông tin / thực hiện thay đổi. Họ kết nối với bảng điều khiển (truy cập bảng điều khiển vật lý, HP iLo / tương tự hoặc truy cập bảng điều khiển vGuest), đăng nhập với quyền root và làm bất cứ điều gì họ muốn. Trừ khi có một tài khoản / thẻ truy cập được đặt tên được sử dụng để có quyền truy cập bảng điều khiển, có lẽ không có nhiều dấu vết kiểm toán.
Bạn nên yêu cầu mọi người sử dụng sudo cho mọi lệnh gốc làm chính sách. Không bao giờ có một lý do để chạy "sudo bash" hoặc tương tự, nó chỉ để thuận tiện, do sự thiếu hiểu biết hoặc để che dấu vết của một người.
Nếu bạn vô hiệu hóa đăng nhập trực tiếp vào tài khoản root, bạn sẽ làm tê liệt khả năng sửa lỗi hệ thống khi có sự cố nghiêm trọng.
Nếu bạn không thể thuyết phục quản trị viên của mình đăng nhập như chính họ và chạy sudo cho mọi lệnh chạy dưới quyền root và không thoát ra khỏi vỏ, bạn có vấn đề nghiêm trọng mà không có giải pháp kỹ thuật.
Các tác giả của Owl distribuion an toàn (và nhà thiết kế Solar) có quan điểm ngược lại được chứng minh cẩn thận; xem, ví dụ: câu trả lời /unix/8581/which-is-the-safest-way-to-get-root-privileges-sudo-su-or-login/8660#8660 cho một bài trình bày về tuyên bố của họ. Vấn đề kiểm toán các hành động siêu người dùng (người đã làm gì) cũng được giải quyết theo quan điểm của họ (về cơ bản, giải pháp là có một số người dùng root với các tên khác nhau).