Host Intrusion Prevention System

Este artículo explica muy someramente que es un "Host Intrusion Prevention System", elemento de vital importancia en el modelo de seguridad en capas (o en profundidad).

Motivación

Si un ataque logra atravesar las defensas basadas en red (Firewalls, IPS, IDS, NAC, DDoS Defenses, etc.), el último campo de batalla es el propio sistema operativo de la PC o Servidor del objetivo del ataque, por tanto estos deben estar preparados. Otro elemento que hace importante los HIPS, es el hecho de que el tráfico cifrado no puede ser evaluado por las protecciones basadas en red. Las defensas basadas en Host más avanzadas son los "Host Intrusion Prevention System" y son la última barrera entre el atacante y su objetivo.

¿Qué es y qué hace un Host-IPS?

Los HIPS buscan anomalías (o comportamientos anómalos) a nivel del sistema operativo, comprueban los módulos cargados por el núcleo, monitorean la actividad del sistema de achivos, buscan RootKits en el sistema, etc.
Una intrusión exitosa suele ser acompañada por un conjunto de actividades que los HIPS intentar descubrir. Normalmente los intrusos buscan adueñarse o utilizar para algún fin el sistema que atacaron, para esto suelen instalar software que les permita el futuro acceso, que borre sus huellas, keyloggers, software de spamming, virus de tipo botnet, spyware, etc.
En la actualidad los HIPS incluyen funcionalidades como Firewall y Anti-maleware (anti-virus, anti-spyware, etc.).
Los Host IPS son implementados como agentes instalados directamente en el sistema que protegen. Estos monitorean de cerca al núcleo y los servicios, incluso interceptando llamadas al sistema o APIs.

Consideraciones

No todos los HIPS son iguales y debido a que trabajan a muy bajo nivel (interceptando llamadas al sistema y APIs) hay que tener ciertos recaudos a la ahora de elegir:
* Debe ser estable (confiable), sino las aplicaciones pueden no correr correctamente.
* No debe impactar negativamente en el rendimiento del sistema.
* No debe bloquear actividades o tráfico legítimo (sin "falsos positivos").
Si un IPS no cumple con estos requisitos es preferible no tenerlo.
Al igual que con los NIPS o NIDS, es muy importante que tenga un buen motor de detección de anomalías. Si sólo se basa en firmas "signatures" nunca va a detectar "exploits zero-days" (exploits muy recientes para los cuales todavía el vendedor no ha producido parches y no se han hecho firmas que lo detecten).
Antes de hacer una implantación masiva es importante chequear que el producto elegido sea compatible con todas las aplicaciones que se utilizan en los sistemas que se instalen. Hay que tener especial atención en las aplicaciones hechas a medida o pedido (home-grow, custom, etc.).
Es importante que se puedan crear reglas propias y que éstas sean sencillas de construir. Esto es importante porque el vendedor crea las reglas de manera genérica y puede no tener en cuenta problemas de nuestro entorno.
Si en el ambiente hay muchos Host (Desktops o Servers) es importante que provea mecanismos de Administración centralizada así como de reporte. Algunos son administrables vía LDAP e incluso los hay integrables con sistemas de administración de seguridad. Es importante que se puedan instalar las reglas personalizadas en todos los sistemas desde un lugar centralizado, lo mismo es recomendable para la generación de reportes.
Si bien los HIPS son de las mejores herramientas de seguridad, no son infalibles, por lo tanto no reemplazan a los NIPS, Firewalls, VPNs, etc. Y sobre todo: tener HIPS instalados en los sistemas no significa que no siga siendo importante mantener actualizados los sistemas, aplicar todos los parches de seguridad y hacer periódicos análisis de vulnerabilidades.

Finalmente algunos productos comerciales:

• McAfee Host IPS
• Cisco Security Agent
• ISS - Proventia Desktop y Server
• Symantec Critical System Protection

Saludos cordiales.-

Referencias:

• http://www.nss.co.uk/WhitePapers/intrusion_prevention_systems.htm
• http://www.sans.org/whatworks/wall.php?id=2
• http://netsecurity.about.com/cs/firewallbooks/a/aa050804.htm

Pronto publicaré un nuevo artículo

Lamentablemente en el último mes varias ocupaciones me impidieron publicar un artículo, que vengo preparando desde hace algún tiempo. Se trata de "Intrusion Prevention Systems" basados en host, espero poder publicarlo el próximo fin de semana.

Saludos, cordiales.-

Ataques MITM

En este artículo describo qué es un ataque de "Hombre en el Medio", las técnicas más comunes y muy someramente las formas de prevenirlos y/o detectarlos.

De Wikipedia:
En criptografía, un ataque man-in-the-middle (MitM, u hombre en el medio, en castellano) es un ataque en el que el enemigo adquiere la capacidad de leer, insertar y modificar a voluntad, los mensajes entre dos partes sin que ninguna de ellas conozca que el enlace entre ellos ha sido violado.

Ataques más comunes o conocidos

- ARP Poisoning (o ARP Spoofing)

Es un ataque de MITM para redes ethernet, que permite al atacante capturar el tráfico que pasa por la LAN y también detenerlo (una denegación de servicio o DoS).
El ataque consiste en enviar algunos mensajes ARP falsos ('spoofed'). Estos frames ethernet contienen las direcciones MAC manipuladas según la conveniencia del atacante. Estos mensajes confunden a los dispositivos de red (principalmente a los switchs). Como resultado los frames de las víctimas son enviados al atacante o a un destino no válido en el caso de una "DoS".
Este ataque puede ser prevenido/limitado utilizando entradas estáticas en las tablas ARP de los Hosts, usar Secure ARP, o usando tecnologías de seguridad en capa de acceso como "port security", 802.1x, NAC "Network Admission Control" o NAP "Network Access Protection".
Hay algunas herramientas que permiten detectar este tipo de ataque (por ejemplo el arpwatch), estas escuchan el tráfico ARP que transita por la red LAN y alertan ante cambios sospechosos. Hay muchos programas para realizar este tipo de ataques, los más conocidos son el Ettercap, Dsniff (ambos en Linux) y cain en Windows.

- DNS spoofing

El protocolo DNS "Domain Name System" convierte nombres en direcciones IP (por ej.: www.google.com a 64.233.161.147) y también la resolución inversa. Este ataque utiliza respuestas falsas a las peticiones de resolución DNS (los request) enviadas por una "víctima". Hay dos métodos en los que puede basarse el atacante: DNS "ID Spoofing" y "Cache poisoning" (envenenamiento de la cache).
El método ID Spoofing se basa en obtener el ID de las peticiones de resolución, el atacante puede lograr esto a través de algún ataque de sniffing, como por ejemplo desbordar la tabla ARP "MAC Flooding" de los switchs para ponerlos en un modo conocido como "failopen" (esto los transforma en un HUB). Siendo capaz de escuchar los ID de las peticiones, el atacante intenta responder a estas antes que el servidor real, logrando de esta forma engañar a la víctima y llevarla así al destino que desee. El método "Cache poisoning" es similar al anterior, salvo que se dirige a los servidores de cache de DNS, redirigiendo así a todos sus clientes al host que indique el atacante.
Herramientas conocidas que realizan este ataque son: ettercap, dsniff y zodiac.
Dado que existe este ataque se vuelve muy importante que los servidores de caché de DNS hagan sus consultas utilizando ID aleatorios. Los IDS son capaces de detectar este tipo de ataque y una medida de prevención podría ser cargar el archivo lmhost (en windows) y /etc/hosts (en linux), para los dominios corporativos. Las extensiones DNSSEC también son capaces de detener este tipo de ataques (estas extensiones se encuentran disponibles para BIND9).

- Port Stealing (robo de puerto)

