Mejorando la seguridad en Apache2 .htaccess

En una entrada anterior enseñamos como configurar mod_rewrite en nuestro .htaccess para poner a «punto de caramelo» nuestro Apache2 pero ahora es necesario preveniros de «haber abierto la caja de Pandora»: nuestro servidor web está expuesto a tácticas de intromisión y hasta toma de control por atacantes con malas intenciones. Sirva pues la presente para complementar y ayudaros a proteger vuestros equipos.

Prerequisitos.

Es bueno que leaís nuestro tutorial para configurar mod_rewrite pero si soís más avanzado os decimos de una vez que tenemos configurado ya un servidor Apache2 sobre Ubuntu 16 en una red de área local con la dirección 192.168.1.47

Para ser más exactos, corremos Apache 2.4 y podemos conocer cuál versión tenemos instalada abriendo una ventana terminal y ganando acceso como «root» o administrador:

root@KEVIN:/home/jimmy# apache2 -v
Server version: Apache/2.4.18 (Ubuntu)
Server built: 2016-07-14T12:32:26

Otra cosa que tenemos activado es el tratamiento de archivos .html o .htm como .php lo cual abre la posibilidad a que nuestra seguridad quede expuesta si alguien logra acceder a escribir en nuestro .htaccess (de nuevo os recordamos que todo está explicado en nuestra entrada anterior sobre como configurar mod_rewrite). Eso quiere decir que tenemos la siguiente instrucción en el archivo .htacces:

AddType application/x-httpd-php .html .htm

Al estar así configurado pasamos a estudiar las posibles brechas en seguridad.

Lo bueno, lo malo y lo feo.

Recordando la famosa película de vaqueros así clasificaremos las tretas y estrategias, poned atención que cada una de ellas es un caso particular a estudiar, pausar y seguir adelante para, al final, tener un panorama completo de la estrategia a seguir que más convenga a nuestro entorno de trabajo.

Empezaremos por lo malo, luego lo feo y de último lo bueno que podemos hacer.

Lo malo.

php_value auto_append_file.

Vale decir que este comando php_value bien puede estar ubicado ya sea en «PHP config», «virtualhost settings» o en un archivo .htaccess que es el caso que nos ocupa y más específicamente el valor auto_append_file porque coloca al final de nuestra página web (en este ejemplo didáctico el archivo index.html que trae por defecto Apache al ser instalado) los valores que tengamos en nuestro archivo hosts con la siguiente instrucción:

php_value auto_append_file /etc/hosts

El resultado sería el siguiente:

Que para nuestro servidor de pruebas nos aporta muy poca información pero imaginad si lo tenéis en un servidor en producción y de paso sea compartido por otros sitios web, dicha información sería muy útil a los atacantes.

Otra variante de esta treta es incluir al archivo .htacces en sí mismo y adicionalmente algún código php. Por ejemplo podemos agregar el comando phpinfo(); con el cual podemos visualizar el entorno de variables con que trabajamos y buscar así software específico para nuestra configuración y poder de esta manera tomar control completo, si fueramos atacantes.

php_value auto_append_file .htaccess
#<?php phpinfo();

php_flag display_errors 1

Hasta ahora hemos visto inyecciones de código que se ejecutan cada vez que es cargado y mostrado un archivo .html ¿pero que tal colocar una bomba eventual? Si, como habéis leido, «eventual» es diferente a una bomba de tiempo, una bomba eventual se ejecuta cuando sucede algún disparador. Para este caso el disparador del evento es cuando nos hayamos equivocado programando algún código php, con la salvedad de que el atacante a nuestra web haya colocado un «script» que se lanza en este suceso, pero veamos el código:

php_flag display_errors 1
php_flag html_errors 1
php_value docref_root "'><script>alert('¡Programador perdedor!);</script>"

En la primera y segunda línea lo que se hace es activar la rutina de aviso de errores (que bien en vez del parámetro «1» puede tomar el valor «on») y en la tercera línea es donde se inserta el código malicioso en sí (acá simplemente mostramos un aviso recriminando el error). Esto sería el equivalente a «castigar» al programador al cometer un error y el script que desencadene podría ser peor aún todavía. Por extraño comportamiento, esto produciría un muy extraño regocijo a nuestro atacante y esperad también ver algún código de aviso para el atacante que nos pudiera servir para dar con el paradero del delincuente digital.

Otra variante sería utilizar php_value docref_ext lo cual duplicaría las ejecuciones del script malicioso.

php_flag display_errors 1
php_flag html_errors 1
php_value docref_root "x"
php_value docref_ext "<script>alert(1);</script>"

QUERY_STRING

En lenguaje HTML y PHP es bien sabido que se puede pasar valores directamente por la barra de direcciones con simplemente agregar al final de la dirección web un signo de cierre de interrogación acompañado del nombre de la variable, un signo de igualdad y el valor de la variable. Si se desean pasar más valores se utiliza un et «&» y se repite el procedimiento. Esto es especialmente útil para iniciar sesión en una página web pero también abre la puerta a posibles robots que intenten, a lo largo de mucho tiempo, ir probando valores automáticamente hasta poder ingresar. Para cerrar esta posibilidad podemos hacer lo siguiente, consideremos el siguiente archivo llamado «bienvenido.hmtl«:

