Cómo configurar cárceles de chroot de Linux

El término cárcel de chroot se usó por primera vez en 1992, en un artículo de un destacado investigador de seguridad, Bill Cheswick, (lo cual es interesante si te gustan ese tipo de cosas, puedes encontrar el artículo aquí). Las cárceles Chroot comenzaron a aparecer en 2003, con aplicaciones como IRC y FTP. En 2005, Sun introdujo su tecnología de” Contenedores ” llamada Zonas, que a su vez fue un precursor del concepto de espacios de nombres, que es una tecnología básica utilizada con contenedores.

Conceptos básicos de Chroot

Chroot permite a un administrador controlar el acceso a un servicio o sistema de archivos mientras controla la exposición al entorno de servidor subyacente. Los dos ejemplos comunes que puede encontrar son durante la secuencia de arranque y el “shell de emergencia” en sistemas Red Hat/CentOS/Fedora, y en FTP Seguro (SFTP).

El comando se ve así:

chroot <newroot> ]

Al igual que el comando sudo, el comando chroot cambia el entorno del siguiente comando. En otras palabras, te cambiará al directorio newroot, y también hará que ese directorio sea el directorio “de trabajo”. El command se ejecuta en esa ubicación, lo que es útil para cosas como rescatar un sistema que no arranca.

A diferencia de sudo, estará “en” el directorio. Esta práctica, de nuevo, es útil si está arrancando desde medios externos pero necesita acceder a un sistema de archivos o comando “local” para hacer el trabajo.

El otro uso común de chroot es restringir un servicio o usuario mediante el uso de una envoltura para ocultar el resto del sistema de archivos, por lo tanto, restringiendo la vista de un usuario remoto de los datos de otros usuarios. Una implementación popular que utiliza este enfoque SFTP.

Ejemplo

Antes de comenzar a trabajar en este ejemplo, debe asegurarse de tener copias de seguridad. En este caso, haga una copia de seguridad del archivo /etc/ssh/sshd_config porque realizará cambios en ese archivo específicamente:

# cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Por ahora, solo restringirá a los usuarios de SFTP a sus directorios personales en el servidor. Este requisito significa que tendrás que añadir usuarios y ponerlos en un grupo:

# useradd -g sftpusers -s /sbin/nologin -p nick nick

Tenga en cuenta que hacer esto asignará nick una cuenta sin shell de inicio de sesión. Esta técnica es práctica y una buena práctica de seguridad: Si solo está usando SFTP, no debería tener privilegios de inicio de sesión. En el próximo artículo hablaré sobre cómo proporcionar un shell a los usuarios remotos.

Ahora, debe decirle al servicio ssh qué hacer cuando los usuarios de SFTP inicien sesión. Abra el archivo /etc/ssh/sshd_config y agregue lo siguiente al final:

Subsystem sftp internal-sftpMatch Group sftpusersForceCommand internal-sftpChrootDirectory /homeX11Forwarding noAllowTcpForwarding no

Es importante que agregue estas configuraciones como un conjunto separado de entradas y que use la sintaxis Match para indicar que esta sección solo se aplica a los usuarios de este grupo. Si realizas los cambios en las entradas existentes, se aplicarán a todos los usuarios de SSH, lo que podría interrumpir el acceso remoto.

Las líneas de configuración se desglosan de la siguiente manera:

  • ForceCommand hace que ssh elija su instalación incorporada para proporcionar el servicio SFTP (que puede controlar de forma independiente).
  • ChrootDirectory indica a sshd dónde restringir al usuario.
  • Subsystem sftp internal-sftp le dice a sshd que cargue el servicio interno sftp y lo ponga a disposición.

Es posible que deba asegurarse de que este Subsystem no esté definido ya comentando esta línea anteriormente en el archivo de configuración:

# override default of no subsystems# Subsystem sftp /usr/libexec/openssh/sftp-server

Una vez que haya realizado los cambios y comprobado la ortografía, siga adelante y guarde los cambios. A continuación, reinicie sshd:

# systemctl restart sshd

Probar el nuevo usuario:

$ sftp nick@showmenick@showme's password:Connected to [email protected]> lsaccounting ansible fred jason kenny lisa nicksftp> pwdRemote working directory: /sftp> exit

Vaya, espera un minuto: Parece que también puedes ver todos los directorios de los demás usuarios. Sin embargo, no puede navegar a esos directorios:

sftp> cd fredsftp> lsremote readdir("/fred"): Permission denied

Puede dirigir al usuario chroot a su propio directorio personal cambiando la línea ChrootDirectory en el archivo sshd_config de esta manera:

ChrootDirectory /

Este cambio rápido hace que Nick parezca que está en su propio directorio personal, y no podrá ver los archivos de ningún otro usuario:

sftp> pwdRemote working directory: /home/nicksftp>sftp> exit$ touch test.txt$ sftp nick@showmenick@showme's password:Connected to [email protected]> put test.txtUploading test.txt to /home/nick/test.txttest.txt 100% 0 0.0KB/s 00:00sftp> lstest.txtsftp>

¿A dónde se fue? Mira esto.:

# ls /home/nicktest.txt

Tenga en cuenta que chroot jail no se considera una restricción de seguridad adecuada por sí misma. Si bien evita que un usuario cambie de un directorio restringido, hay formas de evitarlo (la idea general se menciona en la página de manual chroot(2), a la que debe echar un vistazo si está considerando usar este truco en un contexto crítico para la producción o el negocio.)

Terminando (por ahora)

Así que, puedes ver que chroot puede ser una herramienta bastante útil. En la parte 2, analizaré más la asignación de directorios específicos a los usuarios y el suministro de un entorno de shell a un usuario remoto sin exponer el resto del servidor.

¿Nuevo en contenedores? Descargue el Manual de contenedores y aprenda los conceptos básicos de los contenedores de Linux.

Deja una respuesta

Tu dirección de correo electrónico no será publicada.