En este ataque el atacante envía muchos frames ethernet (paquetes de capa 2), con la dirección MAC de la víctima como origen, y como destino su propia dirección MAC. Esto hace que el switch crea que la víctima está conectada en el puerto del atacante (de ahí el nombre de esta técnica).
Cuando el atacante recibe un paquete destinado a la víctima, este genera un ARP request preguntando por la MAC asociada a la IP de la víctima. Cuando la víctima responde el switch vuelve a conocer en donde está ubicada realmente la víctima, es entonces cuando el atacante reenvía el paquete recibido (intacto o modificado, dependiendo de los intereses del atacante). Luego vuelve a robar el puerto y espera por el próximo paquete con destino a la víctima. Esta técnica degrada la conectividad de la víctima notablemente y es fácilmente detectable por los IDS.
El uso de entradas ARP estáticas en las PC no resuelve el problema. Las alternativas de resolución son un mapeo estático en los switch, port security, 802.1x, NAP o NAC.
Una herramienta capaz de realizar este ataque es el Ettercap con el plugin confusion.

- DHCP Spoofing

Las requerimientos de DHCP son hechos con frames de tipo broadcast, ya que deben ser escuchados por todos los dispositivos dentro de la red local. Si un atacante responde antes que el verdadero servidor, este puede pasarle información errónea a la víctima, como por ejemplo puede decirle que la puerta de enlace es él.
Para algunos servidores de DHCP suele ser bastante sencillo responder antes que él, debido a que muchos verifican si no hay otro dispositivo en la red con la dirección que van a entregar; mientras el servidor real comprueba, el atacante tiene tiempo valioso en el que puede responder antes.
Los IDS detectan este ataque debido a que se producen múltiples respuestas para una única solicitud.
Así como las anteriores, ettercap también es capaz de realizar este ataque.

- Otros ataques de tipo MITM:

• STP Mangling
• Port stealing
• ICMP redirection
• IRDP spoofing
• Route mangling

802.1x/NAC/NAP

En general el uso de tecnologías de control de acceso como 802.1x/NAC/NAP sería suficiente para impedir o mitigar todos los ataques MITM de tipo local. Lamentablemente no todas las empresas u organizaciones pueden costear estas tecnologías.

Protocolos seguros

Una forma de protegernos de estos ataques es reemplazar todos los protocolos inseguros por protocolos seguros, que si bien no impiden estos ataques los hacen inútiles para el atacante, debido a que se ve imposibilitado de descifrar o alterar la comunicación.
Esto sería reemplazar http por https, telnet por ssh (version 2), pop3 por secure pop, etc.

Saludos y hasta la próxima.

Referencias:

• http://www.oxid.it/downloads/apr-intro.swf -- flash que explica ARP poisoning (en inglés)
• http://www.grc.com/nat/arp.htm
• http://wiki.ethereal.com/CaptureSetup/Ethernet
• http://www.sans.org/rr/whitepapers/threats/rss/474.php -- Address Resolution Protocol Spoofing and Man-in-the-Middle Attacks
• http://www.linuxfocus.org/Castellano/March2003/article282.shtml
• http://www.microsoft.com/technet/itsolutions/network/nap/default.mspx
• http://www.cisco.com/en/US/netsol/ns466/networking_solutions_package.html

Ejecutar open simmpls

Analizando las estadísticas del blog, veo que hay mucha gente que llega buscando cómo ejecutar el Open SimMPLS y ejemplos, por lo que me he decidido a retroalimentar el sitio con sus visitantes.

Para ejecutar, estos son los requisitos recomendados:

* Procesador a 1,5 GHz.
* 512 MB. de memoria RAM.
* 1 GB. de espacio libre en disco.
* Java ® Runtime Enviroment 1.5 instalado y configurado.

El "Java ® Runtime Enviroment 1.5" lo puedes descargar desde:

http://www.java.com/en/download/manual.jsp

El enlace de descarga del OpenSimMPLS es:

http://gitaca.unex.es/opensimmpls/proyecto/openSimMPLS.jar

Una vez que tienes el jre de java instalado y has descargado el archivo jar, deberías poder ejecutar el jar como si fuera cualquier aplicación.

