Muchas veces hemos oído el termino bastión o bastionar un servidor en una red DMZ. Este término es empleado cuando a una configuración por defecto de una instalación en un servidor se le realizan modificaciones para fortalecer la seguridad del sistema. A muchos de ustedes les vendrá a la mente Bastille en entornos RedHat.
Dichas modificaciones suelen estructurarse comúnmente en tres etapas:
- La primera etapa se centra en cerrar los puertos de aquellos servicios que escuchan por defecto y que no se requieren para las necesidades solicitadas para dicho servidor.
- La segunda etapa consiste en fortalecer la configuración de los servicios que si se necesitan mediante la restricción de los usuarios que pueden acceder a los servicios, restricción de ordenes que pueden realizar, control y filtrado de los datos que se le envían al servidor (XSS, SQL injection, etc), política de actualizaciones…
- La tercera etapa se centra en instalar el servidor en la red DMZ, la cual dispone de un firewall que restringe el acceso de las máquinas externas hacia la DMZ.
Pero realmente bastionar un servidor no consiste únicamente en dichos pasos; hay que tener en cuenta muchas acciones previas que se deberían realizar tal como veremos a continuación:
Hay que restringir el acceso vía red de los servidores. Normalmente y tal como se ha comentado se suele situar un firewall en la entrada a la red DMZ, pero las reglas de los firewall no suelen contener ningún tipo de restricciones de conexión entre los servidores. Si un servidor no debe tener ningún tipo de tráfico con otro servidor de la DMZ, se debe establecer un conjunto de reglas que no permitan que exista tráfico entre ambas máquinas. De no ser así, si un atacante consigue el control de una máquina de la DMZ, podrá atacar al resto de máquinas desde dicho servidor sin que el tráfico sea filtrado. A su vez, se debería emplear envolturas y reglas de filtrado a nivel del servidor (local) para que en caso de que el router fuera atacado, el servidor no estuviera desprotegido.
Otro punto a tener en cuenta es qué tipo de herramientas se le permite tener instaladas en un servidor de DMZ y con qué permisos. No hay ningún motivo por el cual un servidor disponga de herramientas de desarrollo como compiladores, interpretes de shell, desensambladores, etc. sin restringir el acceso a ellos.
Si no se restringe qué usuarios pueden tener acceso a dichas herramientas cualquier atacante que se haya colado en el sistema, aunque sea con un usuario con pocos privilegios, podría usar dichas herramientas para intentar explotar una escalada de privilegios. Muchas veces existe el error de pensar que un fallo de seguridad no es grave si solo se puede explotar de forma local.
A su vez, cada servicio de la máquina debe ejecutarse con un usuario/grupo propio y único para dicho servicio, y que dicho usuario/grupo tenga el menor número de permisos posibles. El motivo es muy sencillo: si se consigue explotar una vulnerabilidad en un servicio, aunque dicho servicio no sea crítico las ordenes que el atacante quiera realizar se harán con los permisos del usuario y grupo con que se haya ejecutado el servicio atacado.
Por ejemplo, en un servidor Windows donde todos sus servicios se ejecutan con usuario SYSTEM, si un atacante consigue introducir una shellcode en un buffer overflow en un servicio, por muy poco critico que sea dicho servicio, como puede ser un servicio NTP, habiendo obtenido una shell por un fallo en dicho servicios, tendremos control total sobre el resto de servicios de la máquina. Este mismo ejemplo se puede llevar en caso de un servidor Linux/Unix cuyos servicios corren con permisos de usuario o grupo de root.
Si en cambio cada servicio se ejecuta con usuario propio y grupo propio, como por ejemplo www-data para apache o ftp para vsftpd, una vulnerabilidad de dicho servicio solo afectaría a ese servicio. De la misma forma que sólo se tendría acceso a aquellos ficheros y aplicaciones que se le haya permitido a ese usuario o grupo.
Otro fallo común es el uso del bit suid y guid con permisos de administración (root) en aplicaciones que realmente no son necesarias para un usuario sin privilegios, como pueda ser el ping, porque… ¿hay algún motivo para que un usuario sin privilegios tenga que realizar ping en un servidor de la DMZ? Se debe restringir dichos permisos únicamente a aquellos ficheros y directorios que realmente se requieran para el correcto funcionamiento del servidor y eliminar los permisos de aquellos ficheros que no sean necesarios.
Para finalizar, recordar que es crucial disponer de un sistema de copias de seguridad, una red de detección de intrusos, un sistema de integridad de los datos (aide, tripwire…) y un sistema de logs tanto locales como un sistema de logs centralizados. De esta forma un atacante tendría que atacar al servidor de copias de seguridad, al servidor de integridad de los datos, a la red de detección de intrusos, modificar los logs del sistema y del servidor de logs centralizados. Y todo esto sin que el IDS, IPS o el sistema de integridad de los datos notifiquen de una alerta al gestor de eventos.
¿Imposible de entrar entonces? No, simplemente más difícil.
(La fotografía es uno de los bastiones del Castillo de Copertino en Italia, por Istvánka en la Wikipedia)
