Dispositivos IPS vs DDoS de Anonymous

Últimamente los ataques DDoS están ganando cierta importancia en el entorno de seguridad, sobre todo por parte de los ataques que Anonymous lanza contra diferentes compañías u organismos gubernamentales o no gubernamentales. Independientemente de nuestras ideologías o de si estamos a favor o en contra de estos movimientos, nuestro deber como profesionales de seguridad es intentar que la empresa para la que trabajamos no sufra ninguna interrupción en su servicio.

Se me ocurrió escribir este artículo raíz de una experiencia vivida en un cliente con un ataque de denegación de servicio del estilo de los que lanza Anonymous. Después de este ataque pasaron un elenco de comerciales de las diferentes marcas vendiéndonos las excelencias de sus productos y como me pico la curiosidad me puse a investigar que ofrecían los fabricantes para protección contra DDoS. Voy a intentar explicar como se comportan los IPS frente a este tipo de ataques y plantear algunas soluciones.

Para los que no sepáis nada de los ataques que Anonymous suele lanzar, se tratan de unos ataques DDoS mediante un programa llamado LOIC. Para los que no conozcáis LOIC, se trata de un programa para ataques de denegación de servicio, en la que los atacantes se reúnen en un canal IRC, y delegan ciertas partes de la configuración de LOIC al administrador del canal. Cada uno de los usuarios del canal IRC se convierte en un integrante de una botnet. No voy a entrar en detalle, ya que se ha escrito mucho en internet sobre esto. Solo decir que LOIC lo que generan son peticiones HTTP normales, como las que generamos cuando navegamos con cualquier navegador, pero con un volumen de peticiones por segundo importante.

En la práctica…

En una empresa u organismo de considerable tamaño, del tipo de las que Anonymous se fija como objetivo, deberían tener ciertas medidas de seguridad estas suelen ser a grandes rasgos IPS, Firewall y balanceadores. Sobre las labores que suele realizar cada uno se podría hablar largo y tendido, ya que los fabricantes integran de todo en todas partes, no es raro ver un IPS con ACL al mas puro estilo Firewall, y no es raro ver Firewalls con módulos IPS, en cuanto a los firewall de aplicación esto ya si que es un caos, en teoría un SQL Injection y un XSS lo debería parar un IPS, pero los Firewalls de gama alta suelen incluir un modulo de firewall de aplicación por no hablar de los balanceadores, que también suelen incluir protecciones de este tipo.

Aunque no hay un modelo estandarizado de que arquitectura de como se deben colocar los dispositivos en la DMZ, y esto depende de la calidad de estos, y además daría para otro articulo, lo mas aconsejable y lo que recomienda Garner (la gente famosa del cuadrante mágico), es poner IPS->FW->Balanceadores. Hay gente que coloca el IPS detrás del FW, esta solución es igualmente valida, y se suele aplicar cuando los IPS no son de mucha calidad y no pueden analizar mucho volumen de tráfico, y así evitar que analicen el trafico que el FW ya esta bloqueando.

El primer punto que tenemos que tener en cuenta es como detectar este tipo de ataques, teniendo en cuenta que se trata de peticiones HTTP totalmente válidas. Detectarlo no es tarea fácil. Uno de los métodos para detectarlo seria monitorizar el servidor web de alguna forma. O bien porque detectemos una carga inusual de la CPU o porque tengamos monitorizado el numero de peticiones web que se realizan, esto se puede hacer por algun sistema de correlación y sacando los datos del propio log del servidor.

Una vez que habéis detectado un DDoS y trabajáis en una empresa medianamente grande, todos los jefes o altos cargos que tengan nociones de seguridad van a mirar a los IPS. Los IPS, básicamente lo que hacen es buscar paquetes con trazas concretas en el trafico de red. Nos puede servir para detectar cualquier tipo de ataque tipo SQL Injection, XSS.. o también lo podemos usar para mitigar virus como Conficker. Como veis en la imagen anterior de LOIC, en attack options hay una parte que se llama subtittle, si todos la gente que nos está atacando se pusiera de acuerdo en el ataque y pusiese el mismo subtitulo, si que podríamos generar una firma en el IPS para bloquear esas peticiones HTTP, pero si activan la opción de “append random chars to the URL”, pues nos han fastidiado. No hay manera de diferenciar entra peticiones de ataque o peticiones de usuarios lícitos. Lo ideal seria que los IPS nos permitieran contar el número de conexiones, pero la mayoría de los IPS no son capaces de hacer esto. Y además los IPS no se diseñaron para contar conexiones, se diseñaron más para analizar patrones de trafico. Sobre que un IDS/IPS nos permita contar conexiones va a depender del fabricante. De si este a implementado un modulo con ese fin. Lo normal es que no la incluyan, o que no sea muy fiable.

