Perché l'utente 'bin' ha bisogno di una shell di accesso?

Durante un controllo /var/log/auth.logsu uno dei miei server web pubblici, ho trovato questo:

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

A prima vista, questo sembra un tipico sshspam di accesso da hacker casuali; tuttavia, mentre guardavo più da vicino, notai qualcos'altro. La maggior parte delle /var/log/auth.logvoci non riuscite dice invalid userin esse, come questa:

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

La cosa inquietante di quel messaggio di accesso non riuscito per binè che si tratta di un utente valido in /etc/passwdche ha una shell di login anche:

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

Pensavo di aver coperto i tutti i nomi utente di default che potrebbero sessione in modo remoto quando ho disabilitato PermitRootLoginin /etc/ssh/sshd_config; scoprire questa voce ha aperto nuove possibilità nella mia mente paranoica. Se in qualche modo i servizi funzionavano sotto bin, allora è possibile che qualcuno possa inserire in qualche modo una chiave ssh nella bindirectory dell'utente da un servizio in esecuzione sulla scatola, quindi bin, se possibile , vorrei disabilitare completamente l'accesso per l' utente.

Domande

Questo server è remoto e costoso da riparare (cioè pagherò le mani remote per collegare un KVM, più il noleggio KVM). Sto cercando di capire cosa potrei rompere se cambio la /etc/passwdvoce per binassomigliare a questo:

bin:x:2:2:bin:/bin:/bin/false
Ho eseguito i seguenti comandi cercando di capire cosa binè necessario per ... Tuttavia, questi comandi non hanno prodotto file e non sono riuscito a trovare processi di proprietà bin. Cosa fa bincomunque l' utente?

$ sudo find / -group bin

$ sudo find / -user bin
Ci sono altri utenti che dovrebbero impostare le loro shell di accesso /bin/false? Cordiali saluti, ho già avere /bin/falsesu www-data.
Sono troppo paranoico?

Sto eseguendo Debian, se questo è importante.

linux debian security

— Mike Pennington
fonte

Una domanda correlata è unix.stackexchange.com/questions/485505 .

— JdeBP,

Risposte:

Un utente che ha una shell valida e nessuna password può comunque accedere con metodi non basati su password, la più comune è una chiave ssh. È necessaria una shell valida per eseguire cron job. È necessaria anche una shell valida per su bin -c 'wibble'funzionare (almeno su Linux su bin -s /bin/sh -c 'wibble'funzionerà).

Nel caso di bin, la maggior parte dei sistemi non esegue mai un comando come binnel normale funzionamento, quindi impostare la shell su /bin/falsesarebbe ok.

Non vi è alcun rischio di alcun attacco diretto che consenta bindi accedere tramite SSH, poiché ciò richiederebbe la creazione /bin/.ssh/authorized_keyscome utente bino come root. In altre parole, l'unico modo per entrare è quello di entrare. Tuttavia, avere una shell valida aumenta il rischio di errata configurazione. Può anche consentire alcuni attacchi remoti con servizi diversi da SSH; ad esempio un utente segnala che un utente malintenzionato potrebbe impostare una password per daemonremoto tramite Samba, quindi utilizzare quella password per accedere tramite SSH.

È possibile collegare il foro SSH elencando i nomi degli utenti del sistema in una DenyUsersdirettiva /etc/ssh/sshd_config(sfortunatamente, non è possibile utilizzare un intervallo numerico). Oppure, al contrario, puoi mettere una AllowGroupsdirettiva e consentire solo i gruppi che contengono utenti fisici (ad esempio usersse concedi a tutti i tuoi utenti fisici quell'appartenenza al gruppo).

Ci sono bug archiviati su questo problema in Debian ( # 274229 , # 330882 , # 581899 ), attualmente aperti e classificati come "lista dei desideri". Tendo a concordare sul fatto che si tratta di bug e che gli utenti di sistema dovrebbero avere /bin/falsecome shell a meno che non sembri necessario fare diversamente.

— Gilles 'SO- smetti di essere malvagio'
fonte

Non devi preoccuparti di quelli come utenti. Sono "utenti" nel senso di gruppi di sicurezza, non utenti nel senso di "login e uso" di persone. Se guardi in "/ etc / shadow", vedrai che tutti questi "utenti" non hanno password (né "x" o "!" Invece di un hash lungo salato). Ciò significa che questi utenti non possono accedere, qualunque cosa accada.

Detto questo, non so se sia una buona idea cambiare "/ bin / sh" in "/ bin / false" per tutti questi utenti. Poiché i programmi vengono eseguiti in questi gruppi, potrebbe non consentire loro di eseguire i comandi necessari. Li lascerei come "/ bin / sh".

Non è necessario che ti preoccupi di questi utenti. Preoccupati solo degli utenti che crei (e di quelli con hash in "/ etc / shadow")

— Chris
fonte

Punto giusto su nessun hash in /etc/shadow, ma se un servizio viene eseguito come utente, è teoricamente possibile per qualcuno inserire una sshchiave di accesso, no?

— Mike Pennington,

Solo se sono già stati registrati nel tuo account con i privilegi di root ... nel qual caso, questi utenti sono il minimo dei tuoi dubbi :-P

— Chris

Non sono sicuro di essere d'accordo con tutti i vincoli che hai appena elencato. Se ciò fosse vero, le rpcdporte aperte non sarebbero un problema; tuttavia, ho assistito personalmente ai risultati di un exploit remoto su una vecchia macchina Solaris in cui l'attaccante ha ottenuto l'accesso attraverso un rpcexploit sulla scatola. rhostsè stato abilitato e scrivibile da rpcquell'utente (non ricordo altri dettagli ... è stato anni fa) ... Allo stesso modo se riescono a creare un ~/.ssh/authorized_keysutente che potrebbe accedere, allora questo sembra comunque un rischio (anche senza un password in /etc/shadow)

— Mike Pennington,

Sì, ma quell'exploit non era attraverso SSH. I programmi in genere vengono eseguiti con il proprio utente (come hai detto). Un exploit in un programma (ad esempio un exploit buffer overflow) può far sì che l'utente malintenzionato acceda alla shell a cui quel programma ha accesso. Tuttavia, quel programma ha bisogno di quell'accesso per fare qualunque cosa quel programma debba fare (altrimenti non può accedere alle cose che deve fare). Ecco perché è importante assicurarsi che le autorizzazioni siano impostate correttamente. Un exploit nel demone rpc è un grosso problema, che può essere risolto aggiornando il software (o limitandolo).

— Chris,

Spiacente, a corto di spazio. Modificare la shell a cui un programma può accedere risolve il problema, ma crea ulteriori problemi con ciò che il programma dovrebbe effettivamente fare. Pensavo che inizialmente intendevi dire che un utente malintenzionato potrebbe accedere a SSH tramite quell'utente, cosa che non può (a meno che non imposti una chiave, credo, come hai detto). Puoi risolvere quel piccolo problema inserendo, in sshd_config, "AllowUsers <username> <username> ..." per consentire l'accesso a SSH solo a utenti specifici.

— Chris,

Credo che questo non sia un problema, poiché per impostare una chiave pubblica SSH nella binhome directory ( /bin), l' autore dell'attacco dovrebbe avere accesso come root al file system, il che significa che comunque sei fregato.

Se lo desideri, puoi disabilitare tutti i metodi di autenticazione per l' binutente nella configurazione di sshd usando il MatchUserblocco.

Detto questo, sembra che l'utente bin non sia utilizzato sui moderni sistemi derivati da Debian ed è puramente un cenno alla tradizione o è lì per la conformità con alcuni standard.

— user21217
fonte