Bastionado de un servidor WEB Apache (II)

Como ya vimos en el anterior post, lo primero que deberíamos hacer al instalar un apache es ocultar cierta información que podría ser usada para ponérselo más fácil a algún malintencionado para que nos ataque. Como bien se dijo en los comentarios, esto no proporciona seguridad en si mismo, si no que dificulta (un poco) un posible ataque.

Otro factor que creemos que debería tenerse en cuenta, sin entrar todavía en la protección activa, es el de ajustar la configuración según el uso se va a dar a la aplicación web que apache va a servir. Pasemos a describir los métodos mas esenciales que debemos tener en cuenta.

Segundo paso: Activa lo justo y necesario

Lo primero que se podría realizar, para asegurar que cada directorio tenga activado únicamente lo que se necesite, es desactivar las Options y “overrides” para el servidor, teniendo que ir activando una a una, de manera explícita, las que necesitemos. Supongamos que tenemos una aplicación en www, entonces podríamos hacer algo así:

<Directory />
Order Deny,Allow
Deny from all
Options None
AllowOverride None
</Directory>

<Directory /www>
Order Allow,Deny
Allow from all
</Directory>

Por otro lado, una de las recomendaciones más comunes a la hora de configurar apache es la de evitar que éste tenga la posibilidad de seguir enlaces simbólicos. Esto se hace para evitar que un enlace simbólico malicioso pueda acceder a archivos fuera de la estructura de directorios, con el consecuente riesgo de que estos sean manipulados o destruidos. Para evitar esto, debemos marcar la directiva FollowSymLinks con un “-” en el directorio especificado.

<Directory>
...
Options –FollowSymLinks
...
</Directory>

En el caso que se necesite que se puedan seguir enlaces simbólicos, puede usarse SymLinksIfOwnerMatch, que sirve para que el servidor siga los enlaces simbólicos siempre y cuando los ficheros o directorios finales pertenezcan al mismo usuario que el propio enlace.

Es importante desactivar la opción de ejecución de CGI en todos los directorios de la web, salvo en uno concreto destinado a alojar todos los ejecutables. De esta forma se minimiza la posibilidad de que un atacante ejecute código de forma aleatoria. Lo desactivamos de la misma forma que los enlaces simbólicos.

<Directory>
...
Options -ExecCGI
...
</Directory>

En muchos casos la configuración para un directorio en concreto está en el archivo .htaccess. Las siguientes directivas evitan, mediante el uso de una expresión regular, que se puedan descargar los archivos que empiezan por “.ht”:

AccessFileName .httpdoverride
<Files ~ “^\.ht”>
Order allow,deny
Deny from all
Satisfy All
</Files>

Por supuesto, no actives módulos innecesarios, y desactiva aquellos que no vayas a usar.

Otro factor que podemos tener en cuenta es controlar desde dónde se va a consultar la aplicación web. Si el objetivo es que sólo se consulte desde una intranet conocida, o desde una única IP, esto se puede configurar de la siguiente forma:

<Directory>
...
Order Deny,Allow
Deny from all
Allow from 192.168.0.0/16
...
</Directory>

para una red, o:

<Directory>
...
Order Deny,Allow
Deny from all
Allow from 127.0.0.1
...
</Directory>

para una única IP.

En las siguientes entregas hablaremos un poco más de que parámetros se pueden usar para ayudar un poco más en la defensa e instalaremos algunos módulos exclusivos para defendernos de varios tipos de ataque.