Entrando en materia:

1. Una de las soluciones que proponía uno de los fabricantes que mas me llamó la atención, es usar un correlador de eventos como detector de DDoS y usar el IPS para bloquearlo. Es decir, con un correlador correlas el log del servidor web con una regla para que cuente las conexiones web de las direcciones IP durante un tiempo determinado y cuando una IP exceda ese número de conexiones, el correlador se comunica con el IPS y bloquea esas direcciones IP. Por supuesto el fabricante ya tenia un módulo programado entre su correlador y su IPS. Pero podría ser una idea aplicable a cualquier empresa que tenga un sistema de correlación y un firewall, no seria difícil programar una serie de scripts que introdujeran reglas en el firewall. O delegar esta labor a los operadores de red si es que la empresa dispone de una línea de operación 24h.
2. Otro fabricante proponía otra solución, su producto tenía un sistema o algoritmo de aprendizaje. Con lo que la idea era activar el modo aprendizaje una semana en el que se suponía que el tráfico iba a ser normal, el IPS aprendía ese patrón de tráfico. Una vez realizado el aprendizaje se supone que el IPS podría detectar volúmenes o patrones de tráfico anormales. Esta solución no es especifica para Ataques de tipo Anonymous y me resultaba un poco descabellada. No conozco al detalle como funciona el algoritmo de aprendizaje, pero suponer que una semana, o un mes tras otro, el trafico va a seguir siendo parecido me parece poco sensato, y dependería de a qué se dedica la empresa. Lo cierto es que con reglas así podríamos llegar a bloquear tráfico totalmente lícito y normal, con lo que eso supondría para las empresas.
3. Investigando por la red encontré información de otro fabricante que ofrecía una solución muy parecida al anterior, tenía un sistema heurístico que era capaz de detectar cambios en los patrones del tráfico de red, pero esta vez sin proceso de aprendizaje.
4. Por otro lado, tenemos snort que sí que permite definir una regla de tipo threshold para contar conexiones. Esto es básicamente lo que comentaba al principio: contar las conexiones. Pero tenemos que tener en cuenta que snort es en su origen un IDS, aunque se pueda configurar para que también haga labores de IPS. No he podido comprobar si la versión comercial de este IPS propone la misma solución.
5. Mas tarde y hablando con gente del sector e investigando encontré un aparato que casi sin querer hace justo lo que se necesita para parar este tipo de ataques: se trata de un balanceador de carga web. Como ya sabréis la mayoría, un balanceador de carga web se coloca justo delante de los servidores web y lo que hace es gestionar las conexiones web repartiendo la carga entre varios servidores web. Algunos implementan un módulo para no colapsar esos servidores y lo que hace es muy sencillo: cuando el balanceador ve que el número de conexiones está saturando los servidores web, empieza a bloquear las direcciones IP que mas conexiones esté generando. Esto es justo lo que se necesita para bloquear los ataques de LOIC. Además tiene algo de sentido parar este tipo de ataques con estos aparatos, ya que son los que se encargan de gestionar las conexiones web y LOIC al fin y al cabo genera conexiones legítimas. Pero esto tiene sus inconvenientes; explicar a los altos cargos de la empresa de que disponiendo una infraestructura basada en IPS en Firewall, vas a tener que usar además un balanceador de carga para parar un ataque de DDoS.

La infraestructura normal de una empresa debería ser la siguiente:

Requisitos y Conclusiones:

• Tenemos que tener en cuenta que para parar un ataque de este tipo nuestra infraestructura y ancho de banda debe soportar el volumen de tráfico del ataque, y por infraestructura me refiero a todo aparato por el que vayan a pasar las conexiones.
• Si usamos un balanceador de carga para parar un ataque de este tipo, tienes que explicarle a los peces gordos de la empresa que aun teniendo IPS y Firewalls, vas a parar el ataque justo antes del servidor. Esto es comparable a decirles que vives en una casa con alambrada y puerta blindada, y al final paras a los malos en la puerta de la cocina.
• Debe haber muchas otras soluciones de las cuales yo no tengo noticias, así que os ánimo a que expongáis cualquier otra solución que conozcáis en los comentarios.
• Aunque Snort nos soluciona la papeleta, el que un software de este tipo no tenga un gran fabricante al que echar las culpas cuando falle, suele echar para atrás a las empresas.

