Mengapa pengguna 'tempat sampah' memerlukan shell login?

Selama audit /var/log/auth.logpada salah satu webserver publik saya, saya menemukan ini:

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

Pada blush on pertama, ini tampak seperti sshspam login tipikal dari peretas acak; Namun, ketika saya melihat lebih dekat, saya memperhatikan sesuatu yang lain. Sebagian besar /var/log/auth.logentri yang gagal mengatakan invalid userdi dalamnya, seperti ini:

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

Hal menggelisahkan tentang pesan login gagal untuk binadalah bahwa itu adalah pengguna yang valid dalam /etc/passwdyang bahkan memiliki shell login:

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

Saya pikir saya telah menutupi semua username default yang bisa login dari jarak jauh ketika saya dinonaktifkan PermitRootLogindi /etc/ssh/sshd_config; menemukan entri ini membuka kemungkinan baru dalam pikiran paranoid saya. Jika entah bagaimana layanan berjalan di bawah bin, maka sangat mungkin seseorang dapat memasukkan kunci ssh ke bindirektori pengguna dari layanan yang sedang berjalan di kotak, jadi saya ingin sepenuhnya menonaktifkan login untuk binpengguna, jika memungkinkan.

Pertanyaan

Server ini jauh, dan mahal untuk diperbaiki (yaitu saya akan membayar tangan jarak jauh untuk menghubungkan KVM, ditambah sewa KVM). Saya mencoba mencari tahu apa yang mungkin saya hancurkan jika saya mengubah /etc/passwdentri binagar terlihat seperti ini:

bin:x:2:2:bin:/bin:/bin/false
Saya menjalankan perintah berikut mencoba mencari tahu apa binyang diperlukan untuk ... Namun, perintah ini muncul tanpa file dan saya tidak dapat menemukan proses yang dimiliki oleh bin. Apa yang dilakukan binpengguna?

$ sudo find / -group bin

$ sudo find / -user bin
Apakah ada pengguna lain yang harus mengatur shell login mereka /bin/false? FYI, saya sudah punya /bin/falsedi www-data.
Apakah saya terlalu paranoid?

Saya menjalankan Debian, jika itu penting.

linux debian security

— Mike Pennington
sumber

Pertanyaan terkait adalah unix.stackexchange.com/questions/485505 .

— JdeBP

Jawaban:

Seorang pengguna yang memiliki shell yang valid dan tanpa kata sandi masih dapat login dengan metode non-password, yang paling umum adalah kunci ssh. Shell yang valid diperlukan untuk menjalankan pekerjaan cron. Shell yang valid juga diperlukan untuk su bin -c 'wibble'bekerja (setidaknya di Linux, su bin -s /bin/sh -c 'wibble'juga akan berfungsi).

Dalam kasus bin, sebagian besar sistem tidak pernah menjalankan perintah seperti bindalam operasi normal, jadi pengaturan shell /bin/falsemenjadi ok.

Tidak ada risiko serangan langsung yang memungkinkan binuntuk masuk melalui SSH, karena itu akan membutuhkan pembuatan /bin/.ssh/authorized_keyssebagai pengguna binatau sebagai root. Dengan kata lain, satu-satunya cara untuk masuk adalah dengan masuk. Namun, memiliki shell yang valid akan meningkatkan risiko kesalahan konfigurasi. Itu juga dapat mengizinkan beberapa serangan jarak jauh dengan layanan selain SSH; misalnya seorang pengguna melaporkan bahwa seorang penyerang dapat menetapkan kata sandi untuk daemonjarak jauh melalui Samba, kemudian menggunakan kata sandi itu untuk masuk melalui SSH.

Anda bisa pasang lubang SSH dengan mendaftar nama-nama pengguna sistem dalam DenyUsersarahan di /etc/ssh/sshd_config(sayangnya, Anda tidak dapat menggunakan rentang numerik). Atau, sebaliknya, Anda dapat memberikan AllowGroupsarahan dan hanya mengizinkan grup yang berisi pengguna fisik (mis. usersJika Anda memberikan semua pengguna fisik Anda yang menjadi anggota grup).

