Daniel Vigueras

Como ya hemos comentado, es importante tener actualizado nuestro servidor, sobre todo si estas actualizaciones están relacionadas con la seguridad del mismo. En el caso de Debian/Ubuntu directamente podríamos realizar un pequeño script que ejecutara un aptitude update && aptitude upgrade cada 3 horas, por ejemplo. Sin embargo no es algo que recomiende ya que (quizá sea paranoia mía) ¿ y si alguna de estas actualizaciones nos estropea algo del servidor ?

Sería interesante saber cuando hay actualizaciones disponibles para posteriormente entrar a mano y realizarlas bajo nuestra supervisión de forma manual. Para ello he elaborado un script de gran sencillez cuyo cometido es el de actualizar la lista de paquetes disponibles en Debian/Ubuntu y posteriormente realizar una simulación de actualización del sistema, en caso de que se necesite descargar algo nos avisa mediante correo electrónico.

El contenido del script es el siguiente:

#!/bin/bash
LOGFILE=/tmp/log_aptitude
aptitude update  > $LOGFILE
aptitude -sy upgrade >> $LOGFILE
grep -q "Necesito descargar 0B" $LOGFILE
if [ $? -eq 1 ]
then
      cat $LOGFILE | mail -s "Se necesita actualizar el servidor" mi@correo.com
fi

Sustituyendo mi@correo.com por nuestra dirección de correo electrónico donde recibir las notificaciones.
Para añadirlo al crontab de forma que se ejecute cada 3 horas habría que ejecutar como root

crontab -e

y añadir la siguiente línea:

0 */3 * * * /root/scripts/aptupdates

Una vez hecho esto en el momento en que haya alguna actualización pendiente de realizar se nos informarán por correo, evitando así tener que entrar periódicamente al servidor y comprobar esto de forma manual.

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