---------------

Contribución por Manuel Bermúdez

Leer más...

Construyendo tu Host IPS a medida

Sí, bueno, ya sé que igual es un poco ambicioso el título, pero no sé qué nombre puede encajar mejor para el mecanismo de defensa que os voy a proponer a continuación.

Después de muchos años integrando, configurando y afinando este tipo de dispositivos en diferentes organizaciones, me dí cuenta que los IPS comerciales son capaces de detectar/bloquear un amplio porcentaje de ataques dirigidos hacia las redes internas. Sin embargo, debido a que se basan en ataques que son de "sota, caballo y rey", no resultan efectivos para detectar/bloquear aquellos eventos que para mí son una amenaza, aunque para otros puedan no serlo.

Perl es un lenguaje de programación que personalmente me encanta. Con perl eres capaz de hacer lo mismo que en lenguajes de más bajo nivel, siempre y cuando el rendimiento al milisegundo no sea tan importante, permitiéndote lograr tu cometido en pocas líneas de código, con un nivel de abstracción muy grande. Se pensó inicialmente para el tratamiento de cadenas de texto y ficheros por lo que para lo que pensamos hacer, nos viene como anillo al dedo.

Lo primero que debemos saber, es qué queremos proteger, qué servicios tenemos expuestos al exterior, o son importantes y por ello debemos prestarles nuestra máxima atención. El siguiente paso es conocer la ubicación y la estructura de los diferentes ficheros de log en los que estos servicios registran su actividad.

Utilizaremos el módulo File::Tail de Perl para hacer lo mismo que el comando tail en UNIX. Por cada línea escrita en el fichero, nuestro IPS lo monitorizará y podrá reaccionar según definamos.

Vamos allá con un ejemplo práctico. Supongamos que disponemos de un servidor QMail que requiere autenticación para SMTP. Para nosotros una amenaza ante la que reaccionar podría ser un ataque de fuerza bruta que intente averiguar un par de usuario/contraseña válida. 

El formato de una línea de una autenticación errónea es el siguiente:

Nov  8 11:51:52 s_sys@Carmen vpopmail[18129]: vchkpw-smtp: vpopmail user not found guyt@:123.123.123.123

#!/usr/bin/perl

use File::Tail; #el módulo nombrado
my $tail_file_smtp="/var/log/maillog"; #fichero donde se registra la actividad SMTP
my $puerto_destino_smtp=25; #puerto que queremos proteger

$file_maillog=File::Tail->new(name => $tail_file_smtp, maxinterval=>1); 
while (defined($linea=$file_maillog->read))  #si hay linea nueva en el fichero
        {
                if ($linea=~ m/vchkpw-smtp: vpopmail user not found/) #Si coincide con el patrón que queremos bloquear
                {
                        my @trozos=split (/:/,$linea); 
                        my $ip=$trozos[5]; #La IP atacante. En el ejemplo 123.123.123.123
                        chop ($ip) #Eliminamos el retorno de carro
                        blacklistea ($ip,$puerto_destino_smtp,"correla_smtp vpopmail user not found"); #Reaccionamos
                }
        }

En este caso, la reacción es llamar a una función que se llama blacklistea y que recibe como parámetros la IP atacante, el puerto destino, y una descripción. El contenido de la función blacklistea es bastante más complejo, con comprobaciones varias en base a  llamadas a otras cuantas funciones. Fundamentalmente lo que hace es añadir al IPTables de la máquina una regla que bloquea el acceso al puerto 25 desde la IP considerada como atacante y notificar a quien corresponda que se ha bloqueado esa IP a ese puerto por la razón especificada como "Descripción". Asimismo esa misma información queda reflejada junto con la fecha/hora en una base de datos. Hay otro proceso que cada minuto lee de esa base de datos y, si ha pasado un tiempo especificado desde que se añadió esa IP, quita la regla de bloqueo. Si alguien tiene interés en más detalle, que nos lo indique y se lo enviaré o lo publicaré en una segunda parte.

