Liệu / usr / sbin / nologin làm vỏ đăng nhập có phục vụ mục đích bảo mật không?


77

Trong /etc/passwdtệp của tôi , tôi có thể thấy rằng www-datangười dùng được sử dụng bởi Apache, cũng như tất cả các loại người dùng hệ thống, có /usr/sbin/nologinhoặc /bin/falselà vỏ đăng nhập của họ. Ví dụ, đây là một lựa chọn các dòng:

daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
games:x:5:60:games:/usr/games:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
syslog:x:101:104::/home/syslog:/bin/false
whoopsie:x:109:116::/nonexistent:/bin/false
mark:x:1000:1000:mark,,,:/home/mark:/bin/bash

Do đó, nếu tôi cố gắng trao đổi với bất kỳ người dùng nào trong số này (điều mà đôi khi tôi muốn làm để kiểm tra sự hiểu biết của tôi về quyền của họ và có lẽ có ít nhất các lý do khác nửa chừng), tôi đã thất bại:

mark@lunchbox:~$ sudo su www-data
This account is currently not available.
mark@lunchbox:~$ sudo su syslog
mark@lunchbox:~$ 

Tất nhiên, nó không có nhiều bất tiện, bởi vì tôi vẫn có thể khởi chạy một vỏ cho chúng thông qua một phương pháp như thế này:

mark@lunchbox:~$ sudo -u www-data /bin/bash
www-data@lunchbox:~$ 

Nhưng điều đó chỉ khiến tôi tự hỏi mục đích nào được phục vụ bằng cách từ chối những người dùng này một vỏ đăng nhập. Nhìn quanh internet để tìm lời giải thích, nhiều người cho rằng điều này có liên quan đến bảo mật và mọi người dường như đồng ý rằng việc thay đổi vỏ đăng nhập của những người dùng này theo một cách nào đó là một ý tưởng tồi. Đây là một bộ sưu tập các trích dẫn:

Đặt shell của người dùng Apache thành một thứ gì đó không tương tác thường là cách thực hành bảo mật tốt (thực sự tất cả người dùng dịch vụ không phải đăng nhập tương tác nên đặt vỏ của họ thành thứ gì đó không tương tác).

- https://serverfault.com/a/559315/147556

Shell cho dữ liệu www của người dùng được đặt thành / usr / sbin / nologin và nó được đặt vì một lý do rất chính đáng.

- https://askubfox.com/a/486661/119754

[tài khoản hệ thống] có thể là lỗ hổng bảo mật , đặc biệt nếu chúng có vỏ được kích hoạt:

  • Xấu

    bin:x:1:1:bin:/bin:/bin/sh
  • Tốt

    bin:x:1:1:bin:/bin:/sbin/nologin

- https://unix.stackexchange.com/a/78996/29001

Vì lý do bảo mật, tôi đã tạo một tài khoản người dùng không có vỏ đăng nhập để chạy máy chủ Tomcat:

# groupadd tomcat
# useradd -g tomcat -s /usr/sbin/nologin -m -d /home/tomcat tomcat

- http://www.puschitz.com/InstallingTomcat.html

Mặc dù các bài đăng này nằm trong thỏa thuận nhất trí rằng việc không cung cấp cho người dùng hệ thống các vỏ đăng nhập thực sự là tốt cho bảo mật, nhưng không ai trong số họ biện minh cho khiếu nại này và tôi không thể tìm thấy lời giải thích về nó ở bất cứ đâu.

Cuộc tấn công nào chúng ta đang cố gắng tự bảo vệ mình bằng cách không cho những người dùng này đăng nhập thực sự?


Câu trả lời:


51

Nếu bạn xem nologintrang người đàn ông, bạn sẽ thấy mô tả sau đây.

đoạn trích

nologin hiển thị một thông báo rằng tài khoản không có sẵn và thoát ra khác không. Nó được dự định như một trường vỏ thay thế để từ chối quyền truy cập đăng nhập vào tài khoản.

Nếu tệp /etc/nologin.txttồn tại, nologinhiển thị nội dung của nó cho người dùng thay vì thông báo mặc định.

Mã thoát được trả về nologinluôn là 1.

Vì vậy, mục đích thực tế nologinchỉ là khi người dùng cố gắng đăng nhập bằng tài khoản sử dụng tài khoản đó /etc/passwdđể họ được hiển thị một thông báo thân thiện với người dùng và bất kỳ tập lệnh / lệnh nào cố gắng sử dụng đăng nhập này nhận được mã thoát của 1.

Bảo vệ

