¿Por qué el usuario 'bin' necesita un shell de inicio de sesión?

Durante una auditoría de /var/log/auth.loguno de mis servidores web públicos, encontré esto:

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 primera vista, esto parece un sshspam de inicio de sesión típico de hackers aleatorios; Sin embargo, cuando miré más de cerca, noté algo más. La mayoría de las /var/log/auth.logentradas fallidas dicen invalid useren ellas, como esta:

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

Lo inquietante de ese mensaje de inicio de sesión fallido de bines que es un usuario válido en el /etc/passwdque tiene una cáscara incluso entrada:

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

Pensé que había cubierto los todos los nombres de usuario predeterminados que podrían conectarse de forma remota cuando he deshabilitado PermitRootLoginen /etc/ssh/sshd_config; Descubrir esta entrada abrió nuevas posibilidades en mi mente paranoica. Si los servicios se ejecutaron de alguna manera bin, entonces es remotamente posible que alguien pueda insertar una clave ssh en el bindirectorio del usuario desde un servicio en ejecución en la caja, por lo que me gustaría deshabilitar completamente el inicio de sesión para el binusuario, si es posible.

Preguntas

Este servidor es remoto y costoso de arreglar (es decir, pagaré por las manos remotas para conectar un KVM, más el alquiler de KVM). Estoy tratando de descubrir qué podría romper si cambio la /etc/passwdentrada para binque se vea así:

bin:x:2:2:bin:/bin:/bin/false
Ejecuté los siguientes comandos tratando de averiguar qué binse necesita para ... Sin embargo, estos comandos no tienen archivos y no pude encontrar ningún proceso de propiedad bin. ¿Qué hace el binusuario de todos modos?

$ sudo find / -group bin

$ sudo find / -user bin
¿Hay otros usuarios que deberían configurar sus shells de inicio de sesión /bin/false? Para su información, ya he tiene /bin/falseen www-data.
¿Estoy siendo demasiado paranoico?

Estoy ejecutando Debian, si eso importa.

linux debian security

— Mike Pennington
fuente

Una pregunta relacionada es unix.stackexchange.com/questions/485505 .

— JdeBP

Respuestas:

Un usuario que tiene un shell válido y no tiene contraseña aún puede iniciar sesión por métodos no basados en contraseña, siendo el más común una clave ssh. Es necesario un shell válido para ejecutar trabajos cron. También es necesario un shell válido para su bin -c 'wibble'funcionar (al menos en Linux, su bin -s /bin/sh -c 'wibble'también funcionará).

En el caso de bin, la mayoría de los sistemas nunca ejecutan un comando como binen la operación normal, por lo que establecer el shell en /bin/falseestaría bien.

No hay riesgo de que un ataque directo permita bininiciar sesión a través de SSH, ya que eso requeriría crearse /bin/.ssh/authorized_keyscomo usuario bino como root. En otras palabras, la única forma de entrar es estar dentro. Sin embargo, tener un shell válido aumenta el riesgo de una configuración incorrecta. También puede permitir algunos ataques remotos con servicios que no sean SSH; por ejemplo, un usuario informa que un atacante podría establecer una contraseña de daemonforma remota a través de Samba, y luego usar esa contraseña para iniciar sesión a través de SSH.

Puede conectar el agujero SSH enumerando los nombres de los usuarios del sistema en una DenyUsersdirectiva /etc/ssh/sshd_config(desafortunadamente, no puede usar un rango numérico). O, por el contrario, puede poner una AllowGroupsdirectiva y solo permitir los grupos que contienen usuarios físicos (por ejemplo, userssi otorga a todos sus usuarios físicos esa membresía de grupo).

Hay errores archivados sobre este problema en Debian ( # 274229 , # 330882 , # 581899 ), actualmente abiertos y clasificados como "lista de deseos". Tiendo a estar de acuerdo en que se trata de errores y que los usuarios del sistema deberían tener /bin/falsecomo caparazón a menos que parezca necesario hacerlo de otra manera.

— Gilles 'SO- deja de ser malvado'
fuente

No tiene que preocuparse por aquellos como usuarios. Son "usuarios" en el sentido de grupos de seguridad, no usuarios en el sentido de "iniciar sesión y usar" personas. Si busca en "/ etc / shadow", verá que todos estos "usuarios" no tienen contraseñas (ya sea "x" o "!" En lugar de un hash salado largo). Esto significa que estos usuarios no pueden iniciar sesión, pase lo que pase.

Dicho esto, no sé si es una buena idea cambiar "/ bin / sh" a "/ bin / false" para todos estos usuarios. Como los programas se ejecutan en estos grupos, es posible que no les permita ejecutar los comandos que necesitan. Los dejaría como "/ bin / sh".

No es necesario que se preocupe por estos usuarios. Solo preocúpate por los usuarios que creas (y los que tienen hashes en "/ etc / shadow")

— Chris
fuente

Punto justo acerca de que no hay hash /etc/shadow, pero si un servicio se ejecuta como usuario, teóricamente es posible que alguien inserte una sshclave de inicio de sesión, ¿no?

— Mike Pennington

Solo si ya iniciaron sesión en su cuenta con privilegios de root ... en cuyo caso, estos usuarios son la menor de sus preocupaciones :-P

— Chris

No estoy seguro de estar de acuerdo con todas las restricciones que acaba de enumerar. Si eso fuera cierto, entonces los rpcdpuertos abiertos no serían un problema; sin embargo, personalmente presencié los resultados de un exploit remoto en una vieja máquina Solaris donde el atacante obtuvo acceso a través de un rpcexploit en la caja. rhostsfue habilitado y escribible por ese rpcusuario (no puedo recordar más detalles ... fue hace años) ... Del mismo modo, si pueden hacer un ~/.ssh/authorized_keyspara un usuario que pueda iniciar sesión, entonces esto todavía parece un riesgo (incluso sin un contraseña en /etc/shadow)

— Mike Pennington

Sí, pero esa hazaña no fue a través de SSH. Los programas generalmente se ejecutan bajo su propio usuario (como usted ha dicho). Un exploit en un programa (por ejemplo, un exploit de desbordamiento de búfer) puede hacer que el usuario malintencionado acceda al shell al que tiene acceso ese programa. Sin embargo, ese programa necesita ese acceso para hacer lo que sea que esté destinado a hacer (de lo contrario, no puede acceder a las cosas que necesita). Por eso es importante asegurarse de que los permisos estén configurados correctamente. Un exploit en el demonio rpc es un problema bastante grande, que puede resolverse actualizando el software (o restringiéndolo).

— Chris

Lo siento, se quedó sin espacio. Cambiar el shell al que puede acceder un programa soluciona ese problema, pero genera más problemas con lo que el programa realmente debe hacer. Pensé que originalmente querías decir que un usuario malintencionado podría ingresar a través de ese usuario, lo que no puede (a menos que establezcan una clave, creo, como dijiste). Puede resolver ese pequeño problema, en sshd_config, colocando "AllowUsers <username> <username> ..." para permitir solo el acceso SSH de usuarios específicos.

— Chris

Creo que esto no es un problema, ya que para configurar una clave pública SSH en el bindirectorio de inicio ( /bin), el atacante tendría que tener acceso de root al sistema de archivos, lo que significa que de todos modos está jodido.

Si lo desea, puede deshabilitar todos los métodos de autenticación para el binusuario en la configuración de sshd usando el MatchUserbloque.

Dicho esto, parece que el usuario bin no se utiliza en los sistemas modernos derivados de Debian y es simplemente un guiño a la tradición o está allí para cumplir con algunos estándares.

— usuario21217
fuente