Al igual que se hace con el fichero /var/log/mailog para ese tipo de ataque, se puede proteger los accesos incorrectos a otros servicios como: FTP, POP3, HTTP, HTTPS, etc,… siendo una defensa reactiva fabricada a medida para ajustarse a nuestros servicios según nuestro criterio, ante lo que es un ataque y lo que no lo es.

Para ampliar la detección y reacción a otros servicios, lo mejor será lanzar un thread por cada uno de ellos, además de una adaptación de GeoIPS, y de una rutina de comprobación de diferentes checks de la máquina. Esto quedará de la siguiente manera en el arranque del programa principal:

#MAIN

.... 

<snip>

.... 

$thr_www = threads->new(\&correla_www); #Comprobaciones para el servidor web
$thr_vpop3s = threads->new(\&correla_vpop3s); #Para Pop3s
$thr_qmail_log = threads->new(\&correla_qmail_log); #Antispam
$thr_smtp = threads->new(\&correla_smtp); #SMTP
$thr_ftp = threads->new(\&correla_ftp); #FTP
$thr_geo_firewall = threads->new(\&geofirewall); #Adaptación propia de GeoIPS

$thr_checks=threads->new(\&do_checks); #Checks varios de carga, espacio en particiones,...

#Bucle infinito
for (;;)
{
        chequea_bloqueadas; #Función que valida si una IP en cuarentena debe ser ya desbloqueada o no
        sleep ($frecuencia_chequeo);
}

Leer más...

Geo IPS 1.0

Una de las cosas que mas me han fascinado en los últimos años, han sido las tecnologías de Geolocalización IP que tan de moda se han puesto.

Y al hilo de esas tecnologías siempre me he preguntado como ningún fabricante de Firewalls ha implementado una evolución de las típicas reglas IP origen / IP destino con reglas basadas en procedencia geográfica.

Por ejemplo, mi servicio de acceso SSH sé positivamente que solo va a ser accedido desde Madrid y en alguna ocasión desde Zaragoza, no necesito conceder acceso a IPs chinas o americanas. Por otra parte, alguien que tenga un negocio online que sirva pedidos a España y Europa, no tiene porque exponer su site web a otros puntos geográficos tan exóticos como Camerún o Hong Kong. Además, es por todos conocido que cuando se publican top-de-países con mas incidencia de ataques, suelen ser siempre los mismos.

Al hilo de esto, he implementado un GeoIPS que extiende las capacidades nativas de Linux en cuanto a filtrado de paquetes permitiendo crear reglas por País o Ciudad. Inicialmente pensé en integrarlo en el kernel como extensión a iptables, pero he preferido hacerlo 'en modo snort' totalmente transparente al sistema operativo para facilitar su portabilidad a otros sistemas (*BSD, OpenSolaris ...) y su mantenimiento (cambios en el kernel, miles de kernels diferentes en función de la distribución ...)

El software se puede descargar del repo en Google de SbD y la guía de instalación está en el Wiki. / Warning / --> No es precisamente sencillo de instalar, se requiere algo de ninjutsu-linux para hacerlo funcionar.

En este post voy a explicar como configurarlo y como es la estructura del fichero de configuración.

El fichero de configuración se llama db.xml y con idea de, en un futuro, desarrollar helpers, está en formato XML.

Fichero de ejemplo:

<config interface="lo" ip="127.0.0.1" blockcommand="iptables -I INPUT  -j DROP -p tcp -s" unblockcommand="iptables -D INPUT  -j DROP  -p tcp -s" blocktime="25">

    <tcp name="53" mode= "deny">

      <country>Spain</country>

      <country>Mexico</country>

       <city>Zaragoza</city>

       <city>Mountain View</city>

    </tcp>

    <udp name="53" mode="deny">

      <country>Spain</country>

      <country>EEUU</country>

    </udp>

  </config>

Viendo la estructura del fichero debería ser fácil imaginar que es cada cosa; la parte inicial define la interface de red sobre la que va a escuchar GeoIPS, la IP que 'va a defender', los comandos de bloqueo y desbloqueo y el tiempo que va a durar bloqueada cada IP. De este punto, tendrás que configurar la interface de red y la IP.

Las siguientes partes son dos ejemplos de reglas geográficas para el puerto TCP/UDP 53.

Tomemos el primer ejemplo:

<tcp name="53" mode= "deny">

      <country>Spain</country>

      <country>Mexico</country>

       <city>Mountain View</city>

    </tcp>