Ada bug yang diajukan atas masalah ini di Debian ( # 274229 , # 330882 , # 581899 ), saat ini terbuka dan diklasifikasikan sebagai "daftar harapan". Saya cenderung setuju bahwa ini adalah bug dan pengguna sistem harus memiliki /bin/falseshell mereka kecuali jika tampaknya perlu dilakukan sebaliknya.

— Gilles 'SANGAT berhenti menjadi jahat'
sumber

Anda tidak perlu khawatir tentang mereka sebagai pengguna. Mereka adalah "pengguna" dalam arti kelompok keamanan, bukan pengguna dalam arti "masuk dan menggunakan" orang. Jika Anda melihat "/ etc / shadow", Anda akan melihat bahwa semua "pengguna" ini tidak memiliki kata sandi (baik "x" atau "!" Bukannya hash asin yang panjang). Ini berarti bahwa pengguna ini tidak dapat masuk, apa pun yang terjadi.

Yang mengatakan, saya tidak tahu apakah itu ide yang baik untuk mengubah "/ bin / sh" menjadi "/ bin / false" untuk semua pengguna ini. Karena program berjalan di bawah grup-grup ini, itu mungkin tidak memungkinkan mereka untuk mengeksekusi perintah yang mereka butuhkan. Saya akan meninggalkan mereka sebagai "/ bin / sh".

Anda tidak perlu khawatir tentang pengguna ini. Hanya khawatir tentang pengguna yang Anda buat (dan orang-orang dengan hash di "/ etc / shadow")

— Chris
sumber

Poin wajar tentang tidak ada hash /etc/shadow, tetapi jika layanan berjalan sebagai pengguna, secara teoritis mungkin bagi seseorang untuk memasukkan sshkunci login, bukan?

— Mike Pennington

Hanya jika mereka sudah masuk ke akun Anda dengan hak akses root ... dalam hal ini, para pengguna ini adalah yang paling tidak Anda khawatirkan :-P

— Chris

Saya tidak yakin saya setuju dengan semua kendala yang baru saja Anda sebutkan. Jika itu benar, maka rpcdport terbuka tidak akan menjadi masalah; namun, saya secara pribadi menyaksikan hasil eksploitasi jarak jauh pada mesin Solaris lama tempat penyerang memperoleh akses melalui rpceksploit pada kotak. rhostsdiaktifkan dan dapat ditulis oleh rpcpengguna tersebut (tidak dapat mengingat lebih spesifik ... itu bertahun-tahun yang lalu) ... Demikian juga jika mereka dapat membuat ~/.ssh/authorized_keysbagi pengguna yang dapat masuk, maka ini masih tampak seperti risiko (bahkan tanpa kata sandi masuk /etc/shadow)

— Mike Pennington

Ya, tapi eksploitasi itu tidak melalui SSH. Program biasanya berjalan di bawah pengguna mereka sendiri (seperti yang Anda katakan). Eksploitasi dalam suatu program (misalnya, exploit buffer overflow) dapat membuat pengguna jahat mengakses shell yang memiliki akses ke program itu. Namun, program itu membutuhkan akses untuk melakukan apa pun yang seharusnya dilakukan oleh program itu (jika tidak, ia tidak dapat mengakses hal-hal yang diperlukan). Ini sebabnya penting untuk memastikan bahwa izin diatur dengan benar. Eksploitasi dalam daemon rpc adalah masalah yang cukup besar, yang dapat diselesaikan dengan memperbarui perangkat lunak (atau dengan membatasi).

— Chris

Maaf, kehabisan kamar. Mengganti shell yang dapat diakses oleh suatu program TIDAK memperbaiki masalah itu, tetapi membuat lebih banyak masalah dengan apa yang seharusnya dilakukan oleh program. Saya pikir Anda awalnya berarti bahwa pengguna jahat dapat SSH masuk melalui pengguna itu, yang mereka tidak bisa (kecuali mereka menetapkan kunci, saya percaya, seperti yang Anda katakan). Anda dapat memecahkan masalah kecil itu dengan, di sshd_config, masukkan "AllowUsers <username> <username> ..." untuk hanya membolehkan pengguna SSH tertentu mengakses.

— Chris

Saya percaya ini bukan masalah, karena untuk mengatur kunci publik SSH bindi direktori home ( /bin), penyerang harus memiliki akses root ke sistem file, yang berarti Anda tetap kacau.

Jika suka, Anda dapat menonaktifkan semua metode otentikasi untuk binpengguna dalam konfigurasi sshd menggunakan MatchUserblok.

Yang mengatakan, sepertinya pengguna bin tidak digunakan pada sistem modern yang diturunkan dari Debian dan murni anggukan pada tradisi atau ada untuk kepatuhan dengan beberapa standar.

— pengguna21217
sumber