Un problema que podría surgir es que no tengas asociados los archivos con extensión jar con java, en tal caso puedes ejecutarlo desde la línea de comandos, parado sobre el directorio en el que se encuentra el jar, con la siguiente instrucción:

java -jar openSimMPLS.jar

Acerca de los ejemplos puedes descargar algunos desde la página oficial del proyecto en:

http://gitaca.unex.es/opensimmpls/proyecto/ejemplos/packdeejemplo1_0.zip

Espero que esta pequeña entrada resuelva las dudas de algunos de los visitantes de este blog.

Saludos y hasta la próxima.

PD: Todavía no he tenido tiempo de terminar la segunda entrega de "Introducción a ethereal".

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

• http://sourceforge.net/projects/ethereal/
  
• http://es.wikipedia.org/wiki/Tipos_de_Sniffer
  
• http://es.wikipedia.org/wiki/Ethereal
  
• Un tutorial en castellano
  
• Otro tutorial en castellano
  
• Paper "Cables UTP de solo recepcion y 'Network Taps'"

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

• "Keys to Implementing a Successful Security Information Management Solution"
• "What Works - Cisco MARS"
  
• "Users shoring up net security with SIM"
• "Managing the security deluge"
  
• Página de Ossim
• Página de Prelude
  

Algo acerca de MPLS y sus posibles usos

MPLS es una tecnología con mucho auge, aunque todavía la mayor parte de los administradores de red la desconoce por completo, o desconoce sus posibilidades. En este artículo intentaré dar una introducción a la tecnología y explicar sus usos más comunes.

Qué es

Wikipedia define MPLS como:

MPLS (siglas de Multiprotocol Label Switching) es un mecanismo de transporte de datos estándar creado por la IETF y definido en el RFC 3031. Opera entre la capa de enlace de datos y la capa de red del modelo OSI. Fue diseñado para unificar el servicio de transporte de datos para las redes basadas en circuitos y las basadas en paquetes. Puede ser utilizado para transportar diferentes tipos de tráfico, incluyendo tráfico de voz y de paquetes IP.

MPLS fue originalmente propuesto por un grupo de ingenieros de Cisco, con el nombre de "Tag switching", fue entregado a la IETF y luego del proceso de estandarización cambió de nombre.

Cómo funciona

Es de notar que la conmutación IP es realizada en la capa 3 y está basada en la dirección ip destino (en algunos casos también en la ip de origen); si miramos una tabla de enrutamiento sólo vemos la asociación "red destino" - "próximo salto".
Por ejemplo:
192.168.0.0/24 via 10.10.2.1
192.168.1.0/24 via 10.10.2.2
192.168.2.0/24 via 10.10.2.3
0.0.0.0/0 via 10.10.2.254

El enrutamiento en sí, impone restricciones y ciertos cuidados en nuestras redes, como por ejemplo que en la asignación de direcciones ip no haya colisiones (dos segmentos de red no pueden tener las mismas direcciones).
Lo interesante de MPLS es que la conmutación de paquetes está basada en etiquetas y se realiza entre la capa 2 y la capa 3 (no depende del encabezado ip), estas etiquetas son agregadas antes del ingreso a la red MPLS y son removidas cuando los paquetes salen de ella.
MPLS funciona adicionando a los paquetes un header MPLS, que contiene una o más etiquetas, esto es llamado "label stack".

Cada etiqueta contiene 4 campos:
* 20 bits - Valor de la etiqueta.
* 3 bits - Campo experimental reservado para usos futuros.
* 1 bit - Final de la pila. Si tiene el valor 1 entonces es la última etiqueta de la pila.
* 8 bits - Campo TTL (time to live)

Arquitectura de una red MPLS

Nota: esta imagen fue generada con el simulador "Open SimMpls".