La regla, define que vamos a filtrar el protocolo TCP, el puerto y el modo, en este caso deny. ¿Que significa Deny? Básicamente define que la regla va a permitir TODO el tráfico EXCEPTO el que venga desde Spain / Mexico (como países) y específicamente lo que venga de Mountain View como ciudad.

En contraposición a deny existe la directriz allow y es su opuesta; todo el tráfico que venga a ese puerto que NO pertenezca a Spain / Mexico (como países) o Mountain View como ciudad, será bloqueado.

El formato para puertos udp es idéntico a tcp.

Jugando con las reglas puedes definir cosas como:

'A nivel HTTP, permito todo MENOS lo que venga de Rusia y China'

'Para el ssh, únicamente admito Madrid / Barcelona'

Todo es cuestión de hacerse con la estructura XML del fichero.

Si alguien se anima a probarlo y adaptarlo a otros sistemas no Linux, bienvenidos sean !

Leer más...

Más allá del IPS: WAF (Web Application Firewall)

Muchas han sido las veces en las que en este blog hablamos de lo importante que es la utilización de productos adecuados para cada tipo de amenaza o para cada tipo de elemento a proteger. En general, todo aquello expuesto a Internet se considera en un análisis de riesgos como un potencial alto riesgo. Es el punto de entrada, la puerta de acceso a nuestros sistemas internos y/o de alto valor de nuestra organización.

Si echamos la vista atrás, en los que el mayor mecanismo de seguridad que se utilizaba era el cortafuegos o el antivirus, y los que los implantaban eran innovadores, visionarios, estrategas de la seguridad que protegían sus responsabilidades de las manos y ojos externos. Actualmente, a ningún arquitecto de red se le pasaría por la cabeza no utilizar un cortafuegos para permitir determinado tipo de tráfico y bloquear el resto; lo mismo pasaría al instalar un PC y no pensar en ponerle un antivirus. Los tiempos han ido evolucionando y los sistemas de detección de intrusos o IDS han ido dando paso a sistemas inline IPS que previenen además de detectar ante determinado tipo de ataques como hacen únicamente los IDS (en SbD ya aclaramos las diferencias).

El siguiente paso en la protección, y dado que lo que toda organización posee es una puerta de entrada en modo de servidor web, es la de un mecanismo específico para la protección de las aplicaciones web. Hace poco se ha publicado que Akamai ofrece en su cartera de servicios el plus de seguridad de aplicaciones web para sus clientes mediante la utilización de WAF. En general, empresas punteras como Akamai, son los early adopters de este tipo de tecnología. Llegará un momento en el cual no se nos pasará por la cabeza publicar contenidos web a Internet sin la protección específica para los mismas.

Lo que es evidente es que la mejor de las soluciones en un mundo idílico es tener un código de aplicaciones perfecto, sobre servidores con sistemas operativos sin fallos, con un bastionado inmutable y con una configuración exquisita. Como eso no va a pasar en un porcentaje mayor al 1% de las organizaciones existentes, una posible solución para proteger nuestros assets, es añadir una capa previa de mecanismos que sí que evitan los problemas causados por las deficiciencias en la configuración y en la programación de los sistemas: Los IPS y los WAF.

Ambas herramientas, al contrario de lo que mucha gente piensa, no son mutuamente excluyentes, sino complementarias.

Fundamentalmente, el IPS es una herramienta de protección de propósito general (protege ante ataques de todo tipo de protocolos), generalmente basados en firmas, violaciones de protocolo, e incluso algunos hasta incorporan mecanismos de análisis estadístico para analizar fluctuaciones de tráfico y "costumbres" propias de cada organización para responder ante cambios.

El WAF sin embargo, de los que hemos hablado largo y tendido en SbD, únicamente está centrado en protección de tráfico web. Muchos de ellos trabajan comprobando firmas de ataques web conocidos también, pero su misión principal es entender el funcionamiento de ataques como Inyecciones SQL, XSS, manipulación de parámetros, cabeceras, cookies, XML, Javascript, etc,... analizando más allá de los simples paquetes, teniendo en cuenta el comportamiento del usuario y manteniendo las sesiones de los mismos.

