Muchas de las web que se visitan a diario están comprometidas, y el usuario corriente navega por ellas sin tener conocimiento alguno del peligro que supone no tener el navegador o la versión de Adobe Flash  actualizada. A continuación vamos a ver un análisis de este tipo de compromisos que por desgracia, cada día es más habitual.

En el análisis de tráfico HTTP se pueden usar herramientas como Burp o  Fiddler.

En este ejemplo he usado Fiddler y en navegador Iceweasel con un plugin para simular distintos User Agent (Switch  user agent), para en momentos determinados emular Internet Explorer.

Si se quiere instalar Fiddler bajo Linux con mono, se puede seguir este manual:

http://fiddler.wikidot.com/mono

[Read more…]

(Los dominios y nombres de usuario que se describen en este post son ficticios, con el fin de proteger la identidad de los reales)
Una de las tareas habituales a la hora de buscar posibles infecciones es analizar el trafico de navegación web (proxy) en busca de contactos con dominios de carácter dinámico (dyndns, no-ip.org, etc…).

En una de estas búsquedas se ve el contacto con un dominio dinámico sospechoso desde la página www.hospitales.com:

2015-08-09 10:53:40 191.226.176.112 Pgarcia - "none" http://www.hospitaless.com/en/index.php  0 - GET http yyuewv.hopto.org 80 /wordpress/ 633 409

El dominio está inactivo, pero queremos analizar las peticiones que se hacen al visitar esta web. Para ello, uso un analizador como Burp:

[Read more…]

En este último capítulo sobre Pfsense (ver I, II, III, IV y V) se explica la configuración de un servidor proxy como Squid en modo transparente para no tener que configurar todos los equipos de la red.

La tarea de este proxy será registrar todas las conexiones HTTP, hacer estadísticas de navegación y denegar ciertos dominios.

El primer paso es instalar estos 3 paquetes: Squid, SquidGuard y Ligthsquid.

[Read more…]

En este quinto capítulo sobre Pfsense (ver I, II, III y IV) se explicará la instalación y configuración de Snort, con el fin de incluir un NIDS en nuestro firewall.

Para instalar Snort en system > packages

Una vez instalado, en services > snort, se procede a su configuración:

-= Pestaña iface settings =-

Es donde se elige el lugar en el que Snort va a esnifar. wlan0 en caso de querer que actúe entre internet y la entrada del firewall, o ya si se quiere algo mas interno seria en opt1 para la DMZ o LAN para la red interna. En este caso para ver todo el tráfico hacia Internet lo mejor es elegir wlan0.

Respecto a la variable home_net y external_net se pueden dejar por defecto ya que home_net englobará a todas las direcciones IP internas y external_net a todas las que sean diferentes de home_net.

-= Pestaña WAN barnyard2 =-

Barnyard2 permite procesar los log de Snort e insertarlos en una base de datos externa:

En el apartado “MYSQL Database Output settings” es donde se configura el servidor MySQL externo, donde barnyard2 insertará los Log de Snort. Previamente en este servidor externo se debe crear la base de datos snort y dar permisos al usuario snort y a la dirección IP de Pfsense (192.168.1.2) para que pueda acceder a la bbdd:

mysql -u root -p

CREATE DATABASE  snort;

grant INSERT,SELECT,UPDATE,CREATE,DELETE,EXECUTE on snort.* to snort@192.168.1.2
Set password for snort@192.168.1.2=PASSWORD('snortpass');
flush privileges;

y posteriormente crear el esquema de esta base de datos (se puede descargar desde aquí):

mysql -D snort -u root -p < ./schemas/create_mysql

-= Pestaña Global Settings =-

Las reglas de detección del IDS tienen un papel importante y en este apartado es donde se configuran. Para incluir las reglas VRT se debe incluir un código, que se consigue al registrarse en la web de Snort.

Al registrarse envían un correo con el enlace para entrar logeado en la web de snort.org, luego en nuestro perfil conseguimos el oinkcode.

-= Pestaña updates =-

Por último en la pestaña updates se procede a la descarga de las reglas:

-= Pestaña Suppress =-

Al igual que en el fichero threshold.conf de Snort, es aquí donde se puede limitar las alertas, por origen, destino,o por el numero de coincidencias en un determinado tiempo. Veamos un ejemplo:

Se tiene primero que buscar el sig_id (identificador único de cada regla), para poder limitar las alertas (para el ejemplo “1852”):

• No alertar cuando el origen sea 192.168.3.0/24.
• No alertar cuando el destino sea 192.168.1.10 y 192.168.1.11:

  suppress gen_id 1, sig_id 1852, track by_src, ip [192.168.3.0/24] 
  suppress gen_id 1, sig_id 1852, track by_dst, ip [192.168.1.10,192.168.1.11]