Liên quan đến bảo mật, thông thường bạn sẽ thấy một trong hai /sbin/nologinhoặc đôi khi /bin/false, trong số những thứ khác trong lĩnh vực đó. Cả hai đều phục vụ cùng một mục đích, nhưng /sbin/nologincó lẽ là phương pháp ưa thích. Trong mọi trường hợp, họ sẽ giới hạn quyền truy cập trực tiếp vào hệ vỏ như tài khoản người dùng cụ thể này.

Tại sao điều này được coi là có giá trị đối với an ninh?

"Tại sao" khó mô tả đầy đủ, nhưng giá trị trong việc giới hạn tài khoản của người dùng theo cách này, là nó cản trở truy cập trực tiếp qua loginứng dụng khi bạn cố gắng truy cập bằng tài khoản người dùng đã nói.

Sử dụng nologinhoặc /bin/falsethực hiện điều này. Hạn chế bề mặt tấn công của hệ thống của bạn là một kỹ thuật phổ biến trong thế giới bảo mật, cho dù vô hiệu hóa dịch vụ trên các cổng cụ thể hay giới hạn bản chất của thông tin đăng nhập trên hệ thống của một người.

Vẫn có những cách hợp lý hóa khác để sử dụng nologin. Ví dụ: scpsẽ không còn hoạt động với tài khoản người dùng không chỉ định shell thực tế, như được mô tả trong Hỏi & Đáp về ServerFault này có tiêu đề: Sự khác biệt giữa / sbin / nologin và / bin / false là gì? .