Un IPS es capaz de proteger ante determinado tipo de ataques para aplicaciones web; sin embargo el WAF, al ser una herramienta especializada, permite un mayor control para web exclusivamente, llegando donde el IPS no llega, incluso para el tráfico HTTPS (en configuraciones especiales), para aplicaciones web "hechas en la casa" (para las que el IPS no tiene firmas específicas y lo pueda generar falsos positivos). En general los WAF suelen estar basados en proxies inversos para recibir las peticiones web completas, encargándose ellos de efectuar las peticiones a los servidores web finales. En el caso de los IPS, suelen analizar los paquetes enrrutando únicamente hacia donde corresponda aquellos que no sean considerados como ataques. En esta línea algunos IPS son susceptibles en cierto modo de ser evadidos mediante ataques de fragmentación, al no analizar sesiones completas, cosa que en el caso del WAF, si se puede hacer, es más complicado.

Si fuéramos médicos, diríamos que el IPS es al ibuprofeno en pastillas lo que el WAF es a una inyección anti-inflamatoria o una infiltración en el punto adecuado de dolor. Esto no implica que ambas soluciones sean incompatibles en una misma arquitectura, sino altamente recomendables para entornos en los que hay diversos servicios a proteger, y en los que la web tiene una alta cohesión con el resto de los sistemas suponiendo una bonita autopista hacia nuestros datos para curiosos y ladrones.

Leer más...

Como protegerte de buffer overflows, format strings y similares

A estas alturas de la película, casi todo el mundo conoce ya lo que es un buffer overflow o, cuanto menos, lo asocia a técnica-para-explotar-vulnerabilidades. Tal vez sea la forma mas común o la mas ampliamente explotada a lo largo de los años para sacar partido a vulnerabilidades. No obstante, existen otro tipo de vulnerabilidades que se pueden explotar con otras técnicas que igualmente son un serio problema a la hora de defender un sistema.

No voy a entrar en detalle sobre descripciones técnicas de estas vulnerabilidades ya que existe abundante material en Internet sobre los pormenores de porque se produce un buffer overflow, format string y similares.

Lo que hoy voy a presentar es una herramienta que incorpora protección contra ese tipo de ataques en sistemas Windows. Su nombre: WehnTrust

WehnTrust es una herramienta gratuita destinada a sistemas Windows XP / 2000 y 2003 que incorpora una serie de protecciones para tratar de anular los efectos de un exploit contra el sistema operativo.

Su funcionamiento está basado en el trabajo que realizó la gente de Pax para el kernel de Linux (muchos conocerán el famoso parche Grsecurity) portando a Windows, entre otras, la tecnica ASLR (Address Space Layout Randomization)

Pero no todo es gratis, claro. El coste directo de este tipo de parches es una penalización relativamente perceptible en el rendimiento del sistema, indirectamente existe la probabilidad de que algunos programas no sean muy amistosos con este tipo de modificaciones en la ejecución normal y empiecen a dar misteriosos cuelgues. Incluso cabe la posibilidad de que el sistema se vuelva inestable ya que este tipo de soluciones se meten muy profundamente en las entrañas del sistema y al no ser un software probado y ultra-testado por Microsoft no lo podemos denominar estable.

WehnTrust, una vez instalado en el sistema, se lanza automáticamente al arrancar Windows y tiene como interface de administración un tray en la barra de tareas. Si lo lanzamos, podemos ver un breve resumen del funcionamiento de la herramienta donde, entre otras cosas, podremos ver el numero de intentos de 'explotacion' que ha detectado y bloqueado.


En caso de que algún programa se declare rebelde a ser ejecutado bajo las protecciones de la herramienta, podemos añadir una excepción decidiendo que programa va a ejecutarse 'sin protección' y que tipo de protección deseamos deshabilitar



En definitiva WehnTrust es una muy interesante herramienta bastante recomendable en entornos donde la exposición del PC le haga susceptible de ataques en forma de exploits.

Leer más...

Sacándole el jugo a los IDS/IPS (II) - Configuración y afinamiento

En posts anteriores explicamos cómo llevar a cabo un despliegue de sondas IDS/IPS de la forma más óptima posible. Como lo prometido es deuda, en este post detallaremos cómo conviene configurar dichos elementos para que la información generada en forma de eventos de seguridad sea aprovechada por los Departamentos de Seguridad de las organizaciones.

La colección de dispositivos IPS/IDS con la que sembramos nuestra arquitectura de red anteriormente son capaces de enviar alarmas en caso de detectar/bloquear tráfico malicioso. En el momento de la configuración de dichos dispositivos (que traen una base de firmas genérica) se suele poner a registrar toda la actividad de la red durante un tiempo suficiente para obtener una muestra de suficiente calidad (generalmente una semana, aunque este tiempo puede variar). Esto se hace con el fin de evaluar los diferentes eventos detectados por las sondas IDS/IPS. A partir de aquí surgen dos posibles filosofías de afinamiento:

