, 22 febrero 2012 | Imprime

Este es el primer post de una serie elaborada por José Luis Chica y Guillermo Mir. En ésta se quieren recoger los pasos que se pueden realizar (en muchos casos creemos debería ser imperativo realizar) para instalar y securizar un servidor Apache. Existen múltiples entradas y páginas que explican, de manera separada, como realizar diversas tareas, pero nosotros nos hemos propuesto exponerlas todas en esta serie, de manera que puedan servir de guía a todos aquellas personas que se han de instalar o gestionar un servidor de estas características. El sistema operativo que vamos a usar en los ejemplos es un Linux con distribución Debian Squeeze (6), pero esto sólo va a influir en las rutas dónde se encuentran los distintos ficheros de configuración.

Primer paso: Ocultando información

Una instalación por defecto de Apache muestra cierta información relacionada con el entorno donde ha sido desplegado. Dependiendo del sistema operativo, esta información puede variar pero en general, un posible atacante puede recopilar datos muy útiles que le puedan aportar vectores de ataque adicionales. Así pues, solo tendría que comprobar si existen vulnerabilidades conocidas en las versiones de las tecnologías utilizadas.

Pongamos como ejemplo la respuesta de una instalación por defecto de un WordPress sobre un Apache:

HTTP/1.0 302 Found
Date: Thu, 19 Jan 2012 11:27:54 GMT
Server: Apache/2.2.16 (Debian)
X-Powered-By: PHP/5.3.37
X-Pingback: http://example.com/wordpress/xmlrpc.php
Content-Length: 0
Content-Type: text/html

Se puede ver como en tan poco espacio encontramos tanta información. No obstante, es posible minimizar el revelado de información. Comencemos por eliminar la información relacionada con la versión de apache. Ésta se modifica cambiando las siguientes directivas en el fichero /etc/apache2/conf.d/security:

ServerTokens ProductOnly
ServerSignature Off

Esto disminuye la cantidad de información ofrecida en las cabeceras de respuesta HTTP. Antes se mostraba la siguiente cadena:

Server: Apache/2.2.16 (Debian)

Aplicando las directivas anteriores:

Server: Apache

Igualmente, se elimina la información relativa a Apache en las páginas de errores 400.

Es posible modificar la cadena del banner Server: Apache para que se personalice con un texto propio y poder así confundir al atacante. Una forma es modificando una cadena concreta del código fuente y recompilándolo, pero en un entorno de producción, cuyas actualizaciones son habituales (o deberían serlo :P), no parece muy práctico. La alternativa es utilizar mod_security. Para ello solo tenemos que añadir las siguiente directivas al fichero de configuración:

ServerTokens Full
SecServerSignature “Nintendo Game Boy Color 1.0”

Se entrará en más detalle sobre la configuración de mod_security para securizar apache en un post posterior.

La información sobre la versión de PHP puede ser útil para un posible intruso, por lo que vamos a ocultarla también. Para ello, es necesario editar el fichero /etc/php5/apache2/php.ini y cambiar la siguiente directiva:

expose_php = off

De esta forma, la línea donde se muestra la versión de PHP como la que se ha puesto de ejemplo anteriormente, desaparece.

Otra manera de ocultar información, y confundir a las herramientas automatizadas, es personalizando los errores de página. De esta manera en estos casos el código devuelto en la respuesta HTTP será un 200 en lugar de un 404 o un 500. El lugar para configuraro es el fichero del virtualhost donde se quiera hacer, dentro de /etc/apache2/sites-available:

<Directory>
...
ErrorDocument 404 /myError404.html
ErrorDocument 500 /myError500.html
...
</Directory>

Donde myError*.html son las páginas personalizadas que hemos creado para que se muestren cuando exista un error, en vez de la página genérica de Apache.

También es recomendable recordar, aunque parezca básico, configurar cada site denegando el listado de directorio. Es sorprendente la cantidad de webs que se pueden encontrar que permiten navegar por su estructura de directorios. Se configura igualmente dentro del fichero de configuración del virtualhost:

<Directory>
...
Option -Indexes
...
</Directory>

Continuaremos con el bastionado de Apache en una próxima entrada. Esperamos que la primera entrada les haya resultado interesante.

