miércoles, mayo 31, 2006

Introducción al análisis de protocolo con ethereal I

Todo administrador de red o seguridad, tarde o temprano se ve obligado a enfrentar algún problema que lo obligue a analizar qué está sucediendo en su red en el nivel más bajo que pueda. En este primer artículo intento dar una introducción al análisis de protocolo y cómo este nos puede servir para: solucionar problemas, analizar el desempeño de las redes, desarrollar software y protocolos.
Nota: Los analizadores de protocolo también son llamados analizadores de paquetes, "packet sniffer" o simplemente sniffer (del inglés "olfateador").


Motivación

Ampliemos un poco lo que nos motiva al análisis de tráfico con un analizador de protocolos:
  • Los datos viajan por la red como un flujo frenético de ceros y unos, los cuales son ilegibles para los humanos, es preciso convertir los paquetes de datos binarios a un formato legible.
  • Solucionar problemas de red o analizar el rendimiento de la red para descubrir cuellos de botella, etc.
  • Detectar intrusos en la red, máquinas infectadas con virus, ataques de denegación de servicios (DoS), spyware , etc.
  • Recolectar evidencia para análisis forense.
  • Comprobar el cumplimiento de las políticas de uso de la red.
  • Como herramienta educativa para enseñar/aprender sobre el funcionamiento de los protocolos.
  • Para realizar ingeniera inversa sobre aplicaciones/protocolos.


Ethereal

Como mencioné en el título, utilizaremos Ethereal para el análisis de protocolo, esto se debe a que Ethereal no tiene nada que envidiarle a otras alternativas propietarias, además es GPL y me encanta.

De Wikipedia:
Ethereal es un analizador de protocolos, utilizado para realizar análisis y solucionar problemas en redes de comunicaciones, para desarrollo de software y protocolos, y como una herramienta didáctica para educación. Cuenta con todas las características estándar de un analizador de protocolos.
La funcionalidad que provee es similar a la de tcpdump, pero añade una interfaz gráfica y muchas opciones de organización y filtrado de información. Así, permite ver todo el tráfico que pasa a través de una red (usualmente una red Ethernet, aunque soporta algunas otras) estableciendo la configuración en modo promiscuo.

Aspectos importantes de Ethereal:

  • Es mantenido bajo la Licencia GPL.
  • Trabaja tanto en modo promiscuo como en modo no promiscuo.
  • Puede capturar datos de la red o leer datos almacenados en un archivo (de una captura previa).
  • Tiene una interfaz muy flexible.
  • Capacidades de filtrado muy ricas.
  • Soporta el formato estándar de archivos tcpdump.
  • Reconstrucción de sesiones TCP.
  • Se ejecuta en más de 20 plataformas (Linux, Windows, *BSD, Mac OS X, Solaris, etc.).
  • Soporta más de 480 protocolos.Puede leer archivos de captura de más de 20 productos.


Obtener Ethereal

Para poder correr Ethereal debemos instalar tanto el Ethereal como la librería libpcap en un sistema que soporte ambos. Para descargar el Ethereal visitá: www.ethereal.com/download.html
En windows se necesita la librería WinPCap, la cual actualmente viene incluida en el instalador.
También es conveniente bajar el manual de usuario, este se encuentra en www.ethereal.com/docs/#resource. Los capítulos más importantes para comenzar son el 1,3,4 y 6.
Recién lo has instalado, lo has podido correr, quieres ver algo interesante, pero por tu red no pasa nada!!! (o tal vez todavía no te atreves a poner en promiscuo tu "inmaculada" placa de red), entonces puede que te interesen las decenas de capturas de ejemplo que hay en el wiki del proyecto, la dirección es wiki.ethereal.com/SampleCaptures. En el próximo artículo tal vez analicemos algunos de ellos.


Alimentando la bestia

En este punto ya deberíamos tener instalado y corriendo el Ethereal, ahora nos toca analizar cómo hacemos para alimentar el Ethereal con tráfico.


En las viejas redes con topología de bus lineal (coaxil y HUBs)

