| Artículos | 01 SEP 2007

Fortificando un servidor Apache

Tags: Histórico
Chema Alonso.
En varias ocasiones hemos hecho hincapié en definir la seguridad informática como tres factores complementados: los procesos, los usuarios y la tecnología. De nada sirve tener la mejor tecnología sin unos buenos procesos de implantación, gestión y actualización que la mantengan segura o sin unos usuarios responsables. En el presente artículo vamos a repasar algunas recomendaciones para fortificar un servidor Web Apache.

Las leyes de la fortificación
La fortificación de sistemas tiene tres principios básicos que dirigen todo el proceso y que debemos tener siempre presentes en cualquier fortificación que vayamos a realizar, por lo tanto, son igualmente aplicables en este caso también:
- Mínimo Punto de Exposición (MPE): en un servidor sólo deben exponerse las partes estrictamente necesarias para cumplir el rol para el que fue desplegado; es decir, un servidor web no debe tener cargado el software para imprimir, y mucho menos ejecutando demonios de servicio de impresión en red. Esta regla ha hecho que las instalaciones de los sistemas operativos ya no sean orientadas a componentes, es decir, instalando módulos, y se realicen orientadas a roles, es decir, instalando módulos absolutamente necesarios para el cumplimiento de un determinado papel.
- Mínimo Privilegio Posible (MPP): todo componente dentro de un sistema debe ejecutarse con los privilegios necesarios para cumplir con su rol, y nada más. Un sitio web nunca debe correr como administrador porque no es necesario para dar servicio, y si ignoramos este principio puede suceder que un atacante que, por cualquier razón, consiga vulnerar el sitio, obtenga esos privilegios de root en el sistema.
- Defensa en Profundidad (DP): se deben implementar todas las medidas de seguridad que sean posibles teniendo en cuenta dos factores. En primer lugar, una medida de seguridad no debe nunca anular a otra. El ejemplo más claro de esto es cifrar las comunicaciones e instalar un Sistema de Detección de Intrusiones de Red (NIDS). Esto nunca debe suceder, ya que el segundo no podría detectar ataques por red si se usan los canales cifrados. El segundo de los factores es que las medidas de protección no pueden anular la utilidad de un sistema. Si las medidas de protección hacen que el sistema deje de dar servicio en tiempo útil, entonces no son medidas viables.

Las fuentes del servidor
Cuando instalamos un servidor Apache tenemos varias formas de obtener y mantener los ficheros del servidor. El primer camino es ir directamente al proyecto y descargar la última versión compatible con el sistema operativo donde lo vayamos a desplegar, y después realizar las comprobaciones oportunas de los ficheros mediante el hash y la firma. Después de esto lo configuramos, compilamos y listo. Esto es importante sobre todo cuando descargamos ficheros desde otros servidores mirror. La otra opción es descargar los binarios compilados para el sistema operativo, con lo que en este caso habría que realizar la comprobación del hash y la firma de los ficheros directamente sobre los binarios. Hemos de procurar descargarnos los ficheros compilados de los servidores que marcan los fabricantes del sistema operativo, con el fin de evitar problemas como código ya modificado o troyanizado.
Por lo tanto, elegir correctamente el lugar de la descarga del fichero evita situaciones que, aunque a priori puedan parecer algo paranoicas, lo cierto es que existen como formas de atacar sistemas desde las fuentes. De hecho, los lectores interesados en este asunto pueden consultar algunos documentos, como “Troyanizando Apache y sus Módulos”, escrito por Sp4rK, que están disponibles en internet.
Para este ejemplo hemos escogido la última versión de Apache disponible de la rama 2.x (concretamente 2.24) y que, como reza en la propia web del proyecto, es principalmente una versión bugfix, es decir, correctora de bugs (y que nos parece la mejor opción del proyecto Apache). Es posible acceder a los bits desde //httpd.apache.org/download.cgi y es importante que, si realizamos una actualización de una versión a otra, revisemos el Changelog donde se indican los principales cambios de cada versión, con el fin de no encontrarnos con incompatibilidades de software.
No obstante, según nuestro punto de vista, no vale con descargar la última versión del producto, sino que además consideramos extremadamente importante estar suscritos a las actualizaciones de seguridad del producto, pues mantener el servidor actualizado es una de las principales tareas de las que preocuparse para mantener segura una infraestructura con Apache.
Una vez que lo hayamos descargado, podremos acceder a las fuentes del archivo, al fichero hash MD5 y a la firma pública del códigos fuente. Así podremos comprobar que el fichero es el mismo que ellos publican realizando, en primer lugar, una comprobación del hash y, en segundo lugar, una comprobación de la firma. Para realizar la comprobación de la firma es necesario tener las de los distribuidores de los ficheros del proyecto, que están accesibles en http://www.apache.org/dist/httpd/KEYS.
Posteriormente habremos de verificar la firma mediante el comando gpg --verify http-2.2.4.tar.gz.asc, que es el fichero con la firma de las fuentes, y el hash md5 generando un nuevo hash del fichero con el comando md5 http-2.2.4.tar.gz (comprobando si el valor es el mismo que nos ofrecen en el fichero http-2.2.4.tar.gz.md5).

Cambio del banner
Una de las reglas de oro es dar la menor información posible sobre nuestro sistema con el fin de reducir el número de atacantes posibles. Muchos escáneres de vulnerabilidades realizan una comprobación del banner que devuelve el servidor web para poder aplicar unos u otros exploits. Una de las primeras recomendaciones es cambiar dicho banner para que no puedan realizar ataques dirigidos y conocidos en nuestro entorno. Para cambiar el banner debemos modificar el archivo ap_release.h antes de configurar el servidor.
De hecho, es posible incluso cambiar la versión de Apache (nosotros hemos dejado la 2.2.4.0). Cambiar ese banner ayudaría a que Apache bajara en las estadísticas de Netcraft, tan llevadas y traídas en el mundo de la competición software. Por lo tanto, si no queremos dar ninguna información pero nos interesa que las estadísticas sigan contando nuestro servidor, podemos especificar un genérico Apache utilizando la clave ServerTokens Prod en el archivo httpd.conf.

Configuración e Instalación
Cuando hayamos cambiado el banner ya estaremos listos para configurar los módulos que queremos habilitar de nuestro servidor Apache. Para ello, antes de realizar la configuración de las fuentes, es recomendable analizar qué servicios necesitamos mantener activos. Todos los módulos que hay para Apache están documentados en la dirección modules.apache.org y existe una lista reducida en httpd.apache.org/docs/2.0/es/mod. Actualmente hay más de 400 módulos disponibles para Apache, luego es importante controlar cuáles de ellos necesitamos mantenerlos activos y cuáles no. Aunque cada caso es completamente distinto, desde nuestro punto de vista, algunos módulos que se cargan por defecto y no suelen ser necesarios pueden ser:
- mod_imap: ofrece servicio de mapeo automático de ficheros de índice del lado del servidor.
- mod_include: habilita los includes de ficheros del lado del servidor (.shtml).
- mod_info: da información sobre el servidor (los escáneres rastrean la información

Contenidos recomendados...

Comentar
Para comentar, es necesario iniciar sesión
Se muestran 0 comentarios
X

Uso de cookies

Esta web utiliza cookies técnicas, de personalización y análisis, propias y de terceros, para facilitarle la navegación de forma anónima y analizar estadísticas del uso de la web. Consideramos que si continúa navegando, acepta su uso. Obtener más información