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