Seguridad en Redes   

Javier lerdo, Security Consulting Systems, Engineer. CISCO México
InTech México Automatización, 
Edición Abril  – Julio 2012. 

Cuando se habla de seguridad, el 99 por ciento de las veces se refiere a firewalls e  IPSs (Intrusion Prevention System). Ambos dispositivos son fundamentales en cualquier esquema de defensa, pero como veremos, han quedado superados por los avances en los mecanismos ofensivos.

INTRODUCCIÓN

No quiero que se entienda mal; ambas tecnologías (firewalls e IPSs) siguen siendo igual e incluso mucho más necesarias que en el pasado, pero, y he aquí la paradoja, están lejos de ser suficientes ante los escenarios de riesgo sobre los cuales tiene que operar una infraestructura tradicional de Tecnologías de la Información (TI).

Si ustedes hacían seguridad hace diez o más años, no me dejarán mentir cuando digo que en esa época el atacante tenía que hacer la inversión de tiempo, intelectual e incluso económica para encontrar un servicio vulnerable que, expuesto a sus herramientas, terminaba siendo explotado. A este esquema le llamo el modelo de “Push”: el atacante inicia proactivamente el ataque y si encuentra una vulnerabilidad la explota “empujando” el malware hacía el dispositivo vulnerable.

Desde hace ya varios años este modelo ha cambiado. Generalmente, en ataques oportunistas el atacante compromete un servicio que es muy utilizado por una comunidad de usuarios, “apostando” a que un número considerable de ellos lo utiliza a través de herramientas vulnerables.

El ejemplo más claro de esto es la relación navegador/ servicio-web. En este escenario el atacante compromete un servidor web, por ejemplo la intranet de una organización, y hospeda ahí el malware. Una vez que es descargado por un navegador vulnerable se ejecuta en el dispositivo del usuario. A este modelo lo llamo “Pull” de distribución de malware. Literalmente son los usuarios que al utilizar servicios comprometidos “jalan” o traen el malware hacia una organización.

En este escenario, el firewall resulta completamente rebasado, ya que el malware se descarga utilizando los puertos que han sido permitidos por el mismo dispositivo en primer lugar. Lo mismo ocurre con un IPS debido a que en este escenario nada impide que la descarga del malware se dé a través de un canal encriptado utilizando HTTPS por ejemplo- , haciendo que la descarga del malware sea completamente opaca para dispositivos como IPSs o analizadores de protocolos.

Si el firewall e IPS tradicional no pueden detectar y contener este tipo de escenarios, ¿qué opciones quedan? Antes de responder a esta pregunta quiero hablar de Netlflow, una tecnología desarrollada por Cisco hace muchos años. El objetivo de Netflow es crear un registro de cada flujo que transita por un ruteador (y algunos tipos de switches). La creación de estos registros es muy útil, por ejemplo para saber qué dispositivos finales son los que más tráfico están generando o qué protocolos son los que más transitan en un enlace. Esta información puede ser utilizada para hacer capacity management y poder predecir el momento en que se tienen que actualizar los enlaces, o para billing y facturar de acuerdo al tráfico generado por cada uno de los participantes.

Para Netflow, un flujo es el conjunto de todos los paquetes que comparten ciertas características en común y dependiendo de la versión con la que se esté trabajando estas cualidades son fijas (i.e. Netflow v5) o pueden ser definidas por el usuario (i.e. Netflow v9).

En la versión 5 por ejemplo, son parte de un mismo flujo todos los paquetes cuya dirección IP origen y destino sea la misma, cuyos puertos UDP o TCP sean los mismos, el tipo de protocolo (i.e. IP) sea el mismo, el tipo de servicio sea el mismo y la intedace de entrada sea la misma.

Pueden existir flujos de un sólo paquete o haber flujos de miles de millones de paquetes. Lo importante es que todo paquete que transita a través de la red es parte de un flujo: uno existente o uno que recién se esté creando. Es como caminar por la playa, no importa la dirección en que caminemos, nuestras huellas quedan en la arena. Lo mismo ocurre con un paquete de red, pues no importa de donde venga o hacia donde vaya, su paso por la red queda registrado por Netflow.

Previamente describimos algunas de las funcionalidades de Netflow en el ámbito de operación de redes (capacity management y billing) pero este sistema también tiene un uso importantísimo en seguridad.

Espero que estén de acuerdo conmigo cuando digo que un controlador de dominio (DC) es la columna vertebral de toda arquitectura de autenticación, autorización e incluso auditoría en una organización que tiene implementado Active Directory de Microsoft. Veamos algunos ejemplos:

Siendo un DC tan importante dentro de una organización, si este dispositivo tiene flujos a direcciones IPs que no reconocemos como propias de la organización ¿significaría esto que el DC tiene instalado malware que está tratando de “llamar a casa”?, ¿significa que el administrador del DC está en la consola navegando?, ¿significa que tiene un anti-virus que está tratando de actualizarse? Netflow nos dice que algo “anormal” está ocurriendo y es nuestra responsabilidad como encargados de seguridad activar los mecanismos de respuesta a incidentes, para entender el origen y el impacto de esta “anormalidad”.

Si de un día a otro, cien máquinas de una sucursal remota comienzan a generar flujos UDP/TCP al puerto 53 (tráfico DNS) a servidores que nosotros no reconocemos como DNS, que son administrados por nuestras propias áreas de TI, ¿significa que esas 100 máquinas fueron comprometidas y están utilizando un servidor DNS bajo el control del atacante?, ¿significa que en esas 100 máquinas se instaló una nueva aplicación y esto provocó el cambio en la configuración de DNS?, ¿significa que existe un nuevo servidor DNS atendiendo a la organización y no hemos sido notificados?

Por último, si de la noche a la mañana un dispositivo empieza a generar una cantidad muy superior de flujos (100 por ciento más a los que normalmente genera). ¿Significa que alguien está utilizando el dispositivo para escanear la red?, ¿significa que la máquina está infectada y el malware está intentando reproducirse?, ¿es una máquina que está siendo utilizada en una campaña de ataque de negación de servicio?

Netflow no nos da las respuestas a todas estas preguntas, pero importantísimo, nos dice que algo que no es normal está ocurriendo. Muchas veces estas “anormalidades” son el resultado de la ejecución de malware dentro de una organización o son las huellas que deja un atacante al momento de tratar de comprometer la infraestructura. Netflow nos da visibilidad, que es fundamental para poder controlar y administrar.

Activar Netflow en la red es uno de los primeros pasos que hay que seguir para instrumentar la infraestructura y que sea la propia red como un todo, no como dispositivos individuales, la que nos dé la inteligencia necesaria para poder reaccionar ante un incidente.

En artículos posteriores, seguiremos hablando de otras funcionalidades, que aun cuando no son consideradas tradicionalmente como herramientas de seguridad, bajo los escenarios de ataques que se presentan en la actualidad son fundamentales para desplegar una estrategia sólida de defensa en cualquier infraestructura de TI.

0
Compartir:

Dejar un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.