• Suprimir directamente toda la regla:

  suppress gen_id 1, sig_id 1852

• Solo alertar de una de las alertas de la firma cada 3600 segundos:

  event_filter gen_id 1, sig_id 1852, type limit, track by_src,  count 1, seconds 3600

• Suprimir cualquier regla para un origen concreto:

  suppress gen_id 1, sig_id 0, track by_src, ip [192.168.1.1]

Para mas información sobre las configuraciones, se puede visitar el siguiente link.

-= Pestaña Pass list y Blocked =-

En el caso de que Snort también funcione como IPS, es decir no solo alerte, sino que pueda bloquear, en estas dos pestañas se elige qué direcciones están exentas de bloqueo o cuáles bloquear. Por defecto las direcciones WAN, los gateway, servidores DNS, VPN, etc. están en la lista de no bloqueo.

Dentro de Services > snort > snort interfaces se edita (botón a la derecha con la letra “e”) en la pestaña WAN Categories:

Se pueden escoger qué reglas usar como se muestra en la imagen.

En la siguiente y última entrada de la serie sobre Pfsense veremos el tema de Squid como proxy HTTP. Espero que os haya parecido interesante.

Volvemos a la carga con la cuarta parte de nuestra serie sobre pfSense. En el anterior capítulo explicamos cómo configurar las opciones avanzadas del sistema (ver también la primera entrada y la segunda, para los despistados). En esta cuarta parte vamos a explicar cómo configurar “el corazón del firewall”, es decir las reglas de pfSense.

Lo primero, para facilitar la creación de reglas, es importante saber lo que son los “alias” y qué posibilidades brindan. Vamos a la pestaña superior, Firewall → Aliases.

Dentro podemos crear diversos alias como Hosts, subredes, puertos y URLs. Este es un ejemplo de creación de alias para los servidores que pertenecen a la red DMZ:

Así es como se vería un resumen de todos los Alias creados:

Ahora se trata de usar estos alias para configurar las reglas en el apartado Firewall → Rules. Lo más importante que debemos tener en cuenta al crear una regla es que prevalece la prioridad de la regla que se sitúa por encima de otra regla.

En nuestro ejemplo (y en general, en cualquier entorno en producción) la red DMZ no debe tener acceso a la red interna, ya que la DMZ es la que albergará los servidores que están expuestos a Internet y esta red no debe tener ningún tipo de comunicación hacia la red interna. Por otro lado, sí que nos interesa que se puedan gestionar los servidores desde la red interna hacia la DMZ, por lo que podemos crear una regla que permita el trafico por el puerto 22 (SSH) desde la red interna hacia la DMZ.

En el apartado Rules, la interfaz que pertenece a DMZ es “OPT1”, desde allí, existe un botón con el símbolo “+” para añadir reglas. Por tanto, creamos una regla que deniegue el acceso desde la DMZ a red interna, donde en “Destination” usamos el alias “Subnet_lan” creado anteriormente.

Exactamente de la misma forma pero desde la interfaz LAN (red interna) crearemos una regla que deniegue todo el tráfico desde red interna (LAN) a la subred DMZ (más adelante se superpondrán reglas que prevalezcan sobre esta). A continuación, creamos una regla por encima de la anterior que permita la comunicación SSH desde red interna (LAN) hasta los servidores en DMZ:

Ahora en las reglas del firewall de la interfaz LAN (nótese que el deny de DMZ hacia LAN está en el interfaz OPT1, por eso no se muestra) se vera así:

En la regla de más arriba (la más prioritaria) están permitidos dos puertos 10443 y 10022, que son los que se usan para administrar PFsense por HTTPS y SSH. Esta regla se crea por defecto y es importante que exista ya que en caso contrario, se estaría denegando el acceso al propio firewall.

El siguiente paso es configurar NAT (Network Address Traslation). Para ello en la sección NAT en Port Forwarding, configuraremos que nos permitan acceder al servidor web y al servidor FTP desde internet a estos dos equipos situados en la DMZ. En el caso del HTTP sería como se muestra en la imagen.

Tras aplicar ambas reglas, tendríamos una situación como la siguiente:

Es importante saber que al crear esta regla en NAT automáticamente se crean las reglas del firewall asociadas, de forma que se pueda hacer efectivo el acceso desde fuera hacia dentro. Por tanto, así quedarían las reglas del firewall en la interfaz WAN ahora:

Con estos ejemplos básicos ya podemos comenzar a “trastear” con pfSense y un mayor número de reglas. En el siguiente artículo veremos la implementación de herramientas como un IDS (Snort) o un proxy (Squid), dentro de pfSense.