Ajuste e implementación

Un sensor solo ve el tráfico que llega hasta él. La ubicación de los sensores IDS/IPS determina qué puede detectar, por lo que la ubicación es la primera decisión de la implementación.

Planifique la ubicación en torno a los puntos de estrangulamiento y los límites de confianza de su red: el perímetro de Internet, las zonas de seguridad, la parte frontal de los activos críticos y los puntos de salida por los que se produce la exfiltración.

Hay que supervisar dos ejes de tráfico:

• Norte-sur — tráfico que cruza el perímetro (entra o sale de Internet). Los sensores perimetrales clásicos cubren este tráfico.
• Este-oeste — tráfico entre hosts internos. Aquí es donde se produce el movimiento lateral y a menudo no hay supervisión.

Los atacantes que consiguen entrar se desplazan de este a oeste. Una implementación limitada al perímetro no puede detectarlos, por lo que las sondas internas y los sensores de segmento son esenciales para la detección moderna.

Elegir cómo capturar el tráfico afecta a la fidelidad:

• Los puertos SPAN/mirror son gratuitos, pero comparten recursos del switch y descartan paquetes bajo carga, precisamente cuando más los necesita.
• Los TAPs de hardware copian el tráfico sin pérdidas y siguen funcionando ante fallos del dispositivo, pero requieren presupuesto y puertos.

Para enlaces de alto rendimiento o críticos para el cumplimiento normativo, prefiera los TAPs. Los TAPs de agregación y los brokers de paquetes de red pueden proporcionar tráfico a varias herramientas desde un único punto de captura.

Un sensor sobrecargado descarta paquetes silenciosamente, lo que crea brechas de detección que parecen tráfico limpio. Dimensione los sensores según el enlace.

Supervise las estadísticas del motor para detectar capture.kernel_drops y la pérdida de paquetes. Si aumentan los descartes, necesita más CPU, ajustar RAFL/AF_PACKET, modificar el offload de la NIC o utilizar un sensor más rápido. Valide que el sensor gestione el caudal máximo, no el promedio.

Ejecutar todas las reglas disponibles es una receta para generar ruido y perder rendimiento. Seleccione cuidadosamente el conjunto de reglas.

• Active las categorías de reglas relevantes para su entorno y sus activos
• Desactive las reglas para software que no utilice
• Utilice un gestor como suricata-update para descargar, combinar y versionar las fuentes de reglas
• Registre las fuentes de las reglas (ET Open, ET Pro, personalizadas) y actualícelas según un calendario

En lugar de editar las reglas originales, controle el ruido mediante una configuración de umbrales/supresión. Suprima un sid ruidoso para una fuente conocida y legítima; establezca umbrales para otras reglas a fin de limitar la frecuencia de las alertas.

Así podrá mantener actualizadas las reglas de terceros y, al mismo tiempo, silenciar los falsos positivos específicos de su red.

No implemente nunca una regla nueva o desconocida directamente en drop. Ejecútela primero en modo de alerta (IDS), observe durante días o semanas qué detecta y confirme que la tasa de falsos positivos sea aceptable.

Solo cuando una regla demuestre ser fiable debe promoverla al bloqueo inline. Este enfoque gradual evita que una única regla defectuosa provoque una interrupción del servicio.

Definir correctamente $HOME_NET y las demás variables es fundamental. Muchas reglas se activan según la dirección (de externo a interno frente a de interno a externo), por lo que un $HOME_NET incorrecto rompe silenciosamente la lógica de detección.

Defina con precisión sus rangos internos, grupos de servidores y redes de confianza. Manténgalos actualizados a medida que cambie la red y revíselos cuando las detecciones se comporten de forma inesperada.

Los sensores solo son útiles si sus resultados llegan a los analistas. Envíe las alertas y los metadatos a un SIEM para correlacionarlos, enriquecerlos y conservarlos.

El EVE JSON de Suricata emite eventos estructurados (alertas, flujos, HTTP, DNS, TLS y hashes de archivos) que se integran fácilmente en un SIEM. Combine el IDS con la captura completa de paquetes para que los analistas puedan recuperar el tráfico real asociado a una alerta durante la investigación.

Un IPS inline forma parte de la ruta crítica, por lo que su fallo equivale a un fallo de red. Diseñe pensando en la resiliencia.

• Las NIC con bypass de hardware / fail-open mantienen el tráfico en circulación si el motor falla (cuando la disponibilidad tiene prioridad sobre la seguridad)
• Sensores redundantes en pares activo/en espera o agrupados
• Los sensores IDS fuera de banda también necesitan redundancia; de lo contrario, tendrá puntos ciegos silenciosos

Decida entre fail-open y fail-closed para cada enlace según el riesgo empresarial y pruebe la conmutación por error antes de depender de ella.

Un sensor desplegado puede degradarse silenciosamente: un cambio de configuración, un desvío de SPAN o un aumento de carga pueden dejarlo ciego. Verifique que siga funcionando.

• Ejecute periódicamente tráfico de prueba seguro que las reglas conocidas deberían detectar
• Genere una alerta cuando dejen de aparecer las detecciones esperadas
• Supervise el estado del sensor (descartes, CPU, tiempo de actividad) con el mismo cuidado que las alertas
• Utilice emulación de adversarios para confirmar la cobertura de extremo a extremo

Una detección que nunca se prueba es una detección en la que no puede confiar.

Diagnostique una brecha real de despliegue.

Un despliegue eficaz de IDS/IPS se basa en la visibilidad y la disciplina:

• La ubicación determina lo que puede ver; cubra el perímetro y los segmentos internos
• Supervise el tráfico este-oeste, no solo el norte-sur, para detectar el movimiento lateral
• Prefiera los TAPs a SPAN para obtener una captura sin pérdidas y de alto rendimiento
• Dimensione los sensores para que los descartes de paquetes se mantengan cerca de cero
• Seleccione cuidadosamente los conjuntos de reglas con suricata-update; suprima y establezca umbrales para el ruido mediante la configuración
• Ajuste primero en modo de alerta y después promueva la regla a drop
• Defina correctamente HOME_NET
• Envíe EVE JSON a un SIEM y conserve la captura de paquetes para las investigaciones
• Valide continuamente la detección y el estado de los sensores

Ha completado el curso de Monitorización de la seguridad de redes.