<?php
 echo '<html><body>Bienvenido ';
 if (isset($_GET['nombre'])) {
   $test = $_GET['nombre'];
 } else {
   $test = ' Invitado';
 }
 echo $test;
 echo '</body></html';
?>

Como podéis observar utilizamos el método $_GET a modo didáctico para poder hacer las pruebas sin necesitar de otro archivo con formulario que lo refiera. Si introducimos una consulta como la siguiente:

http://192.168.1.47/bienvenido.html?nombre=Pedro

Obtendremos la siguiente respuesta:

Pero como buscamos bloquear dichos «accesos directos» debemos modificar nuestro .htaccess de la siguiente manera:

RewriteEngine On
RewriteCond %{QUERY_STRING} .
RewriteRule ^bienvenido\.html /bienvenido.html? [L]

La primera línea sabemos que activa la maquinaría de reescritura de direcciones y la segunda es una condición que se cumple siempre: compara la consulta %{QUERY_STRING} (toda la subcadena de texto a la derecha del signo de interrogación) y lo compara con el metacaracter «.» que significa una cadena de texto con cualquier (cualesquiera) caracter(es) de cualquier longitud (1 ó más) para que lo ejecute el siguiente comando RewriteRule. Este comando simplemente pasa la dirección con el nombre del archivo en cuestión acompañado de la bandera [L] que le indica que no procese las siguientes líneas en el fichero .htaccess . El resultado sería que el fichero bienvenido.html (que contiene un guion de comandos escritos en lenguaje PHP) muestre el mensaje «Bienvenido Invitado» como si no hubiera pasado consulta alguna al servidor web.

Para suplementar lo anterior, son bien famosos los robots que hacen publicidad en los comentarios de las entradas de WordPress y por supuesto lo hacen con pases de consultas, las podemos filtrar con palabras claves y prohibirles el acceso. Famosos por ser bien insidiosos son los «spam» de medicamentos para la disfunción eréctil tales como «compre viagra en oferta», vamos a realizar una regla adicional a lo anterior -pase de consultas-:

RewriteCond %{QUERY_STRING} \b(spill|cialis|ejaculation|erectile)\b [NC,OR]
RewriteCond %{QUERY_STRING} \b(erections|impotence|levitra|libido)\b [NC,OR]
RewriteCond %{QUERY_STRING} \b(fitex|sildenafil|tadalafilo?)\b [NC,OR]
RewriteCond %{QUERY_STRING} \b(viagra|duroval|viasek)\b [NC]
RewriteRule .* - [F]

Como apreciamos agregamos las marcas más conocidas pero aún faltan muchas más, como la lista es larga «encadenamos» cada RewriteCond con la bandera [OR] pero la última línea antes de RewriteRule NO debe contener [OR]. La otra bandera utilizada es [NC] para que coincida en la búsqueda en mayúsculas y/o minúsculas y para finalizar la bandera [F] para prohibir el acceso, que devuelva un código 403.

Poned atención en la palabra clave «tadalafilo?» ya que bloquea «tadalafil» o «tadalafilo» y en idioma castellano los nombres de principios químicos activos siempre la última letra produce sinonimías (otro ejemplo: «ciprofloxacino» y «ciprofloxacina» significan exactamente lo mismo). Esto es así debido que en inglés el género no toma mayor importancia (y en el lenguaje cotidiano da pie a muchas situaciones graciosas que aprovechan guiones de series de televisión «sitcom») y cuando se traduce al castellano puede tomar valores ambivalentes y el algunos casos hasta extraños. Al contrario, en este campo, en el idiom inglés son pocos los casos que esto sucede (de hecho ellos GUSTAN de palabras cortas, no hablemos ya si gustan de sinonimias, además ellos utilizan marcas comerciales como nombres propios para los principios químicos activos), un caso muy particular es el medicamento contra la depresión llamado «Prozac» y por algunos es escrito como «Prosac»: en nuestras reglas de expresiones regulares lo podemos marcar como «pro[sz]ac» para que sea detectado -ambas escrituras- y bloqueado en los comentarios de cada entrada pública de nuestro blog.

Lo feo 🙁

php_flag engine 0

Con esta única línea en nuestro archivo .htaccess hará que automáticamente podamos descargar completamente un archivo .html o .php aunque igual se ejecute el guión php obtenemos el código fuente completo, incluidas contraseñas, comentarios, los diversos include hacia otros ficheros, etc. que hayamos colocado en dichos archivos. Nos parece que es la más maliciosa inyección de código en nuestro servidor.

LO BUENO 😎

IndexIgnore *

