Mostrando entradas con la etiqueta arquitectura. Mostrar todas las entradas
Mostrando entradas con la etiqueta arquitectura. Mostrar todas las entradas

29 julio 2008

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...

16 junio 2008

Una de Bugs 'gordos': "SNMPv3 Authentication Bug"

SNMP es, tal vez, como la señora de la limpieza; a priori, poca gente repara en su presencia y labor, pero si empieza a dar problemas, acaba afectando a toda la oficina. Bromas aparte, SNMP es un protocolo básico en la gestión, y monitorización de dispositivos de red. Practicamente cualquier organización de mediana o alta entidad lo usa en algún lado y, generalmente, los dispositivos que hablan SNMP suelen ser elementos críticos en la infraestructura.

Tiempo atrás, allá por el 2002 SNMP ya dio un buen susto con un problema severo en la forma que eran parseados los mensajes en formato ASN.1. En ese momento se organizó un tremendo revuelo al respecto ya que fueron muchos los dispositivos de red que se vieron afectados por ese bug.

Por si no fuera poco con ese incidente, ahora ha sido reportado otro bug con bastante enjundia también. En este caso, el problema radica en la gestión de mensajes firmados con HMAC. El resultado es que, en muchos de los dispositivos con mayor presencia en el mercado, (Cisco, Juniper ...) se puede violar el control de acceso y acceder remotamente.

Obviamente no hace falta pensar mucho para imaginar la envergadura del problema (practicamente la conectividad en Internet se sustenta en 3-4 marcas de dispositivos).

Desde mi punto de vista, SNMP es terriblemente complejo, duro de asimilar y tedioso de gestionar. Tal vez sea hora de buscar alguna alternativa mas KISS
Leer más...