Tại sao người dùng 'bin' cần vỏ đăng nhập?

Trong quá trình kiểm toán /var/log/auth.logtrên một trong những máy chủ web công cộng của tôi, tôi đã tìm thấy điều này:

Jan 10 03:38:11 Bucksnort sshd[3571]: pam_unix(sshd:auth): authentication failure; 
    logname= uid=0 euid=0 tty=ssh ruser= rhost=61.19.255.53  user=bin
Jan 10 03:38:13 Bucksnort sshd[3571]: Failed password for bin from 61.19.255.53 
    port 50647 ssh2

Thoạt nhìn, đây giống như sshthư rác đăng nhập thông thường từ các tin tặc ngẫu nhiên; Tuy nhiên, khi tôi nhìn gần hơn, tôi nhận thấy một cái gì đó khác. Hầu hết /var/log/auth.logcác mục thất bại nói invalid usertrong chúng, như thế này:

Jan  9 10:45:23 Bucksnort sshd[3006]: Failed password for invalid user sales 
    from 123.212.43.5 port 10552 ssh2

Điều đáng lo ngại về thông điệp đăng nhập thất bại binđó là nó là một người dùng hợp lệ trong /etc/passwdđó thậm chí còn có một vỏ đăng nhập:

[mpenning@Bucksnort ~]$ grep ^bin /etc/passwd
bin:x:2:2:bin:/bin:/bin/sh

Tôi nghĩ tôi đã bao phủ tất cả các tên người dùng mặc định mà có thể đăng nhập từ xa khi tôi bị vô hiệu hóa PermitRootLogintrong /etc/ssh/sshd_config; khám phá ra mục này đã mở ra những khả năng mới trong tâm trí hoang tưởng của tôi. Nếu bằng cách nào đó dịch vụ chạy bên dưới bin, thì có thể từ xa có thể ai đó có thể chèn khóa ssh vào binthư mục của người dùng từ dịch vụ đang chạy trên hộp, vì vậy tôi muốn tắt hoàn toàn đăng nhập cho binngười dùng, nếu có thể.

Câu hỏi

• Máy chủ này là điều khiển từ xa và rất tốn kém để sửa chữa (tức là tôi sẽ trả tiền cho các tay từ xa để kết nối một KVM, cộng với tiền thuê KVM). Tôi đang cố gắng tìm ra những gì tôi có thể phá vỡ nếu tôi thay đổi /etc/passwdmục nhập binđể trông như thế này:

  bin:x:2:2:bin:/bin:/bin/false

• Tôi đã chạy các lệnh sau để cố gắng tìm ra những gì bincần thiết cho ... Tuy nhiên, các lệnh này xuất hiện không có tệp và tôi không thể tìm thấy quy trình nào thuộc sở hữu bin. Người bindùng làm gì?

  $ sudo find / -group bin

  $ sudo find / -user bin

• Có người dùng nào khác nên đặt shell đăng nhập của họ /bin/falsekhông? FYI, tôi đã có /bin/falsetrên www-data.

• Có phải tôi đang quá hoang tưởng?

Tôi đang chạy Debian, nếu điều đó quan trọng.

Người dùng có vỏ hợp lệ và không có mật khẩu vẫn có thể đăng nhập bằng các phương thức không dựa trên mật khẩu, phổ biến nhất là khóa ssh. Một shell hợp lệ là cần thiết để chạy các công việc cron. Một shell hợp lệ cũng là cần thiết su bin -c 'wibble'để hoạt động (ít nhất là trên Linux, su bin -s /bin/sh -c 'wibble'cũng sẽ hoạt động).

Trong trường hợp bin, hầu hết các hệ thống không bao giờ chạy lệnh như bintrong hoạt động bình thường, do đó, cài đặt shell /bin/falsesẽ ổn.

Không có rủi ro về bất kỳ cuộc tấn công trực tiếp nào cho phép binđăng nhập qua SSH, bởi vì điều đó sẽ yêu cầu tạo /bin/.ssh/authorized_keysnhư người dùng binhoặc root. Nói cách khác, cách duy nhất để vào là. Tuy nhiên, có một vỏ hợp lệ sẽ làm tăng nguy cơ cấu hình sai. Nó cũng có thể cho phép một số cuộc tấn công từ xa với các dịch vụ khác ngoài SSH; ví dụ người dùng báo cáo rằng kẻ tấn công có thể đặt mật khẩu daemontừ xa thông qua Samba, sau đó sử dụng mật khẩu đó để đăng nhập qua SSH.

Bạn có thể cắm lỗ SSH bằng cách liệt kê tên của những người sử dụng hệ thống trong một DenyUserschỉ thị trong /etc/ssh/sshd_config(không may, bạn không thể sử dụng một loạt số). Hoặc ngược lại, bạn có thể đặt một lệnh AllowGroupsvà chỉ cho phép các nhóm có chứa người dùng thực (ví dụ: usersnếu bạn cấp cho tất cả người dùng vật lý của mình thành thành viên nhóm đó).

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à trong danh sách mong muốn của bạn. 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/falsevỏ của họ trừ khi có vẻ cần phải làm khác.

Bạn không phải lo lắng về những người là người dùng. Họ là "người dùng" theo nghĩa của các nhóm bảo mật, không phải người dùng theo nghĩa "đăng nhập và sử dụng" mọi người. Nếu bạn nhìn vào "/ etc / bóng", bạn sẽ thấy rằng tất cả những "người dùng" này không có mật khẩu ("x" hoặc "!" Thay vì băm dài muối). Điều này có nghĩa là những người dùng này không thể đăng nhập, bất kể điều gì.

Điều đó nói rằng, tôi không biết có nên thay đổi "/ bin / sh" thành "/ bin / false" cho tất cả những người dùng này hay không. Bởi vì các chương trình chạy theo các nhóm này, nó có thể không cho phép chúng thực thi các lệnh mà chúng cần. Tôi sẽ để chúng là "/ bin / sh".

Bạn không cần phải lo lắng về những người dùng này. Chỉ lo lắng về người dùng bạn tạo (và những người có băm trong "/ etc / bóng")

Tôi tin rằng đây không phải là vấn đề, vì để thiết lập khóa công khai SSH trong binthư mục chính của ( /bin), kẻ tấn công sẽ phải có quyền truy cập root vào hệ thống tệp, điều đó có nghĩa là dù sao bạn cũng bị lừa.

Nếu bạn thích, bạn có thể vô hiệu hóa tất cả các phương thức xác thực cho binngười dùng trong cấu hình của sshd bằng cách sử dụng MatchUserkhối.

Điều đó nói rằng, có vẻ như người dùng bin không được sử dụng trên các hệ thống có nguồn gốc Debian hiện đại và hoàn toàn là một cái gật đầu với truyền thống hoặc có tuân thủ một số tiêu chuẩn.