• LER (Label Edge Router): elemento que inicia o termina el túnel (agrega y quita las etiquetas). Es el punto de entrada/salida a la red MPLS. Un router de entrada se conoce como Ingress Router y uno de salida como Egress Router. Ambos se suelen denominar Edge Label Switch Router, ya que se encuentran en los extremos de la red MPLS.

• LSR (Label Switching Router): elemento que conmuta etiquetas.

• LSP (Label Switched Path): nombre genérico de un camino MPLS (para cierto tráfico o FEC), es decir, del túnel MPLS establecido entre los extremos. Se debe tener en cuenta que un LSP es unidireccional.

• LDP (Label Distribution Protocol): un protocolo para la distribución de etiquetas MPLS.

• FEC (Forwarding Equivalence Class): nombre que se le da al tráfico que se encamina bajo una etiqueta. Subconjunto de paquetes tratados del mismo modo por el conmutador.

Posibles usos

Los sectores que más provecho pueden sacar de MPLS, son los proveedores de servicio (carriers), las grandes empresas e instituciones gubernamentales (o sea, las grandes redes). Algunas empresas medianas pueden contratar un servicio de VPNs, basado en MPLS de algún proveedor de servicio, aunque la parte divertida la realiza el proveedor.
Los usos más importantes son:

* MPLS-VPN

Con MPLS pueden realizarse robustas VPNs, más escalables y menos costosas que otras alternativas como IPSec, ATM o frame relay; y además agrega QoS.

* Ingeniería de tráfico / QoS / Congestión
El enrutamiento IP tradicional suele llevar a sobrecargar los caminos más cortos (a veces caminos más largos pueden tener menor congestión y menor delay).
Respecto a este problema MPLS puede ser utilizado para:
- Maximizar la utilización de los enlaces y los nodos
- Garantizar el nivel de delay (respetar los SLAs)
- Minimizar el impacto de las fallasLos principales protocolos para realizar ingeniería de trafico con MPLS son CR-LDP y RSVP-TE.

* Integración de redes diversas: ATM, Frame relay, IP, Ethernet y ópticas
Mantener una red, es más barato que mantener muchas. Con MPLS podemos armar una red de transporte universal.

Algunas consideraciones

• Cuando se pensó la conmutación basada en etiquetas, se creía que podía ser mucho más rápida que la basada en los encabezados IP, ya que requiere menos procesamiento y es posible implementarla en hardware; pero el desarrollo de algunas tecnologías como los circuitos ASIC, o la conmutación basada en TCAM y CAM, han hecho posible que la conmutación basada en IP pueda ser tan rápida como la basada en etiquetas.

• Las VPN basadas en MPLS suelen quedar confinadas a un único proveedor de servicio.

• Una alternativa a MPLS es L2TPv3, aunque todavía está en borradores.

Referencias

• RFC - http://www.ietf.org/rfc/rfc3031.txt
• Simulador de redes MPLS, escrito en java y en Español - http://gitaca.unex.es/opensimmpls
• Un tutorial interactivo bastante instructivo de Nortel - http://www.nortel.com/products/announcements/mpls/tooldemo.html
  
• BGP/MPLS VPNs - http://www.ietf.org/rfc/rfc2547.txt - http://www.netcraftsmen.net/welcher/papers/mplsvpn.html
• Varios artículos acerca de MPLS - http://www.convergedigest.com/tutorials/#MPLS
• Wikipedia - http://en.wikipedia.org/wiki/Multiprotocol_Label_Switching
• MPLS en Linux - http://mpls-linux.sourceforge.net/
  

Es habitual encontrar administradores de red, que en un rapto de paranoia o por desconocimiento de las funciones de ICMP, filtran todo el protocolo sin reparar en las consecuencias de esto. Bloquear todo icmp puede traer bastantes molestias, cuando no, serios problemas; por otro lado, no bloquear cierto tipo de mensajes ICMP puede conllevar el riesgo de sufrir algunos ataques basados en las debilidades del protocolo.
En este artículo repaso qué es ICMP, qué permitir y qué denegar de este maravilloso protocolo.

Wikipedia define ICMP como:

"ICMP (Internet Control Message Protocol)
El Protocolo de Control de Mensajes de Internet (ICMP por sus siglas en inglés) es uno de los protocolos centrales de la suite de protocolos de Internet. Es usado principalmente por los Sistemas operativos de las computadoras en una red para enviar mensajes de error, indicando por ejemplo que un servicio determinado no está disponible o que un router o host no puede ser localizado."

Según el modelo OSI ICMP es un protocolo de capa 4, la denominada capa de transporte, esto se debe a que ICMP es encapsulado en paquetes IP.
Ahora ¿qué transporta ICMP? Para empezar, no transporta datos de las aplicaciones de usuario, sino información de control. Esta información de control es usada como soporte de los otros protocolos de transporte.
ICMP está definido por las primeras RFCs (rfc792 y rfc1122.txt), la primera data de 1981. Podemos encontrar una lista de los tipos de mensajes ICMP en:
http://www.iana.org/assignments/icmp-parameters

Usos útiles de ICMP
(lo que no se debe filtrar sin razón)

Destination Unreachable - Para indicar el fracaso de muchos protocolos (como TCP, UDP, GRE, etc.) se usan paquetes de icmp, en particular de tipo 3 "Destination Unreachable" (destino-inalcanzable). Bloquear estos paquetes significa que nunca obtendrá errores como `Host unreachable' o `No route lo host'. Cualquier conexión a un destino inalcanzable esperará hasta el timeout, esto es irritante, pero difícilmente fatal.

Fragmentation needed - Un problema peor se puede generar si filtramos los paquetes de ICMP que participan en el descubrimiento del MTU "Max Transfer Unit". Todas las buenas implementaciones de TCP/IP intentan utilizar el tamaño de paquete más grande que se pueda, esto reduce drásticamente la sobrecarga causada por los encabezados.
Para descubrir el MTU hasta algún destino, se utiliza una técnica conocida como PMTU-D "Path MTU - Discovery", la cual depende de un paquete icmp de tipo "destination-unreachable" con código "Fragmentation needed but DF set" (tipo 3, código 4).
Si filtramos este tipo de paquetes ICMP, se reducirá el rendimiento de TCP para sitios que tengan un MTU pequeño y en algunos casos estos sitios se harán inalcanzables.

Más información en:
- http://www.netheaven.com/pmtu.html
- http://www.ietf.org/internet-drafts/draft-ietf-pmtud-method-06.txt
- http://www.lartc.org/howto/lartc.cookbook.mtu-mss.html

Security Failures - IPSec, el protocolo más usado para realizar VPNs, utiliza un tipo especial de mensajes icmp para informar errores de autenticación, si los filtramos desconoceremos de las causas por las que fallan nuestros túneles.
Más en: http://www.ietf.org/rfc/rfc2521.txt

Time to Live exceeded in Transit - El comando traceroute o tracert, está implementado transmitiendo datagramas UDP con distintos valores en el campo TTL "Time To Live" de la cabecera IP.
El campo TTL es reducido en cada salto (cada vez que pasa por un router); cuando un router reduce el campo TTL de un paquete a cero, lo descarta y genera un paquete ICMP con código "Time to Live exceeded in Transit" - "Tiempo de Vida Excedido en tránsito".
Volviendo al comando traceroute, dijimos que éste genera paquetes UDP con distintos TTL, luego espera por los paquetes icmp con código "Time to Live exceeded in Transit" o "port unreachable", los cuales tienen como ip de origen la ip del router que los originó, con esta información genera la ruta que le solicitamos.

Request/Reply - La herramienta ping está implementada utilizando los mensajes "Echo request" y "Echo reply" de icmp, si los filtramos no esperemos hacer ping a ningún lado. Es incorrecto pensar que, porque filtremos los "echo request/reply" de/a nuestros hosts, esto los hará invisibles.
Podemos ser objetos de un ataque de Denegación de Servicio "DoS" con estos paquetes, por lo cual es recomendable aplicar un control de ancho de banda sobre ellos.