(Puedes seguirnos en Twitter: @SecurityArtWork)
No me gusta esta entradaMe gusta esta entrada (+9 rating, 9 votes)
Loading ... Loading ...




9 comentarios a “Bastionado de un servidor WEB Apache (I)”

(Tenga en cuenta que los comentarios en español y en inglés están mezclados por lo que puede necesitar un traductor online para entender los comentarios de otros usuarios)

Muy bueno, si señor.

Saludos.-

raimungar [web], 22 de febrero de 2012, 12:06 pm

Muy interesante. Enhorabuena.¿Para cuando el siguiente post?

Maite [web], 22 de febrero de 2012, 12:40 pm

La seguridad por oscuridad es un buen comienzo
Gracias por el post

petrohs [web], 22 de febrero de 2012, 6:18 pm

De lujo, desinstalé un Apache porque ni me fiaba de mi propia configuración, seguro qeu con esta guía vuelvo a coger confianza y lo vuelvo a instalar.

Muhcas gracias!!

apachito [web], 23 de febrero de 2012, 1:32 am

Por ahora solo veo oscuridad lo cual no aporta seguridad.

apachete [web], 23 de febrero de 2012, 9:20 am

Por eso se le ha encabezado a este artículo con “Primer paso”, porque luego habrán mas ;)
Es cierto, la oscuridad nunca aporta seguridad, porque las vulnerabilidades siguen existiendo, por mucho que la ocultes. Pero si es una medida para ponérselo mas difícil a un atacante o malware, merecerá la pena, no?
Imagina simplemente un gusano que le atiza sistemáticamente a una versión concreta de Apache, o un buscando en Shodan sitios vulnerables.

Saludos!

jchica [web], 23 de febrero de 2012, 9:53 am

como dice jchica…. por lo menos se lo pones mas dificil… tipo alarma o rejas en casa, no imposibilitan el acceso al 100% pero hace que el atacante que no tiene un objetivo fijo, tu server o empresa, se vaya a otro sitio a mirar, de hecho es una de las funciones de los escoltas, en el mundo fisico de la seguridad, su principal mision es disuadir al atacante y que se fije en otro objetivo no llevarse el “tiro” o impacto.

cr0w [web], 23 de febrero de 2012, 10:34 am

Muy claro todo, excelente trabajo.
Siento a lo mejor algo de curiosidad y al leer este post me pregunté lo siguiente:
Si ocultas la información de php es muy útil, para no saber distinguir con que exploit penetrar a nuestro server, lo mismo con Apache, aunque ahi me entra la duda, será bueno no poner la versión?, no será mejor con el factor sorpresa, ejemplo: si un intruso ve que estamos actualizados, lo poensará dos veces antes de atacar, si ve una versión anterior, no tendrá duda en hacerlo, pero si solo ve Apache, creo yo que se pondrá como reto el saber que versión tienes, o no lo creen?
De todas maneras si teemos todo nuestro firewall bien confirgurado, las actuaizaciones más recientes y monitoreamos constantemente la actividad, no creo que suponga un inconveniente el ocultar la version de apache sino al contrario, podria considerarse como una ventaja.
Saludos y nuevamente felicidades por este post

00000101net [web], 6 de julio de 2012, 7:51 pm
Guía básica para asegurar nuestro servidor web Apache | Cyberthrone [web], 13 de agosto de 2013, 9:42 pm

Deja un comentario

(Los datos que nos proporciones serán incorporados al fichero LECTORES DEL BLOG cuyo responsable es S2 Grupo, cuya única finalidad es la gestión de las acciones e interacciones que se desarrollen con los usuarios de los blogs de S2 Grupo, entre los que se encuentra Security Art Work. Los datos recogidos no serán en ningún caso cedidos a terceras partes ni tratados para una finalidad distinta a la indicada. Puedes ejercer tus derechos de Acceso, Rectificación, Cancelación y Oposición enviando un correo a admin@securityartwork.es, en el que deberás proporcionarnos la información necesaria para verificar tu identidad. Para cualquier otra consulta o duda relativa a cómo gestionamos tus datos personales, puedes utilizar el mismo correo electrónico.)