Hace algún tiempo tuve que resolver un caso de un ataque de “hombre en medio” (man in the middle) que afectó la mayor parte de los equipos de una organización a través de otro ataque, conocido como DHCP rogue[1]. El equipo de respuesta a incidentes tomó la decisión de apagar el dispositivo para contener el ataque lo antes posible y nos solicitó realizar el análisis forense.

Gracias a que se pudo obtener una imagen forense del equipo atacante y a que la herramienta utilizada dejó bitácoras, se logró determinar qué dispositivos fueron afectados, cuándo y por cuánto tiempo. Sin embargo, este caso no hubiera podido resolverse si la herramienta usada para realizar el DHCP rogue (conocido también como DHCP spoofing) no dejara bitácoras, a menos que estuviera habilitado el log del firewall de host de los equipos afectados.

En este artículo veremos cómo se usa el log del firewall de host para identificar ataques informáticos provenientes de la red interna, que por su propia naturaleza no pueden ser identificados por los dispositivos de seguridad perimetrales, incluyendo el ataque DHCP y varios otros.

Antes de explicar las ventajas de habilitar este log, es necesario recordar algunos conceptos básicos:

¿Qué es un firewall?: es software o hardware que comprueba la información procedente de la red y, a continuación, bloquea o permite el paso de esta en función de reglas preestablecidas por el administrador.

¿Qué es un IDS?: es software o hardware con la capacidad de identificar (pero no prevenir) ataques informáticos y generar alertas con la información del ataque, para que un operador tome la acción adecuada.

¿Qué es un IPS?: además de contar con la funcionalidad propia de un IDS, tiene la capacidad de detener ataques de forma configurable y automatizada, es decir, sin la necesidad de interacción externa.

Los tres dispositivos mencionados pueden implementarse en la red o en los hosts y por lo general generan bitácoras de actividad. Normalmente los de red se colocan en un punto neurálgico de la red, típicamente el perímetro, y los de host se pueden implementar en los equipos finales (computadoras personales y servidores) de la organización.

En la actualidad no se concibe una organización mediana o grande que carezca de un firewall y un IDS/IPS en el perímetro de su red, ya que contribuyen de manera significativa a reducir el nivel de riesgo de sufrir ataques informáticos.

Las grandes corporaciones tienen múltiples dispositivos de este tipo, ubicados en diferentes puntos de la red, que permiten implementar un esquema de seguridad en profundidad, pero la gran mayoría de las organizaciones solo cuenta con estos dispositivos en el perímetro debido al gran costo que implica.

En este escenario, ¿qué ocurre con los ataques que vienen de nuestra propia organización? El tráfico generado por estas amenazas ni siquiera pasará por los dispositivos ubicados en el perímetro y por lo tanto no podrán ser identificadas ni, mucho menos, detenidas.

¿Qué pasa si un empleado de la organización infecta vía memoria USB su equipo de cómputo con un malware que comienza a realizar escaneos y otro tipo de ataques en la red interna? ¿Qué sucede si un atacante logra accesar mediante una red inalámbrica con cifrado vulnerable, para luego efectuar un ataque man in the middle  vía DHCP rogue? Muy probablemente no será detectado por los dispositivos perimetrales. En todos estos casos la bitácora del firewall de los equipos finales puede proveer información valiosa para identificar los ataques.

Por ser Windows el sistema operativo más ampliamente utilizado, a continuación veremos cómo habilitar el log del firewall de este sistema operativo, y algunos ejemplos de ataques que pueden ser identificados con esta valiosa fuente de información.

En primer lugar es necesario decidir si se desea registrar el tráfico aceptado, el rechazado, o ambos. Aconsejo habilitar ambos. Para ello, hay que abrir una terminal de comandos (cmd.exe) con privilegios de administrador y ejecutar:

netsh firewall set logging droppedpackets = enable connections = enable

A continuación debemos preguntarnos ¿Cuánto espacio estoy dispuesto a destinar para almacenar las bitácoras? La respuesta estará en función de la cantidad de tráfico que pase por el dispositivo, su capacidad de almacenamiento, nivel de criticidad y su rendimiento. Se puede iniciar con 20 MB para equipos finales y luego modificar el tamaño de acuerdo con las necesidades de cada caso. Cuando el archivo llegue al tamaño máximo, se sobreescribirá la información anterior y ya no podrá ser recuperada. El comando es el siguiente:

netsh firewall set logging maxfilesize = 20000

