¿Tiene / usr / sbin / nologin como shell de inicio de sesión un propósito de seguridad?

En mi /etc/passwdarchivo, puedo ver que el www-datausuario utilizado por Apache, así como todo tipo de usuarios del sistema, tiene /usr/sbin/nologino /bin/falsecomo su shell de inicio de sesión. Por ejemplo, aquí hay una selección de líneas:

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

En consecuencia, si trato de cambiar a alguno de estos usuarios (lo que a veces me gustaría hacer para verificar mi comprensión de sus permisos, y para lo cual probablemente haya otras razones razonables al menos a medias), fallo:

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

Por supuesto, no es un gran inconveniente, porque todavía puedo lanzar un shell para ellos a través de un método como este:

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

Pero eso me hace preguntar qué propósito se sirve al negar estos usuarios un shell de entrada. Buscando una explicación en Internet, muchas personas afirman que esto tiene algo que ver con la seguridad, y todo el mundo parece estar de acuerdo en que sería de alguna manera una mala idea cambiar los shells de inicio de sesión de estos usuarios. Aquí hay una colección de citas:

Establecer el shell del usuario de Apache en algo no interactivo es generalmente una buena práctica de seguridad (realmente todos los usuarios de servicios que no tienen que iniciar sesión de forma interactiva deben tener su shell configurado en algo que no sea interactivo).

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

el shell para el usuario www-data está configurado en / usr / sbin / nologin, y está configurado por una muy buena razón.

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

[las cuentas del sistema] pueden ser agujeros de seguridad , especialmente si tienen un shell habilitado:

• Malo

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

• Bueno

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

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

Por razones de seguridad, creé una cuenta de usuario sin shell de inicio de sesión para ejecutar el servidor Tomcat:

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

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

Si bien estas publicaciones están en acuerdo unánime de que no darles a los usuarios del sistema verdaderos shells de inicio de sesión es bueno para la seguridad, ninguno de ellos justifica esta afirmación, y no puedo encontrar una explicación en ningún lado.

¿De qué ataque estamos tratando de protegernos al no darles a estos usuarios shells de inicio de sesión reales?

Si echa un vistazo a la nologinpágina del manual, verá la siguiente descripción.

extracto

nologin muestra un mensaje que indica que una cuenta no está disponible y que no es cero. Está pensado como un campo de shell de reemplazo para denegar el acceso de inicio de sesión a una cuenta.

Si el archivo /etc/nologin.txtexiste, nologinmuestra su contenido al usuario en lugar del mensaje predeterminado.

El código de salida devuelto por nologinsiempre es 1.

Por lo tanto, la intención real de nologines solo que cuando un usuario intente iniciar sesión con una cuenta que la utiliza en el /etc/passwdes para que se le presente un mensaje fácil de usar y que cualquier script / comando que intente hacer uso de este inicio de sesión recibe el código de salida de 1.

Seguridad

Con respecto a la seguridad, normalmente verá una /sbin/nologino algunas veces /bin/false, entre otras cosas en ese campo. Ambos tienen el mismo propósito, pero /sbin/nologines probablemente el método preferido. En cualquier caso, están limitando el acceso directo a un shell como esta cuenta de usuario en particular.

¿Por qué se considera esto valioso con respecto a la seguridad?

El "por qué" es difícil de describir por completo, pero el valor de limitar la cuenta de un usuario de esta manera es que impide el acceso directo a través de la loginaplicación cuando intenta obtener acceso utilizando dicha cuenta de usuario.

El uso de nologino /bin/falselogra esto. Limitar la superficie de ataque de su sistema es una técnica común en el mundo de la seguridad, ya sea deshabilitar servicios en puertos específicos o limitar la naturaleza de los inicios de sesión en los sistemas de uno.

Todavía hay otras racionalizaciones para usar nologin. Por ejemplo, scpya no funcionará con una cuenta de usuario que no designe un shell real, como se describe en este Preguntas y respuestas de ServerFault titulado: ¿Cuál es la diferencia entre / sbin / nologin y / bin / false? .

Definitivamente sirve un propósito de seguridad. Por ejemplo, mire el siguiente error presentado para un usuario del sistema que tenía un shell.

Mi servidor Debian se vio comprometido debido a que la cuenta de daemon tenía un shell de inicio de sesión válido y tenía Samba abierta para acceso a Internet. La intrusión se realizó estableciendo una contraseña de forma remota a través de samba para la cuenta de daemon y el inicio de sesión a través de ssh. Luego se utilizó algún exploit de raíz local para PROPIAR mi servidor.

Le recomendaría que lea esta maravillosa respuesta de Gilles, donde también ha proporcionado enlaces a algunos de los errores.

Hay errores archivados sobre este problema en Debian (274229, 330882, 581899), actualmente abiertos y clasificados como "lista de deseos". Tiendo a aceptar que se trata de errores y los usuarios del sistema deben tener / bin / false como su shell a menos que parezca necesario hacerlo de otra manera.

Para agregar a las excelentes respuestas de @slm y @ramesh:

Sí, como ha señalado, aún puede cambiar a usuarios con nologin como su shell predeterminado al ejecutar sudocon un shell definido, pero en este caso, ha tenido que:

1. Inicie sesión como otro usuario que tenga un shell válido
2. Tener permisos sudo configurados para que ese usuario ejecute el sucomando, y
3. Tenía su intento de su registrado en el registro de sudoers (suponiendo, por supuesto, que el registro de sudo esté habilitado).

Los usuarios que tienen nologin definido como su shell predeterminado a menudo tienen mayores privilegios / pueden hacer más daño al sistema que un usuario normal, por lo que al no poder iniciar sesión directamente intenta limitar el daño que podría sufrir una violación de su sistema .

