/ Usr / sbin / nologin come shell di accesso serve a scopi di sicurezza?

Nel mio /etc/passwdfile, posso vedere che l' www-datautente utilizzato da Apache, così come tutti i tipi di utenti del sistema, ha una /usr/sbin/nologino /bin/falsecome shell di login. Ad esempio, ecco una selezione di linee:

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

Di conseguenza, se provo a passare a uno di questi utenti (cosa che a volte mi piacerebbe fare per verificare la mia comprensione delle loro autorizzazioni e che probabilmente ci sono altri motivi almeno a metà sani di mente), fallisco:

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

Certo, non è un gran inconveniente, perché posso ancora lanciare una shell per loro tramite un metodo come questo:

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

Ma questo mi lascia solo a chiedermi quale sia lo scopo negando a questi utenti una shell di accesso. Guardando a Internet per una spiegazione, molte persone affermano che ciò ha qualcosa a che fare con la sicurezza e tutti sembrano concordare sul fatto che sarebbe in qualche modo una cattiva idea cambiare le shell di accesso di questi utenti. Ecco una raccolta di citazioni:

L'impostazione della shell dell'utente Apache su qualcosa di non interattivo è generalmente una buona pratica di sicurezza (in realtà tutti gli utenti di servizi che non devono accedere in modo interattivo dovrebbero avere la shell impostata su qualcosa che non è interattivo).

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

la shell per l'utente www-data è impostata su / usr / sbin / nologin ed è impostata per un'ottima ragione.

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

[account di sistema] possono essere falle di sicurezza , specialmente se hanno una shell abilitata:

• Male

  bin:x:1:1:bin:/bin:/bin/sh

• Buono

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

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

Per motivi di sicurezza ho creato un account utente senza shell di accesso per l'esecuzione del server Tomcat:

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

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

Sebbene questi post siano d'accordo all'unanimità sul fatto che non dare agli utenti di sistema vere shell di login sia un bene per la sicurezza, nessuno di questi giustifica questa affermazione e non riesco a trovare una spiegazione da nessuna parte.

Da quale attacco stiamo cercando di proteggerci non dando a questi utenti vere shell di login?

Se dai un'occhiata alla nologinpagina man vedrai la seguente descrizione.

estratto

nologin mostra un messaggio che un account non è disponibile ed esce da zero. È inteso come campo shell sostitutivo per negare l'accesso di accesso a un account.

Se il file /etc/nologin.txtesiste, nologinvisualizza il suo contenuto all'utente anziché il messaggio predefinito.

Il codice di uscita restituito da nologinè sempre 1.

Quindi l'intento reale di nologinè proprio quello che quando un utente tenta di accedere con un account che lo utilizza nel /etc/passwdmodo in cui viene presentato un messaggio di facile utilizzo e che qualsiasi script / comando che tenta di utilizzare questo login riceve il codice di uscita 1.

Sicurezza

Per quanto riguarda la sicurezza, in genere vedrai uno /sbin/nologino talvolta /bin/false, tra le altre cose in quel campo. Entrambi hanno lo stesso scopo, ma /sbin/nologinè probabilmente il metodo preferito. In ogni caso stanno limitando l'accesso diretto a una shell come questo particolare account utente.

Perché questo è considerato prezioso in termini di sicurezza?

Il "perché" è difficile da descrivere completamente, ma il valore nel limitare l'account di un utente in questo modo è che ostacola l'accesso diretto tramite l' loginapplicazione quando si tenta di ottenere l'accesso utilizzando tale account utente.

Usando uno nologino lo /bin/falserealizza. Limitare la superficie di attacco del sistema è una tecnica comune nel mondo della sicurezza, sia disabilitando i servizi su porte specifiche, sia limitando la natura degli accessi sui propri sistemi.

Ci sono ancora altre razionalizzazioni da utilizzare nologin. Ad esempio, scpnon funzionerà più con un account utente che non designa una shell effettiva, come descritto in questa Domande e risposte di ServerFault intitolata: Qual è la differenza tra / sbin / nologin e / bin / false? .

Sicuramente serve a scopi di sicurezza. Ad esempio, guarda il bug di seguito riportato per un utente di sistema che aveva una shell.

Il mio server debian è stato compromesso a causa dell'account daemon con una shell di login valida e che samba era aperto per l'accesso a Internet. L'interruzione è stata effettuata impostando una password in remoto tramite samba per l'account daemon e l'accesso tramite ssh. Alcuni exploit root locali sono stati quindi utilizzati per PROPRIO il mio server.

Ti consiglierei di leggere questa meravigliosa risposta di Gilles in cui ha fornito collegamenti anche ad alcuni dei bug.

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

Per aggiungere alle risposte eccellenti di @slm e @ramesh:

Sì, come hai sottolineato, puoi comunque passare agli utenti con nologin come shell predefinita eseguendo sudocon una shell definita, ma in questo caso hai dovuto:

1. Accedi come un altro utente che ha una shell valida
2. Hanno le autorizzazioni sudo configurate per quell'utente per eseguire il sucomando e
3. Il tuo tentativo su è stato registrato nel registro sudoers (supponendo ovviamente che la registrazione sudo sia abilitata).

Gli utenti che hanno definito nologin come shell predefinita hanno spesso privilegi più elevati / sono in grado di fare più danni al sistema rispetto a un utente normale, quindi non essere in grado di accedere direttamente tenta di limitare il danno che potrebbe subire una violazione del sistema .

Oltre alle eccellenti risposte che sono state fornite, serve un altro scopo.