En las ahora viejas redes con cable coaxil o las redes armadas usando Hubs, o sea redes de topología de bus lineal, todos los paquetes (más propio sería cuadros o frames, ya que estamos hablando de la capa 2 del modelo OSI) son escuchados por todos los host conectados al segmento. En esta topología un host envía los frames recibidos a las capas superiores para ser procesado sólo si la dirección de destino es una dirección de broadcast o si es la suya, por esto basta con poner la interface de red (la NIC - Network Interface Card) de la máquina sobre la cual realizaremos el monitoreo en modo promiscuo, para obtener todo el tráfico de la red.
Es muy difícil (por suerte) encontrar redes, que todavía tengan esta topología, o por lo menos, que toda este implementada como un solo segmento.


En las redes actuales con topología en estrella (todos los host conectados a switchs)

Si cada host está conectado a un puerto en un switch, se dice que hay microsegmentación, lo cual hace que a cada host sólo le llegue tráfico de unicast destinado a él o el broadcast/multicast, y no tráfico unicast de otros; esto hace algo más difícil obtener muestras de tráfico para ser analizadas.
Evaluemos las alterativas que tenemos para hacernos con una muestra:

SPAN - Switch Port Analysis (también llamado Port Mirroring)La mayor parte de los switch con administración, de gama media o superior, tienen la posibilidad de "reflejar" el tráfico (entrante y/o saliente) de uno o más puertos en un puerto que se designa para monitoreo. Esta es probablemente la alternativa más cómoda, ya que sólo requiere una simple configuración y conectar nuestra máquina en un puerto particular para estar obteniendo el tráfico de los puertos que nos interesan. Pero no todos los switchs tienen esta característica, que además requiere un puerto libre y genera carga sobre el equipo, si llega al punto de sobrecarga del switch ocasionará que no nos copie todo el tráfico (en el mejor de los casos).
Enlace de interes: Configuring the Catalyst Switched Port Analyzer (SPAN) Feature

Ethernet Tap (o EtherTap, "Test Access Port")Los Ethernet Tap son dispositivos de capa física (nivel 1 del modelo OSI) que permiten examinar el tráfico de red de manera similar a SPAN (sin intervenir en el flujo de datos) y al ser dispositivos dedicados no tienen impacto en el rendimiento de la red.Existen dos tipos:

Pasivos - Estos son los baratos e incluso son fáciles de construir, básicamente consisten de 4 jacks RJ45, dos son utilizados para que pasen las señales de forma directa, y los otros 2 son conectados cada uno por separado a las líneas de tx de uno y otro extremos. (Creo que se entiende más en el diagrama que hay a continuación )La principal desventaja de los taps pasivos es que se necesitan 2 interfaces (NICs) para poder analizar todo el tráfico. En el sitio de snort hay una guía que explica cómo armar un tap pasivo casero: www.snort.org/docs/tap (en las referencias dejo un link a un paper excelente acerca de este tema y en castellano!) .
Nota: una forma de eliminar la necesidad de 2 interfaces con el tap pasivo es conectar las bocas de monitoreo y el analizador a un hub; pero con mucho tráfico se pueden generar demasiadas pérdidas debido a las colisiones propias del funcionamiento de los hubs, lo que entorpece el análisis. Desde ya no recomiendo agregar un hub si pensamos utilizar el tap para alimentar un IDS.

Activos - Los Taps activos siguen siendo de capa física (1) pero tienen algo de electrónica, esta electrónica puede dar 2 funcionalidades (no excluyentes):
  • Agregación: Combinar el tráfico en cada sentido, esto elimina la necesidad de 2 interfaces en el analizador.
  • Regeneración: Copiar el tráfico en más de un tap, esto permite copiar el tráfico a más de un dispositivo; por ejemplo: permitiría conectar a un tap un IDS y a otro un analizador de protocolo.
La principal desventaja que le encuentro a los taps es que (dependiendo de la topología) pueden agregar un punto único de falla y la otra posible desventaja es que mal construido puede degradar la transmisión de las señales.