• La primera sugiere afinar la política de alertas de red eliminando todos los falsos positivos, y eventos de severidad baja, de manera que solamente genere alertas en caso de ataques que puedan suponer un impacto importante para la organización. Esta filosofía también es conocida como “anomaly detection”. Así los operadores que reciban las alertas deberán poner en marcha un plan de contingencia para mantener el ataque bajo control.
• La otra posible forma de configurar los IDS/IPS es afinar únicamente los falsos positivos y dejar todos los demás eventos activos, de manera que en caso de una intrusión, a la hora de realizar un análisis forense, contar con mucha más información para poder analizar los prolegómenos del ataque.
  

Ambas filosofías son muy opuestas en cuanto a la funcionalidad práctica (la segunda se hace ingestionable por recursos limitados en redes con mucha actividad), el mantenimiento y los costes de almacenamiento (a mayor verbosidad en el registro de eventos mayores necesidades de espacio en disco y mayor frecuencia de rotado de logs para poder manejar la información). Sin embargo la segunda posee como única ventaja el poder contar con un nivel de detalle excelente en casos post-mortem.

Según el ejemplo con el que contábamos en el posts anterior, teniendo mecanismos diferentes de IDS y de IPS, mi experiencia en estas lides me hace recomendar configurar los IPS de forma abnomally detection y los IDS en modo logging completo. De esta manera los IPS no tendrán que analizar una base de datos de ataques tan grande, priorizando también el rendimiento de los mismos, y los IDS guardarán datos de toda la actividad de red con un primer nivel de filtrado (por los IPS en caso de tráfico entrante/saliente).

En la siguiente entrega, aprovecharé para introducir un "juguete" nuevo en la infraestructura de seguridad de la compañía: los centralizadores/correladores de eventos.

Leer más...

Sacándole el jugo a los IDS/IPS

Conocidos como mecanismos de detección o prevención de intrusiones, los IDS/IPS se han convertido en un "must" en el SIMO de dispositivos que han de tener las organizaciones como mecanismos de seguridad en su infraestructura.

Dependerá del uso que se les vaya dando a estos dispositivos, que se conviertan en herramientas útiles que aporten valor en el proceso de la seguridad de las organizaciones, o se conviertan en unos "cacharros" más, cuyo mantenimiento engrose la lista de tareas de los administradores. Ya que todos los dispositivos que forman parte del stuff de una compañía requieren un mantenimiento (backups, actualizaciones, parches, licencias,...) por lo menos vamos a dar las pautas para que la utilización de sondas de detección/prevención de intrusiones puedan resultar útiles en su funcionalidad.

Antes que nada, quiero dejar claro que las sondas IDS son dispositivos que se posicionan offline del flujo de las redes, de manera que reciben una copia del tráfico de cada VLAN (mediante la utilización de TAPs físicos o con la creación de un port mirroring o port span de una VLAN de un switch capaz de hacerlo). Por un interfaz sin pila TCP/IP reciben el tráfico en formato RAW y lo analizan enfrentándolo contra una base de datos de firmas de ataques conocidos, de manera que, a través de otro interfaz, cuando detectan tráfico malicioso, envían señales de alarmas a una base de datos centralizada. Estos dispositivos solamente son capaces de detectar tráfico y, en ciertas ocasiones, pueden llevar a cabo reacciones activas que eviten males mayores en la infraestructura de producción. En este caso nos referimos a IDS de red, puesto que existen (o existieron hace unos cuantos años) los llamados IDS de host. Estos eran agentes software que se instalaban de forma directa en cada uno de los servidores a monitorizar y que enviaban alertas sobre ataques contra los mismos.

Los IPS sin embargo, funcionan de una forma diferente, puesto que se emplazan en modo inline entre las diferentes redes, de modo que el tráfico que pasa hacia y desde una red los ha de atravesar, pudiendo discriminar si el tráfico es malicioso o no. Al encontrarse en modo transparente e inline, este tipo de dispositivo sí que es capaz de bloquear todo tipo de tráfico que se considere un ataque. En líneas generales (aunque los IPS han evolucionado mucho), el funcionamiento principal de los IPS a la hora de identificar ataques es idéntico al de los IDS. Se basan en firmas de ataques conocidos y envían por un tercer interfaz las alertas a una base de datos centralizada.

