Daniel Vigueras

Cuando un atacante explota un fallo en un servidor y logra acceso, lo primero que suele hacer es cubrir sus huellas mediante la instalación de un rootkit. Esto puede implicar modificar binarios o librerías del sistema con versiones creadas especialmente para el caso; por ejemplo se podría sustituir el binario /bin/ls del sistema con una versión que no mostrase los ficheros que empiecen por una cadena en especial, así el atacante podría dejar ficheros en el sistema cuyo nombre comenzasen por esa cadena y nadie más podría ver que existen usando el comando ls.

Aunque existen mecanismos más complejos y eficientes para ocultar ficheros en el sistema (como por ejemplo modificando la syscall table del kernel con una versión alternativa de una llamada al sistema), este método es bastante común. El problema radica en que el administrador no se ha dado cuenta de que un binario ha sido reemplazado por una versión alternativa troyanizada, si tuviera algún método de realizar una comprobación automática podría detectar a tiempo este tipo de intrusiones.

Para conseguir detectar estas modificaciones de forma automática existe una estupenda herramienta denominada Tripwire, que genera una base de datos con un hash digital de los ficheros del sistema. Lo ideal es generar esta base de datos con el sistema recien instalado, antes de conectarlo a la red, así estaremos seguros de que está totalmente limpio. Una vez generada la base de datos podremos realizar chequeos periódicos de forma automática añadiendolo en el crontab, pudiendo configurar el software para que envíe un email al administrador en caso de detectar modificaciones en algún fichero.

Una de las principales amenazas a las que se ven sometidos los servidores web en internet son los fallos existentes en las aplicaciones que ejecutan. Estos fallos, aprovechados convenientemente, pueden conllevar que un usuario malicioso consiga acceso al servidor con los mismos privilegios que el usuario que ejecuta el servicio web. En el caso de Linux este usuario se suele llamar nobody o apache.

El primer paso que un atacante realiza cuando consigue explotar el fallo a través de la aplicación web es el de descargar en el servidor alguna aplicación que le permita acceder remotamente de forma cómoda, como por ejemplo mediante una shell. En el caso de los gusanos creados especialmente para este propósito el comportamiento es muy similar, explotan el fallo, descargan el mismo gusano en el sistema y lo ejecutan para seguir infectado otros servidores.

El usuario sube al servidor esta aplicación maliciosa en un directorio en el cual tenga permisos de ejecución el usuario que ejecuta el servicio web, pero como estos directorios pueden variar entre distintas distribuciones se recurre a utilizar en la mayoría de casos el directorio en el cual todos los usuarios pueden escribir, es decir, /tmp .

Para intentar minimizar las oportunidades de éxito de este tipo de ataques surge la idea de marcar de alguna manera el directorio /tmp como directorio donde no se puedan ejecutar aplicaciones, sin embargo esto no es posible aplicarlo directamente a directorios, sino que se debe realizar sobre particiones completas.

Para lograr conseguir este objetivo sin la necesidad de modificar la tabla de particiones de nuestro disco duro vamos a recurrir a dispositivos loop. Básicamente lo que haremos será crear un fichero del tamaño que deseemos que tenga el directorio /tmp, y posteriormente montaremos este sistema de ficheros en el mismo directorio, marcándolo como no ejecutable para conseguir así nuestro objetivo.

A continuación se puede ver un código de ejemplo que crea un directorio /tmp no ejecutable con un tamaño de 1GB:

cd /var
dd if=/dev/zero of=tmploop bs=1024 count=$((1024*1024))
/sbin/mke2fs tmploop
cp -R /tmp /tmpbak
mount -o loop,noexec,nosuid,rw /var/tmp0 /tmp
chmod 0777 /tmp
cp -R /tmpbak/* /tmp/

Esto nos dejaría /tmp preparado, ahora habría que borrar /tmpbak cuando hayamos comprobado que todo ha ido correctamente. Sin embargo cuando el servidor sea reiniciado estos cambios se van a perder. Para que esto no ocurra habría que añadir la siguiente línea al fichero /etc/fstab :

/var/tmploop       /tmp    ext2    loop,noexec,nosuid,rw  0 0