Daniel Vigueras

Lo ideal es que hoy en día el administrador de un servidor esté suscrito a listas de correo/feeds rss sobre cada uno de los servicios que tiene ejecutando en el servidor (apache, proftpd, mysql, exim, dovecot, etc…) de forma que si aparece un nuevo bug de última hora se tomen las medidas necesarias para evitar su explotación, aún en esos momentos en los cuales no existe un parche oficial.

Esta práctica es muy recomendable, pero no significa que nos cubra completamente, ni mucho menos. Gran cantidad de bugs no se comunican a los creadores del software hasta pasados unos días, semanas e incluso meses posteriores a su descubrimiento, pero lo que sí se crean son los denominados xploits o-day que circulan dentro de los círculos privados de determinados grupos aficionados a la seguridad. Estos xploits permiten en multitud de casos aprovechar una vulnerabilidad remota para ganar acceso a la máquina, en algunos casos directamente como root y en otros casos como usuario normal, pero una vez dentro el conseguir acceso como root se basa en ejecutar otro xploit local, cosa que suele ser de menor dificultad una vez dentro del sistema.

Con el fin de minimizar la probabilidad de que nuestro servidor sea hackeado este artículo quiere presentar (para los que no los conozcan) y recomendar encarecidamente el uso del conjunto de parches denominados Grsecurity. La definición que aportan en su web es la siguiente:

Grsecurity is an innovative approach to security utilizing a multi-layered detection, prevention, and containment model. It is licensed under the GPL.
It offers among many other features:

• An intelligent and robust Role-Based Access Control (RBAC) system that can generate least privilege policies for your entire system with no configuration
• Change root (chroot) hardening
• /tmp race prevention
• Extensive auditing
• Prevention of arbitrary code execution, regardless of the technique used (stack smashing, heap corruption, etc)
• Prevention of arbitrary code execution in the kernel
• Randomization of the stack, library, and heap bases
• Kernel stack base randomization
• Protection against exploitable null-pointer dereference bugs in the kernel
• Reduction of the risk of sensitive information being leaked by arbitrary-read kernel bugs
• A restriction that allows a user to only view his/her processes
• Security alerts and audits that contain the IP address of the person causing the alert

Este conjunto de parches podría en gran cantidad de casos, aún ejecutando en nuestro servidor un proceso que tenga alguna vulnerabilidad conocida, que esta vulnerabilidad pueda ser explotada.  Los mecanismos que añade al kernel para aumentar la seguridad son de un nivel que se escapa del objetivo de este artículo. Por poner un ejemplo, para aquellos que conozcan en que se basan las vulnerabilidades de tipo stack overflow y que alguna vez hayan experimentado con un xploit de este tipo diremos que Grsecurity introduce aleatorización en la dirección EIP de ejecución de los procesos, de forma que un offset precalculado y almacenado en el xploit no serviría para nada en un servidor con estos parches.

La instalación de Grsec requiere parchear el kernel, aunque se pueden encontrar kernels ya parcheados por internet yo recomiendo bajarse los fuentes de la distribución y parchear uno mismo a mano el kernel.

Una característica que me gusta mucho también de Grsec es que si lo activas puedes permitir que los usuarios sólo vean los procesos que están ejecutando ellos mismos, así nunca podrán ver información sensible de los procesos que otros usuarios estén ejecutando en el sistema.

Como conclusión final podemos decir, al igual que en otros artículo que esto aumenta la seguridad de nuestros servidores, pero en ningún caso nos hemos de dormir ya que continuamente aparecen nuevas vulnerabilidades que podrían afectarnos.

Más enlaces de interés para aquellos que quieran profundizar en el tema:

Página oficial de Grsecurity

Packetstorm

SecurityFocus

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

Normalmente en los procesos de autenticación interviene lo que denomicamos un único factor, entendiendo como factor cualquier método de autenticación en el sistema, como podría ser una contraseña, un código PIN, una huella dactilar, una secuencia de ADN… Sin embargo si queremos que este proceso de autenticación en el sistema sea más robusto lo ideal es hacer que intervengan dos factores (tres sería mejor, pero el proceso sería demasiado tedioso) siendo a esto a lo que denominamos autenticación multifactor.

Al comienzo de este artículo se puede ver la imágen de un RSA SecurID, un pequeño aparato con forma de llavero que únicamente posee una pantalla LCD en la cual es muestra un número, lo primero de todo hay que destacar que este aparato no posee ningún método de comunicación con el exterior, ni puerto USB, ni Wi-Fi, ni bluetooth, ni infrarrojos ni nada parecido, funciona aislado del mundo exterior. Cada 30 segundos el número que aparece en pantalla cambia por otro generado aleatoriamente, es decir, incorpora un generador de números pseudoaleatorios en su interior y una semilla que permite que esta secuencia sea diferente en cada SecurID. Esta semilla también está almacenada en el servidor de autenticación y por tanto haciendo una serie de cálculos rápidos puede saber en cada momento que número muestra nuestro aparato por pantalla.

Cuando vamos a autenticarnos en el sistema introducimos nuestro nombre de usuario y un número PIN que sólo nosotros conocemos seguido del número que aparezca en ese mismo instante en la pantalla del SecurID, a continuación si esta primera fase de autenticación se realiza correctamente el sistema procede a solicitarnos nuestra contraseña de usuario para acceder al sistema.

¿ Por qué ganamos seguridad usando este sistema ? Sencillamente porque si usamos un método tradicional de usuario y contraseña un atacante que por fuerza bruta logre adivinar la contraseña tendrá acceso al sistema, sin embargo con este método si el atacante conoce el nombre de usuario y contraseña no concerá ni el PIN necesario ni tendrá el RSA SecurID en su posesión para ver el número que aparece en pantalla. El caso de que el usuario pierda el RSA SecurID tampoco es problema ya que un atacante no conocerá el PIN necesario aunque pueda ver en pantalla el número que aparece en el momento de la autenticación.

Este tipo de medidas se han de tomar debido a que no podemos dejar que toda la seguridad asociada al proceso de autenticación recaiga en el usuario del sistema ya que se convertiría en la mayor brecha potencial.