seguridad vía chsh

3

Estoy desarrollando un programa con el que quiero que las personas puedan conectarse y usar a través de ssh. Decidí que una forma sencilla de hacerlo sería crear una cuenta para ellos en mi servidor Linux y cambiar el shell que usan para iniciar sesión, para que sea mi programa en lugar de bash.

Una medida que puedo tomar es eliminar su variable PATH para que, de alguna manera, tengan acceso a bash, no puedan ejecutar ningún comando.

¿Es esto terriblemente inseguro? ¿Estoy replicando alguna otra cosa existente? ¿Quizás debería simplemente implementar una conexión SSL en lugar de SSH?

    
pregunta Nacht 19.05.2014 - 08:33
fuente

2 respuestas

2

La eliminación de la variable PATH no haría ninguna diferencia: si los usuarios pueden ejecutar un comando de shell, aún podrían establecer la variable o ejecutar comandos dando su ruta completa. Si de alguna manera obtienen acceso a una shell, has perdido.

Cambiar su shell a otro significa que están confinados a ese programa, y todo lo que logran lanzar desde ese programa.

Hay otra forma de restringir a los usuarios que solo pueden iniciar sesión con SSH: puede darles una clave (y no poner una contraseña en la cuenta, de modo que la única manera de iniciar sesión es con la clave), y poner una restricción command=… en authorized_keys (consulte la página de manual sshd . Esto permite configurar diferentes comandos en diferentes claves para la misma cuenta, lo que puede o no ser útil. Tenga en cuenta que si confía en las restricciones en ~/.ssh/authorized_keys , debe hacer que el directorio principal del usuario, el directorio .ssh y su contenido sea propiedad de root para que el usuario no pueda modificarlos.

Si el programa al que desea dar acceso usa interacciones de terminal o es un filtro de flujo, entonces el acceso SSH dedicado es una buena manera de proporcionar ese servicio. Si el programa solo produce resultados de una pequeña cantidad de entrada, o si el programa utiliza un tipo de interacción de relleno en un formulario, entonces el HTTPS sería más adecuado. No invente su propio protocolo sobre SSL para esto: el uso del shell remoto (a través de SSH) o HTTP (a través de HTTPS) es el mejor para la interfaz de su programa. HTTPS será más fácil de usar para la mayoría de los usuarios.

Si desea dar a los usuarios un acceso limitado a la shell que solo les permita ejecutar un conjunto limitado de comandos, puede hacer que su shell rbash , a shell restringido . Tenga en cuenta que los shells restringidos son difíciles de configurar correctamente: debe asegurarse de que ninguno de los programas disponibles tenga un escape de shell (GNU sed , versiones no restringidas de vi , ...).

Para limitar más a los usuarios, jail lo más posible. Esto puede variar desde un simple chroot (que limita los archivos a los que los usuarios pueden acceder si logran engañar a su programa) hasta darles una cuenta solo dentro de una máquina virtual completa.

    
respondido por el Gilles 19.05.2014 - 09:34
fuente
1

(Supongo que estás usando OpenSSH aquí, ya que es el valor predeterminado para los sistemas Linux).

La eliminación de la variable PATH no proporcionará ninguna seguridad. Si un atacante obtiene acceso a Bash, aún puede usar los comandos integrados del shell, uno de los cuales les permite establecer PATH (y otras variables de entorno) a lo que quieran; Además, aún pueden ejecutar programas especificando la ruta completa.

Cambiar el shell de inicio de sesión proporciona cierta seguridad: el usuario está restringido a hacer cosas que el shell de inicio de sesión le permita. Sin embargo, hay algunos errores aquí en un sistema Linux: PAM a menudo se configura para evitar el inicio de sesión si el shell de inicio de sesión del usuario no aparece en /etc/shells .

Si está utilizando OpenSSH, la opción de configuración ForceCommand en sshd_config puede usarse para forzar al usuario a ejecutar su programa cuando inicie sesión.

    
respondido por el Mark 19.05.2014 - 09:31
fuente

Lea otras preguntas en las etiquetas