En mi /etc/passwd
archivo, puedo ver que el www-data
usuario utilizado por Apache, así como todo tipo de usuarios del sistema, tiene /usr/sbin/nologin
o /bin/false
como 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?
Respuestas:
Si echa un vistazo a la
nologin
página del manual, verá la siguiente descripción.extracto
Por lo tanto, la intención real de
nologin
es solo que cuando un usuario intente iniciar sesión con una cuenta que la utiliza en el/etc/passwd
es 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/nologin
o algunas veces/bin/false
, entre otras cosas en ese campo. Ambos tienen el mismo propósito, pero/sbin/nologin
es 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
login
aplicación cuando intenta obtener acceso utilizando dicha cuenta de usuario.El uso de
nologin
o/bin/false
logra 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,scp
ya 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? .fuente
They both serve the same purpose, but /sbin/nologin is probably the preferred method.
Desde el punto de vista de la seguridad, `/ sbin / nologin`` no es el método preferido; desperdicia tiempo y ciclos proporcionando una respuesta. Aunque ninguno proporciona una seguridad particularmente buena; son medidas de defensa en profundidad, pero en realidad no impiden que alguien ejecute un comando como un usuario determinado.nologin
es el método preferido por razones de UX, no por razones de seguridad: hacersudo su someuser
y no tener nada porque su shell de inicio de sesiónfalse
es confuso. Además, ambos do evitar que alguien la ejecución de un comando como un usuario dado en algunas circunstancias, descritas en las respuestas aquí.Definitivamente sirve un propósito de seguridad. Por ejemplo, mire el siguiente error presentado para un usuario del sistema que tenía un shell.
Le recomendaría que lea esta maravillosa respuesta de Gilles, donde también ha proporcionado enlaces a algunos de los errores.
fuente
ssh user@site
, y eso funcionara, no continuarían intentándolossh user@site /bin/bash
, pero estoy bastante seguro de que todavía funcionaría independientemente del shell declarado.ssh user@site /bin/bash
devuelve unThis account is currently not available.
mensaje simple . Además, esta respuesta dice que nologin protege el acceso SSHPara 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
sudo
con un shell definido, pero en este caso, ha tenido que:su
comando, yLos 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 .
fuente
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.fuente
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.
fuente
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).
fuente
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.
fuente
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 [email protected] 'command to run'
sintaxis).Por supuesto, idealmente un atacante no podrá autenticarse como usuario en absoluto. Pero supongamos que ocurre la siguiente situación:
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/nologin
como shell de inicio de sesión, incluso después de que el atacante escriba con éxito la clave públicaauthorized_keys
, no le será útil. Todo lo que les permite hacer es ejecutarlo de forma remotanologin
, 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 delredis-server
paquete Apt (que había usado para instalar Redis) tenían la sabiduría para hacerlo ejecutar Redis como unredis
usuario 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.
fuente