EL Rincón de Tux

Creative Commons Reconocimiento-NoComercial-CompartirIgual 2.1

© 1999-2007 Joel Barrios Dueñas. Usted es libre de copiar, distribuir y comunicar públicamente la obra y hacer obras derivadas bajo las condiciones siguientes: a) Debe reconocer y citar al autor original. b) No puede utilizar esta obra para fines comerciales (incluyendo su publicación, a través de cualquier medio, por entidades con fines de lucro). c) Si altera o transforma esta obra, o genera una obra derivada, sólo puede distribuir la obra generada bajo una licencia idéntica a ésta. Al reutilizar o distribuir la obra, tiene que dejar bien claro los términos de la licencia de esta obra. Alguna de estas condiciones puede no aplicarse si se obtiene el permiso del titular de los derechos de autor. Los derechos derivados de usos legítimos u otras limitaciones no se ven afectados por lo anterior. Licencia completa en castellano. La información contenida en este documento y los derivados de éste se proporcionan tal cual son y los autores no asumirán responsabilidad alguna si el usuario o lector hace mal uso de éstos.

Introducción.

SSH es un protocolo que permite realizar transferencias seguras a través de un túnel seguro donde toda la información trasmitida va cifrada. Sin embargo, SSH potencialmente se puede volver un arma de dos filo si una cuenta de usuario se ve comprometida. Configurar un sistema con OpenSSH con soporte para chroot brinda una mayor seguridad al aislar a los usuarios dentro de un entorno separado del sistema principal con un mínimo de herramientas para trabajar y que disminuye los riesgos potenciales en caso de verse comprometida alguna cuenta.

Chroot es una operación que cambia el directorio raíz, afectando solamente al proceso actual y a los procesos derivados de éste (hijos). Específicamente se refiere a la llamada de sistema chroot(2) o al programa ejecutable chroot(8).

Este documento considera que el lector utiliza CentOS 4, Red Hat™ Enterprise Linux 4 o White Box Enterprise Linux 4.

Equipamiento lógico necesario.

Se requiere instalar los paquetes de OpenSSH modificados con el parche disponible a través de http://chrootssh.sourceforge.net/ y que están disponibles a a través de Alcance Libre en el siguiente URL:

Utilice el mandato wget, del siguiente modo, para descargar los paquetes correspondientes:

wget -m -np -nH --cut-dirs=1 \

http://www.alcancelibre.org/al/openssh-chroot/

El directorio completo será descargado junto los paquetes RPM necesarios, junto con algo de contenido HTML que pueden eliminarse.

rm -f openssh-chroot/index.html*

Al terminar, acceda al subdirectorio openssh-chroot que se acaba de crear:

cd openssh-chroot/

Por motivos de seguridad, los paquetes distribuidos por Alcance Libre están firmados digitalmente con GnuPG. La clave pública está disponible en http://www.alcancelibre.org/al/AL-RPM-KEY. Conviene descargar e importar ésta a fin de verificar la integridad de los paquetes RPM involucrados en este documento.

wget http://www.alcancelibre.org/al/AL-RPM-KEY
rpm --import AL-RPM-KEY

Una vez importada la llave pública, se verifica la integridad de los paquetes RPM utilizando el mandato rpm, con las opciones -v y -K, que corresponden, respectivamente, a mensajes descriptivos y verificación de firmas.

rpm -Kv *.rpm

Lo anterior debe devolver algo similar a lo siguiente:

openssh-3.9p1-9.9.el4.al.chroot.i386.rpm:
    CabeceraFirma V3 DSA: OK, key ID 7c080b33
    resumen SHA1 de la cabecera:OK (15c28f0f6dc0dce549fe5441ef4e67054c8dbe07)
    Resumen MD5: OK (41044560482050a87274061848f39910)
    Firma V3 DSA: OK, key ID 7c080b33
