La propia historia y la evolución de los diversos ataques cibernéticos, han llevado a contar con un auténtico festival de dispositivos destinados, cada uno a su manera, a proteger en conjunto los activos de las organizaciones. Cortafuegos, antivirus, antispams, gestores de ancho de banda, IDS/IPS, mecanismos
NAC …
Cada fabricante presenta en formato appliance su solución para dotar de seguridad ante una tipología de ataques dado. Ante esta avalancha de “cajas negras” que se apilan en los racks de los CPDs, contamos con que cada aplicación posee su propia herramienta/consola de gestión (tanto para la configuración inicial como para la gestión de los eventos emitidos). Desgraciadamente, los fabricantes no pueden hacer herramientas con una API común a la hora de la configuración, por lo que los administradores de red, han de tener una colección de GUIs para administrar cada uno de los equipos con los que cuentan.
Sin embargo, lo que si que parece estar más estandarizado es la manera de gestión de eventos. En realidad, cada dispositivo envía eventos a su propia plataforma de recolección de Logs, pero suelen soportar el envío mediante el estandar syslog a plataformas de centralización de eventos de manera que podemos tener ordenados cronológicamente los eventos producidos por un mismo ataque al atravesar los diversos equipos.
La principal ventaja de este tipo de solución de centralización está bien clara, el operador de red que monitorice diferentes consolas de logs, ahora tendrá en un único punto toda la información relevante en orden cronológico. La eficiencia aumenta, por tanto el tiempo de reacción ante ataques también. Un ejemplo de centralización o consolidación de eventos de red podría ser la utilización de un servidor Syslog configurable para guardar los eventos en una base de datos centralizada y además poderlos guardar en formato texto para ser utilizados por separado llegado el momento. Me refiero por supuesto a
Syslog-NGUna vuelta de tuerca más nos lleva a las soluciones que además de consolidar esos eventos y ponerlos a disposición de un operador, son capaces de elaborar alertas más elaboradas, basadas en los eventos recibidos de diversas fuentes de información. La idea es análoga a la disyuntiva que indicábamos en el
post de configuración de IDS/IPS, puesto que podemos tener almacenados (y centralizados) todos los eventos que se reciben por diversas fuentes, pero presentarle al operador una única alarma como consecuencia de un conjunto de esos eventos. Como dijimos en su momento, una solución híbrida es la recomendada.
Podemos por ejemplo prevenir un ataque de denegación de servicio basándonos en la diversos eventos: un aumento en el número de conexiones TCP/IP así como un incremento de la carga de un router o un cortafuegos, la detección de ese evento por parte de las sondas IPS/IDS, un aumento del ancho de banda disponible, pérdida de conectividad con el exterior,… de manera que podamos, llegado el momento establecer reacciones ante esos eventos como correlación que nos permitan bloquear la IP atacante de forma dinámica mediante ACLs o reglas.
Existen soluciones comerciales para la consolidación y correlación de eventos por parte de fabricantes como
Computer Associates,
LogICA,
Bitacora,...
En general este tipo de productos dan lugar a largas implantaciones para las organizaciones para adaptar las métricas necesarias a los productos y concluir cuándo se da un ataque y cuándo es tráfico normal de red. Se suelen implantar en organizaciones grandes y financieramente solventes (bancos, grandes ISPs, organismos militares, etc…).
Desde SecurityByDefault queremos recomendar una alternativa basada en software libre:
OSSIM. Este proyecto se basa en la integración de varios productos de seguridad que vuelcan la información en una base de datos y una consola única para acceder a la información que genera cada uno. Además, esta consola genera, basándose en datos reales (escanea las vulnerabilidades desde un punto de vista interno con Nessus y correla la información obtenida por Snort como eventos ocurridos), el nivel de riesgo al que está expuesto una organización, a modo de cuadro de mandos de seguridad.
Las herramientas que aúna para currelar eventos son, entre otras:
Snort (Detección de intrusiones),
Nessus (Análisis Remoto de Vulnerabilidades),
PADS (Detector de software de una organización basado en el análisis del tráfico de red. Detecta hasta versiones de algunas aplicaciones),
Ntop (Análisis del tráfico de una red clasificándolo por IP Origen/Destino, Protocolo, ancho de banda utilizado, etc,…),
ARPWatch (Monitorización de pares IP/MAC para detectar cambios de MAC en determinados hosts),
P0f (detección de sistemas operativos de las máquinas que emiten trafico de red mediante trazas de la pila TCP/IP), RRDTool (Elaboración de estadísticas en tiempo real en base a datos almacenados en formato RRD)
Otra alternativa llevada a cabo por colaboradores de este Weblog en un importante ISP nacional, se basó en un desarrollo propio de integración de diferentes módulos que recogían información de diferentes equipos de red (routers, firewalls e IDSs). Mediante un módulo correlador hecho en Perl (
SEC: Simple Event Correlator) se establecieron una serie de patrones que eran efectivas para la entidad en concreto, siendo capaces de prevenir un ataque
DoS (Denegación de Servicio).
Como se puede observar, existe la posibilidad de integrar soluciones genéricas adaptables a las necesidades de una organización, así como utilizar herramientas libres o desarrollos propios para consolidar y/o currelar eventos. De lo fino que se quiera hilar en esta labor (y una vez más, dependiendo del presupuesto asignado), elegiremos una o varias de las alternativas expuestas pudiendo tener en todo momento controlada la actividad de la red.