De manera predeterminada un servidor web Apache siempre buscará mostrar un archivo llamado «index.html» o «index.php» pero si dicho archivo -por alguna u otra razón- no se encuentra entonces se le mostrará al visitante -o atacante- los archivos y subdirectorios presentes, mirad un ejemplo:

Para evitar dicho comportamiento debemos agregar a nuestro .htaccess las siguientes líneas:

IndexIgnore *
Options +FollowSymLinks All -Indexes

Al guardar y revisitar mostrará lo siguiente:

De tener algún problema con la opción «+FollowSymLinks» (mirad imagen siguiente) simplemente comentarla y guardar de nuevo el archivo .htaccess.

DirectoryIndex

Mencionamos en el punto anterior que siempre buscará servir un fichero «index» pero ¿qué tal si tenemos dos ficheros llamados «index.php» e «index.html» en el mismo directorio?

Pues con la orden DirectoryIndex podemos ordenar cual se ejecuta primero -y de no conseguirse ejecuta el segundo-, esto puede ser de utilidad si queremos «forzar» cuál clase de archivos queremos siempre mostrar.

DirectoryIndex index.html index.php

En este ejemplo -recordad la configuración de servidor- obligamos que sea mostrado «index.html» primero (y dentro tenemos el código php necesario que será ejecutado por nuestra configuración especial .htaccess) y de no conseguirse buscaría mostrar «index.php». Un atacante podría colocar su propio «index.php» y modificar .htaccess para camiar este orden. Nosotros preferimos utilizar solamente lo siguiente:

DirectoryIndex index.html

Así al faltar «index.html» no muestra ninguna página e intentará mostrar los archivos y subdirectorios opción la cual le eliminamos la visualización en el punto anterior.

FileETag MTime Size

Habilitar los ETag en un servidor web trae doble beneficio: por una parte ahorramos en tráfico de bytes lo cual redunda en rapidez al cargar nuestro sitio y el beneficio de la seguridad adicional.

ETags funciona identificando en un archivo TAGS las características que identifican unívocamente para fichero que pondemos a disposición del público. Es transmitido y guardado por el cliente en un caché, luego si recargan la página el servidor envia de nuevo el ETag y si el recurso no ha cambiado pues se ahorra el envio.

Por parte de la seguridad es útil si utilizamos rsync desde un servidor que origina datos (y que no está expuesto a la internet) y sirve para «alimentar» uno o varios servidores espejos -o nodos-. Hay un interesante artículo titulado «Rsync: Sincroniza tus carpetas o respalda tus archivos en Linux – Debian – Ubuntu – Derivados» escrito por el experimentado usuario Twitter @Xombra donde encontraréis mayores detalles acerca del uso de rsync como estrategia de respaldo.

 

Si utilizamos un servidor único podemos agregar INode, cuando hay varios servidores web para una misma página los ETags se vuelven inútiles ya que en cada servidor cada INode es diferente con lo cual incluso incrementa la carga de trabajo en nuestro sitio web. Es debido a esto que se les activa solamente dos atributos: tiempo (MTime) y tamaño (Size).

Para habilitarlo debemos colocar lo siguiente en nuestro archivo .htaccess (pendientes con detalle del INode):

FileETag INode MTime Size

SetEnvIf user-agent

Otra manera de proteger en alguna manera nuestro Apache es denegando a ciertos agentes que visiten nuestro sitio. Cada navegador web envia su identificación al solicitar una página web y a nuestro servidor podemos denegar el acceso (esto no quiere decir que a su vez los atacantes «disfrazen» su software de ataque como algún navegador web popular). La sintaxis que debemos usar es la siguiente:

SetEnvIf user-agent "Wget" stayout=1
SetEnvIf user-agent "Indy Library" stayout=1
SetEnvIf user-agent "libwww-perl" stayout=1
SetEnvIf user-agent "Download Demon" stayout=1
SetEnvIf user-agent "GetRight" stayout=1
SetEnvIf user-agent "GetWeb!" stayout=1
SetEnvIf user-agent "Go!Zilla" stayout=1
SetEnvIf user-agent "Go-Ahead-Got-It" stayout=1
SetEnvIf user-agent "GrabNet" stayout=1
SetEnvIf user-agent "TurnitinBot" stayout=1
deny from env=stayout

En realidad la última línea es la que bloquea los agentes, fijaros bien que la primera línea bloquea al famoso wget que si bien no es un programa malicioso en sí mismo si que se utiliza en scripts que pueden ser mal utilizados. Si tenéis algún script propio que acceda a vuestro servidor web tened cuidado en marcar como comentario dicha línea.

Fuentes consultadas.

En idioma castellano.

• «Teoría sobre Apache» por Sapoclay.
• «Directivas básicas de configuración de Apache 2».

En idioma inglés.

Lo malo:

• «PHP htaccess injection cheat sheet» by Suhosin.
• «Automatically append or prepend files in a PHP script» by TheElectryToolBox.

Lo bueno:

• «htaccess examples (security)» by Joomla.
• «ETags Revisited«

Lo feo:

• «Runtime Configuration«