openssh-askpass-3.9p1-9.9.el4.al.chroot.i386.rpm:
    CabeceraFirma V3 DSA: OK, key ID 7c080b33
    resumen SHA1 de la cabecera:OK (a3e8ab96f78d49d05cfbf43ad80ad5a5056f717e)
    Resumen MD5: OK (b5f6987c780e9f5802e716de24855f44)
    Firma V3 DSA: OK, key ID 7c080b33
openssh-askpass-gnome-3.9p1-9.9.el4.al.chroot.i386.rpm:
    CabeceraFirma V3 DSA: OK, key ID 7c080b33
    resumen SHA1 de la cabecera:OK (bd5f0e5743a05a33137cbea9cb7abc5a3bed875a)
    Resumen MD5: OK (24a8a19f83e993bbd18e048dde0b77eb)
    Firma V3 DSA: OK, key ID 7c080b33
openssh-clients-3.9p1-9.9.el4.al.chroot.i386.rpm:
    CabeceraFirma V3 DSA: OK, key ID 7c080b33
    resumen SHA1 de la cabecera:OK (679c214e1f0d147523b41b38060ca76d0fd547d7)
    Resumen MD5: OK (92f870b2f74d4410c99f44e96f00681b)
    Firma V3 DSA: OK, key ID 7c080b33
openssh-server-3.9p1-9.9.el4.al.chroot.i386.rpm:
    CabeceraFirma V3 DSA: OK, key ID 7c080b33
    resumen SHA1 de la cabecera:OK (eebb0d88596cd80c6caf7ad0d758a53c5ef653cf)
    Resumen MD5: OK (0f80de58e6d6e2d610593506142981ad)
    Firma V3 DSA: OK, key ID 7c080b33

A fin de satisfacer cualquier otra dependencia que pudiera faltar, utilice el mandato yum para instalar los paquetes RPM en el interior:

yum localinstall *.rpm

Si no se dispone del mandato yum en el sistema, o bien si así se prefiere, se puede utilizar directamente el mandato rpm del siguiente modo:

rpm -Uvh openssh-*

Procedimientos

Solo el usuario root deberá poder modificar la estructura de la jaula y su contenido. El objeto es poder permitir el acceso por SSH/SFTP a un entorno aislado del sistema principal. Adicionalmente si se configura el servicio de FTP con jaulas, se podrá acceder indistintamente por FTP, SSH o SFTP.

Componentes mínimos para la jaula.

Los siguientes son los componentes mínimos de la jaula basada sobre un sistema con CentOS 4, Red Hat™ Enterprise Linux 4 o White Box Enterprise Linux 4:

/bin/sh
/bin/cp
/bin/false
/bin/ls
/bin/mv
/bin/pwd
/bin/rm
/bin/rmdir
/bin/sh
/bin/true
/etc/group
/etc/passwd
/lib/ld-linux.so.2
/lib/libacl.so.1
/lib/libattr.so.1
/lib/libc.so.6
/lib/libcom_err.so.2
/lib/libcrypt.so.1
/lib/libcrypto.so.4
/lib/libdl.so.2
/lib/libnsl.so.1
/lib/libpthread.so.0
/lib/libresolv.so.2
/lib/librt.so.1
/lib/libselinux.so.1
/lib/libtermcap.so.2
/lib/libutil.so.1
/usr/lib/libz.so.1
/usr/lib/libgssapi_krb5.so.2
/usr/lib/libk5crypto.so.3
/usr/lib/libkrb5.so.3
/usr/libexec/openssh/sftp-server
/sbin/nologin

Si se requiere utilizar /bin/sh, y suponiendo se utiliza /chroot/ como directorio raíz para la jaula, se debe copiar dentro de éste como /chroot/bin/sh, si se requiere /lib/libtermcap.so.2 se debe copiar como /chroot/lib/libtermcap.so.2, si se requiere /usr/libexec/openssh/sftp-server se debe copiar como /chroot/usr/libexec/openssh/sftp-server, y así sucesivamente.