They both serve the same purpose, but /sbin/nologin is probably the preferred method.Từ quan điểm bảo mật, `/ sbin / nologin`` không phải là phương thức ưa thích; nó lãng phí thời gian và chu kỳ cung cấp một phản ứng. Mặc dù không cung cấp bảo mật đặc biệt tốt; chúng là các biện pháp chuyên sâu, nhưng thực tế chúng không ngăn ai đó chạy lệnh như một người dùng nhất định.
Bắn Parthian

4
@ParthianShot thời gian và chu kỳ cần thiết để lặp lại một chuỗi mã hóa cứng, liên quan đến bất kỳ công việc nào mà HĐH đang làm dù sao để tìm kiếm lớp vỏ nào để thực thi cho người dùng, dường như không quan trọng đối với bất kỳ ai xây dựng từ chối dịch vụ tấn công. slm đang đề xuất nologinlà phương pháp ưa thích vì lý do UX, không phải là bảo mật - thực hiện sudo su someuserkhông có gì xảy ra vì vỏ đăng nhập của chúng falsegây nhầm lẫn. Ngoài ra, cả hai điều này đều ngăn ai đó chạy lệnh như một người dùng nhất định trong một số trường hợp, được mô tả trong câu trả lời ở đây.
Đánh dấu Amery

28

Chắc chắn nó phục vụ một mục đích bảo mật. Ví dụ, hãy xem lỗi dưới đây được đệ trình cho một người dùng hệ thống có vỏ.

Máy chủ debian của tôi đã bị xâm nhập do tài khoản daemon có vỏ đăng nhập hợp lệ và có samba mở để truy cập internet. Việc đột nhập được thực hiện bằng cách đặt mật khẩu từ xa qua samba cho tài khoản daemon và đăng nhập thông qua ssh. Một số khai thác root cục bộ sau đó đã được sử dụng để SỞ HỮU máy chủ của tôi.

Tôi muốn đề nghị bạn đọc câu trả lời tuyệt vời này của Gilles, nơi ông cũng đã cung cấp các liên kết đến một số lỗi.

Có một số lỗi được gửi về vấn đề này trong Debian (274229, 330882, 581899), hiện đang mở và được phân loại là danh sách mong muốn của Hồi. Tôi có xu hướng đồng ý rằng đây là những lỗi và người dùng hệ thống nên có / bin / false làm vỏ của họ trừ khi có vẻ cần phải làm khác.


... Tôi không thấy điều đó thực sự phụ thuộc cụ thể vào trình bao khai báo cho người dùng. Nếu kẻ tấn công chỉ chạy ssh user@site, và nó đã hoạt động, chúng sẽ không tiếp tục cố gắng ssh user@site /bin/bash, nhưng tôi khá chắc chắn rằng nó vẫn hoạt động bất kể vỏ khai báo.
Bắn Parthian

2
@ParthianShot, bằng chứng giai thoại: trên máy chủ CentOS của tôi, khi trình bao của tài khoản được đặt thành / sbin / nologin ssh user@site /bin/bashtrả về một This account is currently not available.tin nhắn đơn giản . Ngoài ra, câu trả lời này cho biết nologin bảo vệ quyền truy cập SSH
metavida

@ParthianShot dựa trên mô tả, đó không phải là những gì đã xảy ra. Điều gì đã xảy ra là: Samba bị định cấu hình sai; Kẻ tấn công đã cấu hình truy cập ssh qua Samba; Kẻ tấn công đăng nhập thông qua ssh. Mặc dù trường hợp này rõ ràng là lỗi của sysadmin, nhưng nếu bạn thay thế "Samba bị định cấu hình sai" bằng "dịch vụ có thể khai thác", thì việc ngăn chặn truy cập đăng nhập có ý nghĩa, vì nó làm giảm bề mặt tấn công. Tất nhiên, nếu việc khai thác cho phép thực thi cục bộ, có quyền truy cập ssh chứ không phải không, sẽ tạo ra rất ít sự khác biệt.
Marcus

18

Để thêm vào câu trả lời tuyệt vời của @slm và @ramesh:

Có, như bạn đã chỉ ra, bạn vẫn có thể chuyển sang người dùng có nologin làm vỏ mặc định của họ bằng cách chạy sudovới trình bao được xác định, nhưng trong trường hợp này, bạn phải:

  1. Đăng nhập với tư cách người dùng khác có vỏ hợp lệ
  2. Có quyền sudo được cấu hình để người dùng đó chạy sulệnh và
  3. Có cố gắng su của bạn đã đăng nhập vào nhật ký sudoers (tất nhiên giả sử rằng đăng nhập sudo được bật).

Người dùng có nologin được xác định là vỏ mặc định của họ thường có đặc quyền cao hơn / có khả năng gây thiệt hại cho hệ thống nhiều hơn so với người dùng thông thường, do đó họ không thể đăng nhập trực tiếp để hạn chế thiệt hại mà vi phạm hệ thống của bạn có thể bị ảnh hưởng .


7

Ngoài các câu trả lời tuyệt vời đã được đưa ra, nó phục vụ một mục đích khác.

Nếu bạn chạy một daemon FTP trên máy chủ của mình, nó sẽ kiểm tra lớp vỏ đăng nhập của người dùng cố gắng đăng nhập. Nếu shell không được liệt kê /etc/shells, nó không cho phép họ đăng nhập. Vì vậy, việc cung cấp cho các tài khoản daemon một lớp vỏ đặc biệt sẽ ngăn người khác sửa đổi tài khoản qua FTP.


7

Bên cạnh những câu trả lời tuyệt vời đã được đưa ra, tôi có thể nghĩ về kịch bản sau đây.

Một lỗi bảo mật trong một dịch vụ chạy như một người dùng bị hạn chế cho phép viết một tệp như người dùng đó. Tập tin này có thể là ~ / .ssh / ủy quyền.

Điều này cho phép kẻ tấn công đăng nhập trực tiếp vào hệ vỏ, điều này sẽ giúp việc thực hiện leo thang đặc quyền dễ dàng hơn nhiều.

Không cho phép một vỏ đăng nhập sẽ làm cho tùy chọn này khó khăn hơn rất nhiều.


1

Nói chung tôi sẽ nói / bin / false và / sbin / nologin giống nhau - nhưng tôi cho rằng nó phụ thuộc vào máy chủ SSH nào bạn đang sử dụng.

Tôi sẽ rất thận trọng khi chỉ ra khai thác gần đây trên OpenSSH này có vẻ như ảnh hưởng đến / bin / thông tin đăng nhập sai nhưng KHÔNG / sbin / nologin. Tuy nhiên, quy định rằng Dropbear khác biệt theo cách này (cũng là cách khai thác đặc biệt áp dụng cho OpenSSH).

Khai thác ảnh hưởng đến hầu hết các phiên bản:

7.2p1 trở xuống (tất cả các phiên bản; có niên đại ~ 20 năm) Với bật chuyển tiếp X11

https://www.Exloit-db.com/Exloits/39569/

Vì vậy, dựa trên điều này - Cá nhân tôi sẽ làm / sbin / nologin tuy nhiên tôi không chắc liệu điều này có thể ảnh hưởng đến các dịch vụ tạo mục nhập / bin / false trong / etc / passwd hay không. Bạn có thể thử nghiệm và xem kết quả của mình, nhưng vui lòng tự chịu rủi ro! Tôi cho rằng trường hợp xấu nhất bạn chỉ có thể thay đổi lại và khởi động lại bất kỳ (các) dịch vụ ảnh hưởng nào. Cá nhân tôi có khá nhiều mục sử dụng / bin / false - Không chắc tôi có muốn làm phiền với điều này không vì chuyển tiếp X11 không phải là thứ tôi đã kích hoạt;)

Nếu bạn sử dụng OpenSSH (tôi nghĩ nhiều người ...) VÀ bật chuyển tiếp X11 - bạn có thể muốn xem xét / sbin / nologin (hoặc có thể chuyển sang Dropbear).


0

Nói chung, thực tiễn bảo mật tốt là đặt tài khoản dịch vụ và ứng dụng thành đăng nhập không tương tác. Người dùng được ủy quyền vẫn có thể có quyền truy cập vào các tài khoản đó bằng SU hoặc SUDO nhưng tất cả các hành động của họ được theo dõi trong tệp nhật ký Sudoers và có thể được truy ngược lại cho người dùng đã thực hiện các lệnh theo đặc quyền tài khoản dịch vụ. Đây là lý do tại sao điều quan trọng là lưu trữ tệp nhật ký trong hệ thống quản lý nhật ký tập trung để quản trị viên hệ thống không có quyền truy cập để thay đổi tệp nhật ký. Người dùng thực thi các lệnh trong SU hoặc SUDO đã được phép truy cập hệ thống.

Mặt khác, người dùng bên ngoài hoặc trái phép vào hệ thống sẽ hoàn toàn không có quyền truy cập để đăng nhập bằng các tài khoản đó và đó là một biện pháp bảo mật.


0

Vâng, nó phục vụ một mục đích bảo mật. Đó là một biện pháp phòng thủ chuyên sâu.

Lý do cốt lõi mà nó phục vụ cho mục đích là có nhiều bit phần mềm sẽ xác thực một số dạng thông tin đăng nhập cho một người dùng được chỉ định và sau đó sử dụng shell đăng nhập của người dùng đó để chạy lệnh. Có lẽ ví dụ đáng chú ý nhất là SSH. Nếu bạn xác thực thành công người dùng qua SSH, SSH sẽ khởi chạy trình đăng nhập của người dùng (hoặc sử dụng nó để chạy lệnh bạn cung cấp, nếu bạn sử dụng ssh someuser@example.com 'command to run'cú pháp).

Tất nhiên, lý tưởng nhất là kẻ tấn công sẽ không thể xác thực là người dùng. Nhưng giả sử tình huống sau đây xảy ra:

  • Máy chủ mà bạn kiểm soát đang chạy dịch vụ web với tư cách là người dùng có thư mục chính và vỏ đăng nhập
  • Kẻ tấn công phát hiện ra lỗ hổng trong dịch vụ đó cho phép kẻ tấn công ghi các tệp vào thư mục nhà của người dùng

Bây giờ kẻ tấn công của bạn có thể viết khóa công khai SSH ~/.ssh/authorized_keys, sau đó SSH vào và - bùng nổ! - họ đã có quyền truy cập shell vào máy chủ của bạn.

Nếu người dùng thay vào đó /usr/sbin/nologinlà vỏ đăng nhập của họ, thì ngay cả sau khi kẻ tấn công viết thành công khóa công khai vào authorized_keys, nó không hữu ích với họ. Tất cả những gì nó cho phép họ làm là chạy từ xa nologin, điều này không hữu ích lắm. Họ không thể có được vỏ, và cuộc tấn công của họ đã được giảm nhẹ.

Trong trường hợp kịch bản này có vẻ rất giả thuyết, tôi muốn lưu ý rằng tôi đã bị nhắm mục tiêu chính xác bởi cuộc tấn công này vào một thời điểm nào đó trong năm 2015, khoảng một năm sau khi tôi hỏi câu hỏi này. Giống như một tên ngốc chết tiệt, tôi đã để lại một ví dụ Redis không có mật khẩu mở ra cho thế giới. Nó bị nhắm mục tiêu bởi cuộc tấn công bẻ khóa Redis , trong đó kẻ tấn công chèn khóa công khai SSH vào cơ sở dữ liệu Redis của bạn, sau đó gửi lệnh yêu cầu Redis viết nội dung của cơ sở dữ liệu .ssh/authorized_keys, sau đó cố gắng SSH vào. Tôi đã được cứu khỏi hậu quả về sự bất tài của riêng tôi chỉ bởi thực tế là những người duy trì redis-servergói Apt (mà tôi đã sử dụng để cài đặt Redis) đã có được sự khôn ngoan để khiến nó chạy Redis như mộtredisngười dùng không có thư mục nhà hoặc vỏ đăng nhập; nếu không phải là họ, máy chủ của tôi có thể đã bị chuộc hoặc kết thúc một phần của mạng botnet của một số hacker.

Trải nghiệm đó mang lại cho tôi một mức độ khiêm tốn và khiến tôi đánh giá cao tầm quan trọng của việc phòng thủ theo chiều sâu và đặc biệt là không cấp vỏ đăng nhập cho các tài khoản chạy máy chủ web, cơ sở dữ liệu và các dịch vụ nền khác.

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.