Además de las excelentes respuestas que se han dado, tiene otro propósito.

Si ejecuta un demonio FTP en su servidor, verifica el shell de inicio de sesión de los usuarios que intentan iniciar sesión. Si el shell no aparece en la lista /etc/shells, no les permite iniciar sesión. Entonces, dar a las cuentas de daemon un shell especial evita que alguien modifique la cuenta a través de FTP.

Junto a las excelentes respuestas ya dadas, puedo pensar en el siguiente escenario.

Un error de seguridad en un servicio que se ejecuta como un usuario restringido permite escribir un archivo como ese usuario. Este archivo puede ser ~ / .ssh / certified_keys.

Esto permite que el atacante inicie sesión directamente en un shell, lo que facilitaría mucho la ejecución de una escalada de privilegios.

No permitir un inicio de sesión hará que esta opción sea mucho más difícil.

En general, diría que / bin / false y / sbin / nologin son lo mismo, pero supongo que depende del servidor SSH que esté utilizando.

Sería prudente para mí señalar que este reciente exploit en OpenSSH parece afectar / bin / false logins pero NO / sbin / nologin. Sin embargo, establece que Dropbear es diferente de esta manera (también el exploit se aplica específicamente a OpenSSH).

El exploit afecta a la mayoría de las versiones:

7.2p1 y versiones anteriores (todas las versiones; datan de ~ 20 años) Con reenvío X11 habilitado

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

Basándome en esto, personalmente haría / sbin / nologin, sin embargo, no estoy seguro de si esto podría afectar los servicios que crean la entrada / bin / false en / etc / passwd. Puede experimentar y ver sus resultados, ¡pero hágalo bajo su propio riesgo! Supongo que en el peor de los casos, puede volver a cambiarlo y reiniciar los servicios afectados. Personalmente, tengo bastantes entradas usando / bin / false: no estoy seguro si quiero molestarme con esto ya que el reenvío X11 no es algo que haya habilitado;)

Si usa OpenSSH (creo que mucha gente ...) Y tiene habilitado el reenvío X11, puede considerar / sbin / nologin (o tal vez cambiar a Dropbear).

En general, es una buena práctica de seguridad establecer cuentas de servicio y aplicación para el inicio de sesión no interactivo. Un usuario autorizado aún puede tener acceso a esas cuentas usando SU o SUDO, pero todas sus acciones se rastrean en los archivos de registro de Sudoers y se pueden rastrear hasta el usuario que ejecutó los comandos con privilegios de cuenta de servicio. Es por eso que es importante almacenar los archivos de registro en un sistema de administración de registros centralizado para que los administradores del sistema no tengan acceso para cambiar los archivos de registro. El usuario que ejecuta comandos bajo SU o SUDO ya está autorizado para acceder al sistema.

Por otro lado, un usuario externo o no autorizado del sistema no tendrá acceso completo para iniciar sesión con esas cuentas y eso es una medida de seguridad.

Sí, tiene un propósito de seguridad. Es una medida de defensa en profundidad.

La razón principal por la que sirve un propósito es que hay varios bits de software que validarán alguna forma de credenciales de inicio de sesión para un usuario específico y luego usarán el shell de inicio de sesión de ese usuario para ejecutar un comando. Quizás el ejemplo más notable es SSH. Si se autentica correctamente como usuario a través de SSH, SSH inicia el shell de inicio de sesión del usuario (o lo usa para ejecutar el comando que proporciona, si usa la ssh someuser@example.com 'command to run'sintaxis).

Por supuesto, idealmente un atacante no podrá autenticarse como usuario en absoluto. Pero supongamos que ocurre la siguiente situación:

• Un servidor que controlas ejecuta un servicio web como usuario que tiene un directorio de inicio y un shell de inicio de sesión
• Un atacante descubre una vulnerabilidad en ese servicio que le permite escribir archivos en el directorio de inicio del usuario

Ahora su atacante puede escribir una clave pública SSH ~/.ssh/authorized_keys, luego ingresar SSH y ¡boom! - Tienen acceso de shell a su servidor.

Si, en cambio, el usuario tiene /usr/sbin/nologincomo shell de inicio de sesión, incluso después de que el atacante escriba con éxito la clave pública authorized_keys, no le será útil. Todo lo que les permite hacer es ejecutarlo de forma remota nologin, lo que no es muy útil. No pueden obtener proyectiles, y su ataque ha sido mitigado.

En caso de que este escenario parezca muy hipotético, me gustaría señalar que fui atacado precisamente por este ataque en algún momento de 2015, alrededor de un año después de hacer esta pregunta. Como un maldito idiota, había dejado una instancia de Redis sin contraseña abierta al mundo. Fue atacado por el ataque crackit Redis , en el que el atacante inserta una clave pública SSH en su base de datos Redis, luego envía un comando diciéndole a Redis que escriba el contenido de la base de datos .ssh/authorized_keys, luego intenta ingresar SSH. Me salvé de las consecuencias de mi propia incompetencia solo por el hecho de que los mantenedores del redis-serverpaquete Apt (que había usado para instalar Redis) tenían la sabiduría para hacerlo ejecutar Redis como unredisusuario que no tiene directorio de inicio o shell de inicio de sesión; Si no hubiera sido por ellos, mi servidor probablemente habría sido rescatado o terminado como parte de la botnet de algún hacker.

Esa experiencia me dio un cierto grado de humildad y me hizo apreciar la importancia de la defensa en profundidad y, en particular, de no otorgar shells de inicio de sesión a cuentas que ejecutan servidores web, bases de datos y otros servicios en segundo plano.