it-swarm-vi.com

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ố thao tác (đặc biệt là IO chuyển hướng) thuận tiện hơn với su nhưng bảo mật-khôn ngoan đ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?
124
stribika

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

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 thử lừa bạn sau này ... họ chỉ có thể sử dụng Sudo 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ể (giống như các 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 cho đi gốc hoàn toàn. 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 đó không nhất thiết là vấn đề mà chương trình có nghĩa là giải quyết (do đó cấu hình phức tạp một cách lố bịch cú pháp tập tin).

Nhưng, Sudo-for-unrestricted-root không 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 qua 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 xem máy nào có mật khẩu nào 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 thứ 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 mật khẩu hoàn toàn cho SSH rất nguy hiểm, vì các trình tiện ích trojan đánh hơi mật khẩu được đặt vào vị trí giống như 90% các thỏa hiệp của hệ thống trong thế giới thực Tôi đã 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ó hạng nặng độc quyền RSA SecurID . 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ý.

105
mattdm

Đâ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, 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ừ mộ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 Prompt bootloader. Đ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. (* BSD's securelevel hoạt động như thế này: ở độ 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 , tính toàn vẹn , tính khả dụng . Tự khóa hệ thống của bạn có thể ngăn bạn phản ứng với 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ề sai sót của su và 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 ưu tiên 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ọ có "đã loại bỏ hoàn toàn các chương trình gốc SUID trong cài đặt mặc định" (tức 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 dưới dạng không root", sau đó là su hoặc Sudo để root "sysadmin", so với việc đăng nhập dưới dạng không root và trực tiếp bằng 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 sysadins, 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ế sulogin bằng msulogin để cho phép thiết lập với nhiều tài khoản root: msulogin cho phép một người cũng nhập tên người dùng khi chuyển sang chế độ một 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 ).

10

Bạn dường như đang giả định rằng việc sử dụng Sudo luô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 web 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 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 quyền root.

Vì vậy nếu env_reset được bật (mặc định), kẻ tấn công không thể ghi đè PATH 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).

4
Cedric

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.

4
Šimon Tóth

Tôi chỉ muốn thêm một chút gì đó 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 toàn bộ bảo mật là sự 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 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

3
user5520

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 Sudo hoặc su, thì hãy sử dụng mật mã một lần cho Sudosu.

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 .

2
nowen

Bạn cũng có thể xem PrivacyIDEA , điều này 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. I E. nếu bạn có nhiều máy và nhiều 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.

0
cornelinux