Parameter Problem - Estos mensajes son usados para indicar que se encontró un problema durante el procesamiento de los parámetros de la cabecera IP, normalmente dado por la mala implementación del Sistema Operativo, origen o destino; estos errores derivan en la pérdida de la conexión. Descubrir dichos errores sin estos mensajes puede ser muy difícil; sin embargo hay quienes bloquean estos mensajes, ya que pueden ser utilizados para hacer "fingerprinting" (Descubrir qué SO estamos corriendo).

Ataques basado en ICMP y Mensajes Obsoletos
(qué filtrar)

Redirect - Existe un tipo de paquete icmp llamado "redirect", que es usado por un router cuando le llega un paquete, para indicarle a otros equipos que existe una ruta alternativa sin pasar por él. Dado este caso, el router genera un mensaje icmp "redirect", con la información de la ruta que él cree mejor, y lo envía al equipo que le entregó el paquete. Si el equipo que recibe el paquete "redirect" tiene "Fé" en lo que le dicen, acepta la nueva ruta.
Este tipo de paquetes icmp debe ser filtrado ya que puede ser utilizado para ejecutar un ataque de "hombre-en-el-medio", por sus siglas en inglés de MITM; y en una red bien mantenida estos mensajes no deberían ser necesarios.

Source Quench - El mensaje source quench es obsoleto y fue pensado originalmente para que un host destino pueda pedir al host origen que baje el ritmo al que está enviando. Actualmente hay mejores mecanismos para manejar el control de ancho de banda. Y este tipo de mensajes puede ser utilizado para implementar un ataque de DoS "Denial Of Service". En la próxima revisión de icmp será declarado obsoleto.

Otros Obsoletos - "Information Request/Reply", "Datagram Conversion", "Domain Name", "Address Mask Request/Reply" y "Address Mask Request/Reply". La mayoría de estos tenían funciones que ahora se cubren con DHCP.

Notas

• Hay cierto tipo de ataques basados en paquetes icmp que no son tratados en este artículo. Te recomiendo la lectura del borrador de RFC de Fernando Gont, acerca de esto: http://www.gont.com.ar/drafts/icmp-attacks-against-tcp.html

• En la mayoría de las distribuciones de linux podemos deshabilitar que se acepten los icmp redirect, agregando la siguiente línea al archivo /etc/sysctl.conf:
  
  net.ipv4.conf.all.accept_redirects = 0
  
  En cisco por interface con el comando:
  
  router1(config)# interface Ethernet0
  router1(config-if)#no ip redirects
  
  
• Ejemplo de filtrado con iptables:
  Se puede filtrar los paquetes icmp "source quench" con el siguiente comando:
  
  $ iptables -I FORWARD -p icmp --icmp-type source-quench -j DROP
  y podemos obtener una lista de los tipos de mensajes icmp con:
  $ iptables -p icmp --help
  

Referencias

• http://www.ietf.org/rfc/rfc792.txt
• http://www.ietf.org/rfc/rfc1122.txt
• http://www.ietf.org/rfc/rfc2521.txt
• http://www.iana.org/assignments/icmp-parameters
• http://www.ietf.org/internet-drafts/draft-ietf-pmtud-method-06.txt
• http://www.netheaven.com/pmtu.html
• http://www.lartc.org/howto/lartc.cookbook.mtu-mss.html
• http://www.aarnet.edu.au/engineering/networkdesign/qos/icmp.html
• http://www.gont.com.ar/drafts/icmp-attacks-against-tcp.html

En este espacio publicaré artículos de temas relacionados con las redes y la seguridad informática.
Algo que no encontrarás en este blog son noticias; si es lo que estás buscando te recomiendo otros sitios como bugtraq, securityfocus, slashdot, barrapunto, etc.
Si bien intentaré hacer los artículos de carácter conceptual independientes de plataforma/vendedor, habrá otros muy enfocados en linux.
Veremos que sucede con el correr del tiempo.

Saludos.