Cómo configurar las cárceles chroot de Linux

El término cárcel chroot se utilizó por primera vez en 1992, en un artículo de un destacado investigador de seguridad, Bill Cheswick, (que es interesante si te gusta ese tipo de cosas, puedes encontrar el artículo aquí). Las cárceles de chroot comenzaron a aparecer en 2003, con aplicaciones como IRC y FTP. En 2005, Sun presentó 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 central utilizada con contenedores.

Conceptos básicos de chroot

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

El comando se ve así:

chroot <newroot> [[command][arguments]]

Similar al sudo comando, el chroot El comando cambia el entorno del siguiente comando. En otras palabras, lo cambiará a newroot directorio, y también hace que ese directorio sea el directorio "de trabajo". El command luego se ejecuta en esa ubicación, lo cual es útil para cosas como rescatar un sistema que no arranca.

A diferencia de sudo , estará "en" el directorio. Esta práctica, nuevamente, es útil si está arrancando desde un medio externo pero necesita acceder a un sistema de archivos o comando "local" para trabajar.

El otro uso común de chroot es restringir un servicio o usuario usando un envoltorio para ocultar el resto del sistema de archivos, restringiendo así la vista de un usuario remoto de los datos de otros usuarios. Una implementación popular que usa este enfoque SFTP.

Ejemplo

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

[root@showme1 ~]# cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Por ahora, solo restringirá a los usuarios de SFTP a sus directorios de inicio en el servidor. Este requisito significa que deberá agregar usuarios y ponerlos en un grupo:

[root@showme1 ~]# useradd -g sftpusers -s /sbin/nologin -p nick nick

Tenga en cuenta que al hacer esto se le 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. Hablaré de proporcionar un shell a usuarios remotos en el próximo artículo.

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

Subsystem sftp internal-sftp

Match Group sftpusers
ForceCommand internal-sftp
ChrootDirectory /home
X11Forwarding no
AllowTcpForwarding no

Es importante que agregues esta configuración como un conjunto separado de entradas y que uses el Match sintaxis para indicar que esta sección solo se aplica a los usuarios de este grupo. Si realizó los cambios en las entradas existentes, se aplicarían a todas. Usuarios de SSH, lo que podría interrumpir el acceso remoto.

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

• El ForceCommand hace ssh elija su instalación integrada para proporcionar el servicio SFTP (que puede controlar de forma independiente).
• ChrootDirectory le dice a sshd a dónde restringir al usuario.
• Subsystem sftp internal-sftp le dice a sshd para cargar el sftp interno servicio y ponerlo 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 revisado la ortografía, continúe y guarde los cambios. Luego, reinicie sshd :

[root@showme1 ~]# systemctl restart sshd

Probar el nuevo usuario:

[skipworthy@milo ~]$ sftp nick@showme
nick@showme's password:
Connected to nick@showme.
sftp> ls
accounting   ansible   fred   jason   kenny   lisa    
nick
sftp> pwd
Remote working directory: /
sftp> exit

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

sftp> cd fred
sftp> ls
remote readdir("/fred"): Permission denied

Puede dirigir al usuario chroot a su propio directorio de inicio cambiando el ChrootDirectory línea en el sshd_config archivo como este:

ChrootDirectory /

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

sftp> pwd
Remote working directory: /home/nick
sftp>
sftp> exit
[skipworthy@milo ~]$ touch test.txt
[skipworthy@milo ~]$ sftp nick@showme
nick@showme's password:
Connected to nick@showme.
sftp> put test.txt
Uploading test.txt to /home/nick/test.txt
test.txt 100% 0 0.0KB/s 00:00
sftp> ls
test.txt
sftp>

¿A donde se fué? Mira esto:

[root@showme1 ~]# ls /home/nick
test.txt

Tenga en cuenta que una chroot jail es no considerada como una restricción de seguridad adecuada por sí misma. Si bien evita que un usuario cambie fuera de un directorio restringido, hay formas de evitar esto (la idea general se menciona en chroot(2) man, que debería consultar si está considerando utilizar este truco en un contexto crítico para la producción o el negocio).

Resumiendo (por ahora)

Entonces, 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 la provisión de un entorno de shell a un usuario remoto sin exponer el resto del servidor.

¿Nuevo en contenedores? Descarga Containers Primer y aprende los conceptos básicos de los contenedores de Linux.