Una de las mejores prácticas en lo que a seguridad corporativa se refiere, es la implantación de un proxy para la navegación web. Con esta medida, se puede controlar el tráfico web que abandona la organización.
Una de las medidas de seguridad mas aplicadas, es la de restringir en el firewall todo el tráfico web, excepto el que proviene del proxy. Con esta medida, evitamos la conexión de malware sencillo que no lee la configuración de proxy del sistema.
Sin embargo, si disponemos de un sistema de detección de intrusiones ( en nuestro caso, Suricata ) nos vamos a encontrar con diferentes problemas. A continuación explico dichos problemas y los workarounds que he utilizado.
El primer problema que nos encontramos es que los orígenes o los destinos de las alertas nos son inservibles. En la imagen anterior, si Suricata está escuchando antes del proxy, nos vamos a encontrar con que todos los paquetes http tienen como destino el proxy. Si por el contrario ponemos Suricata entre el proxy y el firewall, nos encontraremos con que los paquetes http tienen como origen el proxy.
Una posible solución, sería activar en el proxy la cabecera X-Forwarded-For. De esta forma, todos los paquetes que salieran del proxy llevarían una cabecera HTTP con la IP interna y Suricata podría hacer el matching. El problema de esta aproximación, es que si el firewall no elimina dicha cabecera, se enviaría al servidor web destino con el consecuente problema de privacidad.
Si no se puede eliminar la cabecera en el firewall, podríamos tratar la IP del firewall como una IP externa, así las reglas de Suricata podrían volver a funcionar correctamente. Para hacer esto, simplemente hay que editar el fichero de configuración de Suricata ( por defecto, se encuentra en /etc/suricata/suricata.yaml ) y modificar la variable $HOME_NET e indicar que la IP del proxy no pertenece a esa variable:
HOME_NET: "[10.0.0.0/24,!10.0.0.254]"
Esto debería ser suficiente para arreglar nuestro problema, pero actualmente existe un bug en Suricata que hace que el inicio del programa sea extremadamente lento. En mis pruebas, dicho inicio duró mas de dos horas.
¿Que podríamos hacer para solventar el problema? La opción que utilicé es la de modificar las reglas mediante un sencillo script. El primer paso es declarar la variable PROXY_SERVERS en el fichero de configuracion:
PROXY_SERVERS: "[10.0.0.254,10.0.0.253]"
El segundo paso sería reemplazar todas las referencias a EXTERNAL_NET por PROXY_SERVERS. ¿Todas? La respuesta es .... no. Solo deberíamos reemplazar las reglas que empiecen por "alert http ....". De esta forma, nos aseguramos que solo modificamos las reglas que queremos.
Asumiendo que tenemos nuestras reglas en /opt/reglas/ y que disponemos del directorio /opt/reglas_proxy, solo deberíamos ejecutar el siguiente script:
#!/bin/bash
#For que recorre todos los archivos .rules
for archivo in $(ls /opt/reglas/);
do
#Reemplazo condicional. Si la linea empieza por "alert http" substituir
#$EXTERNAL_NET por $PROXY_SERVERS y guardarlo en un nuevo fichero
sed '/^alert http/s/$EXTERNAL_NET/$PROXY_SERVERS/g' /opt/reglas/$archivo > /opt/reglas_proxy/$archivo
done
y cambiar el directorio de las reglas en el fichero de configuración de Suricata.
David Lladró
Responsable de Seguridad en Datadec Online