Instalar Ethereal/Tcpdump en el host - Si estamos analizando problemas con un host en particular y tenemos la administración del mismo, tenemos como alternativa obtener capturas de tráfico instalando Ethereal, Tcpdump o algún analizador que pueda exportar a un formato compatible en el mismo host.

Última alternativa: Interponer un hub entre los segmentos que queremos analizar y conectar el analizador a éste, debido a cómo funciona el hub seremos capaces de escuchar todo el tráfico (los hubs retransmiten las señales recibidas en una boca a todas las restantes); la desventaja de esta alternativa es que surgen colisiones, las cuales afectan el tráfico que transita por la red, no sólo el tráfico copiado al analizador.

Una consideración importante a la hora de elegir alguna de las opciones anteriores, más allá del costo de cada una, debe ser que el hecho de analizar el tráfico debe alterar lo menos posible el funcionamiento de la red. Si estamos tratando de determinar el por qué del mal funcionamiento de la red, el hecho de empezar a analizar el tráfico no debe entorpecer la actividad tanto como para que ya no se pueda determinar si la causa es un problema en la red, o si lo que hicimos para analizar el tráfico enmascaró otros problemas .
Lamentablemente por el principio de incertidumbre, se sabe que es imposible observar un fenómeno sin alterarlo.

Bueno creo que es suficiente para un primer artículo. En el siguiente, hablaré de la interfaz de Ethereal y analizaré algunas muestras de ejemplo de problemas habituales.
Hasta la próxima!


Referencias

sábado, mayo 06, 2006

Security Information Managment

(Gestión y correlación de los eventos de seguridad)

Desde hace algún tiempo toda red de mediana envergadura se ha visto en la necesidad de instalar, no uno, sino varios productos de seguridad, como: Firewalls (de borde y/o host), IDS/IPS (de red y/o host), VPNs, los clásicos Antivirus, etc.
Esto le ha causado al personal de seguridad (si es que la organización tiene personal dedicado solamente a la tarea de mantener la seguridad) un terrible problema, y este problema consiste básicamente en que cada uno de estos productos genera un increíble volumen de eventos de seguridad; según datos del instituto SANS, un IDS en una red de gran tráfico puede producir de 2, a más de 50 millones de eventos por día. La otra arista de este problema reside en la poca fiabilidad de estos eventos, normalmente la mayoría de las alertas corresponden a ataques que no logran comprometer la red.
En otras palabras, tenemos demasiadas alertas y estas no son fiables, obtenemos demasiados falsos positivos. Asimismo, la información es muy detallada, pero atómica, parcial y sin capacidad de abstracción; no somos capaces de detectar ataques definidos por comportamientos más complejos, nuestro segundo problema son los falsos negativos.
Para dar respuesta al problema antes descripto han surgido los SIMs (Security Information Managment). Un SIM es un sistema que de forma centralizada colecta, normaliza, relaciona/correlaciona y prioriza los eventos de seguridad. Estos presentan los datos de seguridad de manera tal que puedan ser "digeridos" por el personal de seguridad. Su propósito es aumentar la eficiencia y la eficacia, pero además dar una vista global del estado general de seguridad, un excelente punto de partida para analizar el estado de la red, que antes no existía.
Junto con ellos ha surgido un nuevo tipo de proveedor de servicios, los MSSPs "Managed Security Service Providers", pero no hablaremos de ellos en este artículo, y menos de si se puede confiar en terceros para administrar la seguridad de nuestra red.
Diagrama simplificado del sistema:


Los SIMs propietarios no son productos baratos, su precio puede variar desde 50.000 a 200.000 dólares. Esto puede parecer una cantidad exorbitante, pero mantener el mismo nivel de seguridad sin disponer de esta herramienta, implicaría por los menos disponer del doble de personal en seguridad, dedicado a la sola tarea de chequear los eventos de seguridad, y de todas formas puede ser que se nos escapen cosas. Además con lo difícil que es conseguir profesionales en seguridad, es un desperdicio asignarlos a filtrar eventos poco relevantes.
Debido a su costo es necesario evaluar muy bien las alternativas existentes antes de elegir un producto. Las siguientes son algunas características que a mi juicio debe cumplir o tener un SIM:

• Colectar y normalizar (traducir los eventos a un formato estándar) las alarmas de un gran número de dispositivos (Firewalls, IDS, VPNs, Databases, WebServers, etc.), o al menos de los que se tiene instalados en la actualidad.
• Posibilitar el desarrollo de agentes, a través de algún lenguaje de scripting, para dar soporte a sistemas de seguridad no soportados.
• Disponer de un formato sencillo para agregar reglas de correlación.
• Correlacionar los eventos de seguridad en tiempo real.
• Disponer de un inventario con información de los dispositivos de red, servidores, pc de escritorio, relevancia de los dispositivos, ubicación, etc. Además debe utilizar esta información para priorizar las alertas.
• Generar reportes (y muchos), los cuales deben ser muy personalizables y el trabajo con ellos también debe ser sencillo.


Estas son sólo algunas características importantes, les recomiendo leer "Keys to implementing a Successful Security Information Management Solution" del instituto SANS.
Algunos desarrolladores de SIMs propietarios son: OpenService, netForensics, Intellitactics, ArcSight, Network Intelligence, Cisco (Cisco Works SIM y MARS), Computer Associates, IBM (Tivoli), Symantec (SESA) y NetIQ


Alternativas en Software Libre
Dos proyectos de software libre que implementan un sistema SIM son OSSIM y Prelude, ambos con un grado importante de desarrollo.

OSSIM
"Open Source Security Information Management"

Es una herramienta para monitorear la seguridad de una red. Actualmente integra 22 aplicaciones de seguridad y crea una consola de seguridad distribuida. Es la primera consola de seguridad Open Source y probablemente la más usada. Es utilizada por empresas desde Sudáfrica a Singapur, incluidas corporaciones y bancos españoles, entre ellos Telefónica Empresas de España, para su solución de “Seguridad Co-Gerenciada” (http://ossim.itdeusto.com/case.htm).
Su objetivo es ofrecer un marco para centralizar, organizar y mejorar las capacidades de detección y visibilidad en la monitorización de eventos de seguridad de la organización. OSSIM pone a trabajar juntas estas aplicaciones de seguridad, haciendo correlación, priorización y agregación de la información que generan, para hacer valoraciones sobre el estado de la red o buscar patrones que sirvan para detectar si está siendo atacada. Nos da una visibilidad de todos los eventos de los sistemas en un mismo punto y con un mismo formato, y aumenta la capacidad de detección a través de la correlación, prioriza los eventos según el contexto en que se producen, y al ser Open Source nos permite adaptarlo a nuestras necesidades. Entre las aplicaciones que ossim integra están: Snort, Ntop, Nagios, Nmap, Osiris, Iptables, Arpwatch, P0f, Pads, ..... y muchas más en activo desarrollo.

Prelude
Hybrid Intrusion Detection System

La gente que hace "Prelude" caracteriza al proyecto como un IDS híbrido, porque trabaja como un IDS basado en Host y en Red al mismo tiempo, es un producto que permite colectar los reportes de todas las aplicaciones de seguridad en un sistema centralizado.
A diferencia de ossim, prelude usa el estándar IDMEF (Intrusion Detection Message Exchange Format) para la comunicación de los eventos.
Soporta Snort, Nessus, Samhaim (este último es un HIDS) y más de 30 tipos de log de sistema. Sin embargo, al motor de correlación le falta bastante desarrollo, aunque es un proyecto muy activo y en marzo fue cargada al svn (el repositorio) una primera versión beta del motor y ya puede detectar algunas cosas.



Palabras finales
Los SIM son una tecnología muy reciente y aunque algunos analistas consideran que las versiones actuales son más bien "administradores de eventos", aún así esta mínima funcionalidad (tener disponible la información de seguridad en un solo lugar) puede aliviar el trabajo de los administradores de seguridad, haciéndoles disponer de más tiempo para otras tareas.



Referencias