Esos dos sencillos pasos bastarán para comenzar a registrar los eventos del firewall de Windows. De manera predeterminada el archivo se ubica en la ruta: C:\Windows\System32\LogFiles\Firewall.

La bitácora es simple y tiene dos secciones, la primera es de directivas y la segunda consta de registros de eventos. Las directivas indican la versión de la bitácora, que fue generada por el firewall de Windows, con la fecha y hora que se toman del sistema local y los campos que contiene. Esta información será de suma importancia cuando se interprete su contenido como parte de un análisis forense. Por ejemplo:

#Version: 1.5
#Software: Microsoft Windows Firewall
#Time Format: Local
#Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path
2013-01-11 12:05:00 ALLOW UDP 172.30.1.1 172.30.1.2 65102 1947 0 - - - - - - - SEND

Ahora veremos cómo identificar, por medio de la bitácora del firewall de Windows, dos ejemplos de ataques informáticos:

1.- Escaneos de puertos realizado con nmap, desde la dirección IP 192.168.220.141 (atacante) a la dirección IP 192.168.220.1 (víctima).

david-bernal-fig-1

Como indicios de actividad sospechosa se observa la gran cantidad de paquetes eliminados (sentencia DROP) en un periodo de 11 segundos. Además es posible determinar que el tipo de escaneo es sync, ya que en la sección de banderas TCP, la “s” se encuentra habilitada.

2.- Gusanos, mala configuración y otro tipo de malware pueden provocar que se genere una gran cantidad de paquetes en la red, que provocan una degradación en el ancho de banda y en la calidad de los servicios.

En el siguiente ejemplo se observa que el equipo con IP 172.30.19.142 está enviando al equipo local paquetes del protocolo SSDP (puerto 1900) y en tres  segundos generó siete peticiones SSDP (puerto 1900), que son demasiadas. En el resto de la bitácora se manifiesta que esta situación se mantiene, pero no entraré en detalles por falta de espacio. Además, en algunas ocasiones la dirección IP destino es broadcast (255.255.255.255) y en otras multicast (239.255.255.250), lo que constituye otro indicio de actividad sospechosa.

RECEIVE
2013-01-11 13:48:52 DROP UDP 172.30.19.162 255.255.255.255 58867 1211 128 - - - - - - - RECEIVE
2013-01-11 13:48:52 DROP UDP 172.30.19.162 239.255.255.250 1900 1900 543 - - - - - - - RECEIVE
2013-01-11 13:48:52 DROP UDP 172.30.19.162 239.255.255.250 1900 1900 529 - - - - - - - RECEIVE
2013-01-11 13:48:52 DROP UDP 172.30.19.162 239.255.255.250 1900 1900 527 - - - - - - - RECEIVE
2013-01-11 13:48:53 DROP UDP 172.30.19.162 239.255.255.250 1900 1900 463 - - - - - - - RECEIVE
2013-01-11 13:48:53 DROP UDP 172.30.19.162 239.255.255.250 1900 1900 472 - - - - - - - RECEIVE
2013-01-11 13:48:53 DROP UDP 172.30.19.142 239.255.255.250 49933 1900 161 - - - - - - - RECEIVE

Con la información de la bitácora y algunas herramientas de análisis, es posible determinar la fecha y hora del primer y último paquete enviado, así como la suma del tamaño de todos los paquetes, que equivale a la cantidad de ancho de banda consumido. En particular, se determinó que este evento produjo 3,320 paquetes en un periodo de cuatro horas, todos ellos con acción DROP.

En el siguiente artículo explicaré cómo analicé y resolví el ataque DHCP  que mencioné al inicio. También revisaré escenarios avanzados de este ataque, como el uso de técnicas antiforenses, que pueden ser resueltos con el análisis de las bitácoras del firewall de Windows y Linux.

.

[email protected]

.

Referencias:

http://www.youtube.com/watch?v=RMMLYGqRvnU

http://technet.microsoft.com/en-us/library/cc787462(v=ws.10).aspx

http://technet.microsoft.com/en-us/library/cc947815(v=ws.10).aspx

 

[1] Los servidores DHCP rogue son aquellos que por descuido fueron instalados de forma no autorizada, o bien, que están configurados con fines maliciosos con el propósito de realizar ataques informáticos. El impacto en la red de este ataque puede ir desde pérdida de disponibilidad en el servicio hasta pérdida de integridad y confidencialidad de la información http://blogs.technet.com/b/teamdhcp/archive/2009/07/03/rogue-dhcp-server-detection.aspx