Se esegui un demone FTP sul tuo server, controlla la shell di accesso degli utenti che tentano di accedere. Se la shell non è elencata /etc/shells, non consente loro di accedere. Quindi dare agli account daemon una shell speciale impedisce a qualcuno di modificare l'account tramite FTP.

Accanto alle grandi risposte già fornite, posso pensare al seguente scenario.

Un bug di sicurezza in un servizio in esecuzione come utente con restrizioni consente di scrivere un file come tale utente. Questo file può essere ~ / .ssh / authorized_keys.

Ciò consente all'attaccante di accedere direttamente a una shell, il che renderebbe molto più semplice eseguire un'escalation dei privilegi.

Non consentire una shell di login renderebbe questa opzione molto più difficile.

Generalmente direi / bin / false e / sbin / nologin sono uguali, ma suppongo che dipenda dal server SSH che stai usando.

Sarebbe prudente per me sottolineare che questo recente exploit su OpenSSH sembra influenzare / bin / false login ma NOT / sbin / nologin. Tuttavia afferma che Dropbear è diverso in questo modo (anche l'exploit si applica specificamente a OpenSSH).

Lo sfruttamento influisce sulla maggior parte delle versioni:

7.2p1 e versioni precedenti (tutte le versioni; risalenti a ~ 20 anni) con l'inoltro X11 abilitato

https://www.exploit-db.com/exploits/39569/

Quindi, in base a questo, personalmente farei / sbin / nologin, tuttavia non sono sicuro che ciò possa influire sui servizi che creano la voce / bin / false in / etc / passwd. Puoi sperimentare e vedere i tuoi risultati, ma per favore fallo a tuo rischio e pericolo! Suppongo che nel caso peggiore puoi semplicemente ripristinarlo e riavviare qualsiasi servizio interessato. Personalmente ho parecchie voci usando / bin / false - Non sono sicuro se voglio preoccuparmi di questo dato che l'inoltro X11 non è qualcosa che ho abilitato;)

Se usi OpenSSH (penso che molte persone ...) E hai abilitato l'inoltro X11 - potresti prendere in considerazione / sbin / nologin (o magari passare a Dropbear).

In genere è buona prassi di sicurezza impostare account di servizi e applicazioni su accessi non interattivi. Un utente autorizzato può ancora avere accesso a quegli account usando SU o SUDO ma tutte le loro azioni sono tracciate nei file di registro dei Sudatori e possono essere ricondotte all'utente che ha eseguito i comandi con i privilegi dell'account di servizio. Questo è il motivo per cui è importante archiviare i file di registro in un sistema di gestione dei registri centralizzato in modo che gli amministratori di sistema non abbiano accesso ai file di registro delle modifiche. L'utente che esegue i comandi su SU o SUDO è già autorizzato ad accedere al sistema.

D'altra parte, un utente esterno o non autorizzato al sistema non avrà completamente accesso al login utilizzando tali account e questa è una misura di sicurezza.

Sì, serve a scopi di sicurezza. È una misura di difesa approfondita.

Il motivo principale per cui serve uno scopo è che ci sono vari bit di software che convalidano una qualche forma di credenziali di accesso per un utente specificato e quindi usano la shell di accesso dell'utente per eseguire un comando. Forse l'esempio più notevole è SSH. Se si esegue correttamente l'autenticazione come utente su SSH, SSH avvia quindi la shell di accesso dell'utente (o la utilizza per eseguire il comando fornito, se si utilizza la ssh someuser@example.com 'command to run'sintassi).

Naturalmente, idealmente un utente malintenzionato non sarà in grado di autenticarsi come utente. Supponiamo che si verifichi la seguente situazione:

• Un server che controlli esegue un servizio Web come utente con una home directory e una shell di accesso
• Un utente malintenzionato rileva una vulnerabilità in quel servizio che consente all'autore dell'attacco di scrivere file nella home directory dell'utente

Ora il tuo aggressore può scrivere una chiave pubblica SSH in ~/.ssh/authorized_keys, quindi SSH in, e - boom! - hanno accesso shell al tuo server.

Se invece l'utente ha /usr/sbin/nologincome shell di login, anche dopo che l'autore dell'attacco ha scritto correttamente la chiave pubblica authorized_keys, non è utile per loro. Tutto ciò che consente loro di eseguire è eseguire in remoto nologin, il che non è molto utile. Non possono ottenere il guscio e il loro attacco è stato mitigato.

Nel caso in cui questo scenario sembri molto ipotetico, vorrei notare che sono stato preso di mira proprio da questo attacco ad un certo punto nel 2015, circa un anno dopo aver fatto questa domanda. Come un dannato idiota, avevo lasciato un'istanza di Redis senza password aperta al mondo. È stato preso di mira dall'attacco crackis di Redis , in cui l'attaccante inserisce una chiave pubblica SSH nel database Redis, quindi invia un comando che dice a Redis di scrivere il contenuto del database .ssh/authorized_keys, quindi tenta di SSH in. Sono stato salvato dalle conseguenze della mia incompetenza solo dal fatto che i manutentori del redis-serverpacchetto Apt (che avevo usato per installare Redis) avevano la saggezza per far funzionare Redis come unredisutente che non ha home directory o shell di login; se non fosse stato per loro, il mio server sarebbe stato probabilmente riscattato o sarebbe finito parte della botnet di alcuni hacker.

Quell'esperienza mi ha dato un certo grado di umiltà e mi ha fatto apprezzare l'importanza della difesa in profondità , e, in particolare, di non concedere shell di login agli account che eseguono server web, database e altri servizi in background.