Cualquier otra herramienta que se quiera agregar, solo requerirá estén presentes, dentro de las rutas relativas de la jaula, las bibliotecas correspondientes. Éstas se determinan a través del mandato ldd aplicado sobre la herramienta que se quiere utilizar. Por ejemplo, si se quiere añadir el binario del mandato more a la jaula, primero se determina que bibliotecas requiere para funcionar:

ldd /bin/more

Lo anterior devuelve algo como lo siguiente:

        libtermcap.so.2 => /lib/libtermcap.so.2 (0x00bea000)
        libc.so.6 => /lib/tls/i586/libc.so.6 (0x00515000)
        /lib/ld-linux.so.2 (0x004fe000)

Lo anterior significa que para poder utilizar el binario del mandato more dentro de la jaula deberán estar presentes dentro de ésta y en el subdirectorio lib/ las bibliotecas libtermcap.so.2, libc.so.6 y ld-linux.so.2.

Ficheros /etc/passwd y /etc/group.

Los ficheros /etc/group y /etc/passwd solo necesitan contener la información de los usuarios que interese enjaular así como la ruta relativa al directorio donde se encuentra la jaula de sus directorios de inicio (es decir, se define /home/usuario, suponiendo que realmente se localiza en /var/www/sitiocliente/home/usuario). Es indispensable esté presente esta información dentro de la jaula o de otro modo no será posible realizar el ingreso al sistema.

usuario:x:503:503::/home/usuario:/bin/bash

usuario:x:503:

Dispositivos de bloque.

Aunque no del todo indispensable para utilizar OpenSSH con Chroot, es buena idea crear los siguiente nodos dentro de la jaula:

mkdir dev
mknod -m 0666 dev/tty c 5 0
mknod -m 0644 dev/urandom c 1 9
mknod -m 0666 dev/null c 1 3
mknod -m 0666 dev/zero c 1 12

Ejemplo práctico.

Suponiendo que se tiene un cliente, y éste ha solicitado servicio de hospedaje para su sitio de red a través de HTTP. El cliente quiere dos usuarios diferentes para subir distinto contenido al sitio de red. Los usuarios serán fulano y mengano. El dominio a administrar sera sitio.com, que será administrado exclusivamente por fulano, y se quiere un sub-dominio denominado ventas.sitio.com que será administrado por mengano.

Crear las cuentas de los usuarios

Se crea el directorio /var/www/sitio.com y se copia la estructura de la jaula antes mencionada dentro de subdirectorios relativos a /var/www/sitio.com, teniendo cuidado de dejar a root como propietario a fin de impedir que los usuarios puedan borrar algún subdirectorio del interior.

Se crean las cuentas de los dos usuarios, tomando en cuenta que si se asigna /sbin/nologin o /bin/false como interprete de mandatos, se podrá acceder por FTP pero no se podrá acceder por SSH o SFTP, y si se asigna /usr/libexec/openssh/sftp-server, solo se podrá acceder por SFTP. Si se asigna /bin/sh como interprete de mandatos, se podrá acceder por SSH, SFTP y FTP.

useradd -s /bin/sh -d /var/www/sitio.com/./ fulano
mkdir /var/www/sitio.com
chown root.apache /var/www/sitio.com
passwd fulano

useradd -s /bin/sh -m -d /var/www/sitio.com/./ventas mengano
mkdir /var/www/sitio.com/ventas
chown root.apache /var/www/sitio.com/ventas
passwd mengano

Cabe señalar que los directorios de inicio pertenecen a root, de este modo se impide que el usuario pueda borrar subdirectorio relativos que se utilizarán para guardar las bitácoras de Apache.

Suponiendo que el ususario fulano tiene UID 513 y que el usuario mengano tiene UID 514, el fichero /var/www/sitio.com/etc/passwd debería tener el siguiente contenido:

fulano:x:513:513::/var/www/sitio.com/./home/fulano:/bin/sh
mengano:x:514:514::/var/www/sitio.com/./home/mengano:/bin/sh

Basado sobre lo anterior, e fichero /var/www/sitio.com/etc/group debería tener el siguiente contenido:

apache:x:48:
fulano:x:513:
mengano:x:514:

Ejemplo aplicado a sitio de red virtual con Apache.

El dominio www.sitio.com se configurará del siguiente modo:

	<VirtualHost *:80>
		ServerName www.sitio.com
		ServerAlias sitio.com
		DocumentRoot /var/www/sitio.com/html
		ErrorLog /var/www/sitio.com/logs/error_log
		CustomLog /var/www/sitio.com/logs/access_log combined
		<Directory "/var/www/sitio.com/html/">
			Options Indexes Indexes Includes
			AllowOverride all
		</Directory>
	</VirtualHost>

Los directorios necesarios se crearán del siguiente modo con siguientes permisos:

mkdir /var/www/sitio.com
chown root.apache /var/www/sitio.com
mkdir -p /var/www/sitio.com/html
chown fulano.apache /var/www/sitio.com/html
mkdir -p /var/www/sitio.com/configs
chown fulano.apache /var/www/sitio.com/configs

El subdominio ventas.sitio.com se configurará del siguiente modo:

	<VirtualHost *:80>
		ServerName ventas.sitio.com
		DocumentRoot /var/www/sitio.com/ventas/html
		ErrorLog /var/www/sitio.com/ventas/logs/error_log
		CustomLog /var/www/sitio.com/ventas/logs/access_log combined
		<Directory "/var/www/sitio.com/ventas/html/">
			Options Indexes Indexes Includes
			AllowOverride all
		</Directory>
	</VirtualHost>

Los directorios necesarios se crearán del siguiente modo, asignando estos con el mandato chown al usuario root, fulano y el grupo apache:

mkdir /var/www/sitio.com/ventas
chown root.apache /var/www/sitio.com/ventas
mkdir -p /var/www/sitio.com/ventas/html
chown fulano.apache /var/www/sitio.com/ventas/html
mkdir -p /var/www/sitio.com/ventas/configs
chown fulano.apache /var/www/sitio.com/ventas/configs

Comprobaciones del ejemplo.

Al acceder con el usuario fulano a través de SSH o FTP hacia www.sitio.com se deberá acceder hacia /var/www/sitio.com, el cual será presentado como “/”. El usuario publicará el contenido HTML dentro del subdirectorio /html, , podrá guardar contenido fuera del directorio raíz público, del sitio virtual en Apache, en el subdirectorio /configs y podrá acceder hacia las bitácoras generadas por apache en /logs, para ser utilizadas por cualquier herramienta de análisis, como Webalizer. Es importante mencionar que el usuario fulano no podrá borrar contenido, ni deberá tener capacidad tal, del directorio /, como son el subdirectorio de bitácoras /logs y el subdirectorio /html. Éste último se mostrará a través de Apache como http://ventas.sitio.com/. En la ausencia de estos, tras una eliminación accidental de los mismos, Apache no podría iniciar, lo cual afectaría a todos los sitios hospedados en el servidor.

Al acceder con el usuario mengano a través de SSH o FTP hacia www.sitio.com se deberá acceder hacia /var/www/sitio.com, el cual será presentado como “/”. El usuario publicará el contenido HTML dentro del subdirectorio /ventas/html, podrá guardar contenido fuera del directorio raíz público, del sitio virtual en Apache, en el subdirectorio /ventas/configs y podrá acceder hacia las bitácoras generadas por Apache, en el subdirectorio /ventas/logs, para ser utilizadas por cualquier herramienta de análisis, como Webalizer. Es importante mencionar que el usuario mengano no podrá borrar contenido, ni deberá tener capacidad tal, del directorio /ventas, como serían el subdirectorio de bitácoras (/ventas/logs) y el subdirectorio de contenido HTML (/ventas/html). Éste último se mostrará a través de Apache como http://ventas.sitio.com/. En la ausencia de estos, tras una eliminación accidental de los mismos, Apache no podría iniciar, lo cual afectaría a todos los sitios hospedados en el servidor.

Última Edición lunes, abril 09 2007 @ 02:37 CDT