Como diferencias principales entre ambos, aparte de las ya comentadas referidas a la capacidad de detectar únicamente o de bloquear los ataques, es la cantidad de tráfico a monitorizar por parte de ambos. En el caso de los IPS, sólo son capaces de identificar ataques dentro del tráfico que los atraviesa en ambos sentidos. Sin embargo, los IDS de red van más allá, puesto que al analizar el tráfico de una VLAN completa, es capaz de clasificar ataques entre máquinas de la VLAN, no sólo la que pasa de una red a otra.

Inicialmente, todo despliegue de una plataforma de sondas IDS/IPS, cómo si del apostamiento de francotiradores se hablase, requiere planificar con cierta inteligencia.

Como tónica habitual en la gestión de proyectos de este tipo lo que manda principalmente es el presupuesto asignado para invertir en el análisis de la seguridad de las redes.

Suponiendo que disponemos de algo de presupuesto para equipos con licencias comerciales, mi recomendación sería diversificar entre software comercial y software libre. Si bien como iniciativas libres disponemos del ultraconocido Snort (que puede funcionar como IDS y como IPS inline). Como soluciones comerciales más recomendables podemos contar con ISS (adquirida por IBM), Tipping Point (adquirida por 3Com), McAfee Intrushield (solución IPS basada en ASIC), Sourcefire (spin-off comercial de Snort que se integra sobre máquinas Nokia, aparte de sus propios appliances),...

No obstante, y dependiendo en mayor medida de si se tiene proyectado efectuar cambios en la estructura de cortafuegos de red principales, existen los llamados UTMs (Unified Threat Management) o MFA (Multi Functional Appliances) que son en realidad cajas que aunan las funcionalidades de cortafuegos de red, gestor de túneles VPN, antivirus, proxy, gestor de contenidos e IDS/IPS (dependiendo si solo registran las alarmas detectadas o si bloquean los ataques), entre otros... por lo que no es nada desechable la idea de implantar como pilar central de la seguridad un dispositivo de estas características que sea capaz de detectar y bloquear los ataques que lo atraviesen en dirección desde/hasta cualquiera de las redes que delimitan. Por poner ejemplos de fabricantes de dispositivos comerciales UTM, podríamos indicar: Fortinet, Juniper, NetASQ, Checkpoint, Radware,... De esta manera es posible evitar la inclusión de dispositivos IPS puros en los segmentos más importantes de la red. Huelga decir que si tenemos presupuesto ilimitado para llevarlo a cabo, lo más recomendable es situar elementos de diferentes fabricantes por lo que utilizar uno o varios UTM con la función de IPS activa para separar diferentes redes, y además la inclusión de IPS puros en los segmentos de red que necesitemos.

Supongamos que no contaremos con un dispositivo de estas características como eje central distribuidor de las redes principales de nuestra organización. Lo más normal en estos casos es dimensionar la cantidad de sondas a desplegar en caso de los IDS. Si contamos con instalar Snort como IDS (opción recomendada por ser gratuito y de gran calidad), de manera que podemos darnos el lujo de tener una sonda por cada red que posea la organización. En caso de tener limitación en el número de sondas por el coste del hardware, habremos de priorizar sobre las redes en las que tengamos elementos más críticos para nuestro negocio. Se suelen seguir criterios como "la red con más servicios expuestos a Internet" o "la red donde más información confidencial haya".

En cuanto al despliegue de IPS, supongamos que hemos destinado el grueso del presupuesto del proyecto a comprar equipos comerciales IPS. Lo más recomendable es situar un dispositivo (o clústers en alta disponibilidad si el presupuesto lo permite) justo en el punto de acceso a la red (puede ser en la salida/entrada de cada interfaz del firewall que delimita esa red).

Con esta disposición lograremos tener monitorizado el tráfico que entra a cada una de las redes que separa el firewall principal (y bloquearlo con los UTM o los IPS) y el tráfico que se intercambian las máquinas de cada red entre ellas (mediante el análisis del tráfico interno entre máquinas de un mismo segmento), pudiendo detectar actividad vírica que pudiera dejar fuera de combate una VLAN completa.

En posteriores entregas intentaré detallar lo mejor posible cómo configurar los diferentes elementos de seguridad que hemos incluido en nuestra arquitectura de red.

Leer más...