Qué es un IDS: tipos, diferencias con IPS y Snort vs Suricata

Un IDS detecta intrusiones en red o host y genera alertas sin bloquear el tráfico por sí mismo. Las siglas vienen del inglés Intrusion Detection System. Monitoriza tráfico de red, eventos de sistema o ambos buscando patrones que indiquen intento de intrusión o violación de política. El nombre lleva varias décadas en uso y, aunque la categoría ha evolucionado hacia productos modernos como NDR (Network Detection and Response) y XDR, los principios siguen siendo los mismos: observar, comparar contra reglas o modelos, alertar. En 2026 el IDS clásico no muere; convive con NDR y se integra como capa de un programa defensivo más amplio.

Esta guía explica qué es exactamente un IDS, las dos categorías clásicas (NIDS basado en red y HIDS basado en host), las diferencias precisas con IPS, firewall y SIEM, comparativa práctica de las tres plataformas que más aparecen en producción real (Snort, Suricata, Zeek), cómo encaja en el ecosistema SIEM y SOC, errores comunes en despliegues y cuándo conviene un IDS frente a NDR moderno o XDR integrado.

Qué es un IDS

Un IDS es un sistema pasivo de monitorización que detecta actividad sospechosa y genera alertas, sin bloquear el tráfico ni la actividad por sí mismo. Las cuatro ideas que lo definen:

1. Pasivo. Observa, no interviene. Esto lo distingue del IPS.
2. Basado en reglas, anomalías o ambos. Las reglas detectan patrones conocidos (firmas); el análisis de anomalías detecta desviaciones respecto a la línea base normal.
3. Genera eventos. La alerta llega a un SIEM, a un equipo SOC o a un buzón. La acción la toma alguien después.
4. Cubre red, host o ambos. NIDS observa tráfico; HIDS observa eventos de sistema.

Lo que aporta operativamente:

• Visibilidad de tráfico interno y externo sin requerir agente en cada endpoint.
• Detección de movimiento lateral que un firewall perimetral no ve.
• Evidencia forense posterior a un incidente.
• Cumplimiento documentable en NIS2, DORA, ISO 27001, ENS, PCI DSS.
• Coste bajo en plataformas open source bien operadas.

Lo que limita:

• Solo alerta, no bloquea. Sin equipo que actúe, la alerta es decoración.
• Falsos positivos. Sin ajuste, ahoga al SOC y se acaba ignorando.
• Cifrado. TLS 1.3 y QUIC reducen lo que un NIDS puede inspeccionar sin TLS termination.
• Tráfico encriptado por VPN o aplicaciones modernas queda fuera del alcance.

NIDS frente a HIDS

La división clásica que sigue vigente.

NIDS (Network-based IDS)

Sensor que captura tráfico de red en un punto estratégico (SPAN port, network TAP, capa cloud equivalente) y lo analiza. Reglas que comparan paquetes contra firmas, motores que detectan anomalías estadísticas, decoders de protocolos.

Productos open source: Snort, Suricata, Zeek. Comerciales: Cisco Firepower, Palo Alto WildFire, Check Point IPS, Trellix Network Security Platform.

Ventaja: una sola instalación cubre muchos hosts. Inconveniente: TLS cifrado lo limita, encapsulación en VPN o aplicaciones modernas también.

HIDS (Host-based IDS)

Agente instalado en el endpoint que monitoriza eventos del sistema operativo: logs, procesos, conexiones, integridad de ficheros (FIM), syscalls.

Productos open source: OSSEC (ahora descontinuado en favor de Wazuh), Wazuh agent, AIDE para FIM puro. Comerciales: la mayoría de EDR modernos incluyen funcionalidad HIDS (CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint).

Ventaja: ve el contenido descifrado en el host, capta eventos sin depender de la red. Inconveniente: requiere agente, mantener cobertura, peso por endpoint.

En la práctica moderna, los dos coexisten. La separación NIDS y HIDS se ha difuminado dentro de NDR, EDR y plataformas XDR; el principio sigue válido para arquitectura defensiva.

IDS, IPS, firewall y SIEM

La confusión entre estos términos es habitual. Las diferencias prácticas:

• Firewall. Bloquea o permite tráfico en función de reglas L3-L7. Es preventivo. Los modernos (Next-Generation Firewall) integran capacidades IDS/IPS y filtrado de aplicación.
• IDS. Detecta y alerta sobre tráfico sospechoso. Pasivo. No corta la conexión.
• IPS (Intrusion Prevention System). Detecta y bloquea. Es la evolución activa del IDS. En productos modernos suele aparecer como módulo dentro del NGFW.
• SIEM. Plataforma que ingiere logs de IDS, firewall, EDR, identidad y muchas otras fuentes, los correlaciona y genera alertas más ricas. Detalle en qué es un SIEM.
• NDR (Network Detection and Response). Categoría moderna que extiende el IDS clásico con ML, threat intelligence y capacidades de respuesta integradas.
• EDR / XDR. Equivalentes en endpoint. Sobre el papel cubren el rol HIDS y van más allá.

En una arquitectura típica: el firewall bloquea lo conocido malo, el IDS/NDR observa lo que pasa, el SIEM correlaciona, el SOC actúa. Cada pieza tiene función específica; ninguna sustituye a otra.

Snort, Suricata y Zeek: comparativa práctica

Las tres plataformas open source que más aparecen en producción real, especialmente en mid-market español y sector público.

Snort

El IDS open source más antiguo y conocido. Creado por Marty Roesch (Sourcefire, ahora Cisco). Reglas en formato .rules que comparan patrones contra paquetes. Comunidad activa, conjunto de reglas comunitarias (Snort Community Rules) y comerciales (Talos Subscriber). Snort 3 (2021+) rediseñó la arquitectura para multi-threading.

• Mejor para: detección basada en firmas, integraciones legacy, organizaciones con experiencia previa Sourcefire/Cisco.
• Limitaciones: detección de anomalías limitada, sintaxis de reglas que envejece, menos preparado para alto throughput sin tuning.

Suricata

Lanzado en 2009 por OISF (Open Information Security Foundation). Reglas compatibles con Snort más extensiones propias. Multi-threading nativo, parseo de protocolos, escritura de tráfico relevante en disco, extracción de ficheros, scripting con Lua. Salida directa a EVE JSON, ideal para integración SIEM.

• Mejor para: alto throughput (10G/40G/100G con hardware adecuado), uso moderno, integración con stacks Elastic, Splunk o Wazuh.
• Limitaciones: requiere ajuste fino para evitar falsos positivos, complejidad operativa media-alta.

Se ha convertido en el default moderno cuando una organización elige open source IDS/NDR desde cero.

Zeek (antes Bro)

Lanzado en 1994 por Vern Paxson (LBNL). Filosofía distinta: no es un motor de reglas, es un analizador de protocolos profundo que genera logs estructurados muy ricos (conn.log, http.log, dns.log, ssl.log, files.log). Scripts en su propio lenguaje Bro/Zeek scripting language para definir lógica de detección custom.

• Mejor para: análisis forense, threat hunting, organizaciones con equipo capaz de escribir scripts. Genera el dataset más rico de la tríada.
• Limitaciones: curva de aprendizaje alta, requiere SIEM o ELK detrás para explotar los logs, no detecta "out of the box" como Snort/Suricata.

Stacks típicas combinando los tres

Patrones realistas en cliente español:

• Solo Suricata. La elección más común en mid-market. Cobertura suficiente con reglas comunitarias o comerciales (ET Open, ET Pro de Proofpoint, ANY.RUN).
• Suricata + Zeek paralelo. Doble pipeline: Suricata para alertas inmediatas, Zeek para enriquecimiento forense. Pasa todo al SIEM para correlación.
• Wazuh con módulo de network IDS. Para organizaciones que ya operan Wazuh como SIEM.
• NDR comercial sobre Suricata. Productos como Stamus Networks, Corelight, Vectra construyen sobre motores open source y añaden ML, UI, integración cloud y soporte.

Integración con SIEM y SOC

Un IDS aislado no aporta valor real. La integración correcta:

1. Salida estructurada del IDS hacia el SIEM (Splunk, Elastic, Wazuh, Microsoft Sentinel). Suricata escribe EVE JSON nativo; Zeek emite logs estructurados.
2. Correlación en SIEM con otras fuentes: firewall, EDR, identidad, DNS, proxy.
3. Reglas de detección que combinan eventos IDS con contexto. Una alerta IDS aislada puede ser falso positivo; correlada con un login anómalo a la vez en otro sistema, sube de prioridad.
4. Playbooks que el equipo SOC ejecuta tras cada tipo de alerta IDS: aislamiento, captura forense, comunicación.
5. Feedback loop. El SOC retroalimenta el ajuste de reglas IDS para reducir falsos positivos.

Un IDS sin SOC ni proceso de respuesta es un generador de ruido. El IDS solo aporta si el equipo defensivo lo opera.

Errores comunes en despliegues IDS

Lo que se ve en auditorías y proyectos con clientes que tienen IDS desplegado pero mal operado.

Reglas por defecto sin ajuste. Genera miles de falsos positivos en las primeras horas. El equipo se desensibiliza, las alertas se ignoran, las que importan se pierden en el ruido.

Posicionamiento del sensor incorrecto. Sensor solo en perímetro deja ciego el movimiento lateral interno. Sensor solo en datacenter deja ciego el tráfico hacia internet. Lo correcto es múltiple, con visibilidad este-oeste y norte-sur.

Capacidad insuficiente. Sensor que recibe 10 Gbps con hardware dimensionado para 1 Gbps deja paquetes sin inspeccionar. La cifra de packet loss en producción debe ser cero o cercana.

TLS sin termination. El 95% del tráfico moderno va cifrado. Sin TLS termination autorizado en el perímetro o sin visibilidad complementaria de endpoint, el IDS solo ve handshakes.

Reglas obsoletas. Conjunto de reglas sin actualizar durante meses queda atrás de las amenazas reales. Suscripción a feeds comerciales (ET Pro, Talos) o actualización diaria de feeds comunitarios.

Sin integración SIEM. El IDS genera sus alertas en una consola aislada que nadie mira. Toda alerta debería ir al SIEM y entrar en el flujo de triage normal.

Confundir IDS con compliance solo. Comprar IDS para marcar la casilla NIS2 o PCI sin operarlo. Auditoría seria detecta la ausencia de operación real y suspende.

Cuándo conviene IDS frente a NDR moderno

Decisión 2026 en empresa mediana:

• IDS open source (Suricata) + SIEM: presupuesto ajustado, equipo técnico interno o partner MSSP, organización con tráfico predominantemente plano y arquitectura clásica.
• NDR comercial (Vectra, ExtraHop, Darktrace, Corelight): presupuesto disponible, necesidad de detección automática con ML sobre comportamiento, organizaciones con tráfico complejo, multi-cloud, OT.
• EDR / XDR + telemetría cloud: empresa puramente cloud-native, sin perímetro tradicional. El concepto IDS se diluye dentro de XDR.
• Combinación de las tres capas: organizaciones grandes o sectores críticos (NIS2 esencial, DORA, energía, sanidad).

Ningún producto sustituye a un equipo capaz de operarlo. La decisión técnica importa menos que la decisión organizativa de tener alguien que mire las alertas.

Encaje con compliance

IDS o equivalente NDR es exigible directa o indirectamente en marcos vigentes:

• NIS2 (artículo 21). Detección de incidentes, monitorización continua. Sin capacidad de detección de red, el incumplimiento es defendible ante auditoría.
• DORA (artículo 9). Resiliencia ICT en servicios financieros. Monitorización formal con métricas.
• ISO 27001:2022 (controles 8.16, 8.20, 8.21). Actividades de monitorización, redes seguras, servicios de red.
• ENS Real Decreto 311/2022 (op.mon). Sistema de medidas de monitorización.
• PCI DSS v4.0 (req. 11.5). Mecanismos de detección y prevención de intrusiones obligatorios para entornos que procesen datos de tarjeta.
• RGPD. La capacidad de detectar y notificar brechas en 72 horas requiere visibilidad técnica real.

Preguntas frecuentes

¿Diferencia exacta entre IDS y IPS?

El IDS detecta y alerta; el IPS detecta y bloquea. Funcionalmente IPS es IDS más capacidad de actuación inline. Los productos modernos (NGFW, NDR) suelen ofrecer ambos modos en la misma plataforma. La decisión depende del riesgo de bloqueo accidental: un IPS que bloquea tráfico legítimo crítico genera incidente operativo, mientras que un IDS que solo alerta es seguro frente a falsos positivos.

¿Hace falta IDS si ya tengo EDR?

Cubren cosas distintas. El EDR ve el endpoint y lo que pasa dentro, incluso tráfico cifrado decodificado por el navegador. El IDS ve el tráfico entre endpoints, incluyendo sistemas sin agente (impresoras, OT, routers, IoT). La cobertura realista combina los dos.

¿Suricata sustituye a Snort?

En despliegues nuevos, casi siempre. Suricata es compatible con la mayoría de reglas Snort, escala mejor en multi-core y emite logs JSON nativos. Snort sigue presente en organizaciones con inversión legacy o stacks Cisco que prefieren mantener la herramienta del fabricante.

¿Para qué sirve Zeek si ya tengo Suricata?

Para análisis forense y threat hunting profundo. Suricata alerta; Zeek genera el dataset que permite reconstruir qué pasó durante una intrusión. Equipos serios despliegan los dos.

¿IDS puede inspeccionar tráfico TLS?

Solo si hay TLS termination autorizado. La práctica habitual en empresa es desplegar proxy o NGFW que descifra tráfico saliente con certificado raíz corporativo distribuido a endpoints, inspecciona y re-cifra. Sin este modelo, el IDS de red queda con visibilidad limitada al SNI, certificado y metadatos.

¿Qué pasa con QUIC y HTTP/3?

Suricata 7+ y Zeek 6+ parsean QUIC parcialmente. HTTP/3 sobre QUIC complica la inspección porque va cifrado de extremo a extremo. La industria está adaptándose; en 2026 la cobertura real es mejorable. La defensa complementaria es la telemetría de endpoint, que ve el contenido descifrado.

¿Cuál es la tasa razonable de falsos positivos?

Tras la calibración inicial, una organización madura mantiene tasas inferiores al 5-10% en alertas de severidad alta. Por encima, el ruido satura al SOC y el sistema deja de ser efectivo. La revisión continua de reglas es parte del coste operativo.

Recursos relacionados

• Qué es un SIEM: plataforma que ingiere y correlaciona los eventos del IDS junto con otras fuentes.
• Wazuh open source: SIEM + HIDS open source con capacidades de IDS integradas.
• Qué es un SOC: equipo que opera el IDS, revisa alertas y ejecuta respuesta.
• Qué es un EDR y qué es un MDR: controles complementarios al IDS en la pila defensiva.
• Qué es threat hunting: disciplina que aprovecha la telemetría rica de Zeek y los logs IDS para caza proactiva.
• Qué es MITRE ATT&CK: catálogo donde cada regla IDS debería estar etiquetada con la técnica correspondiente.

Diseño y operación de IDS en Secra

En Secra trabajamos del lado del cliente con IDS en tres situaciones típicas: revisión de despliegue existente (cobertura, posicionamiento de sensores, ajuste de reglas, falsos positivos reales, integración SIEM), diseño de pila nueva (elección entre Suricata, Zeek o NDR comercial según presupuesto, arquitectura y obligaciones), y validación empírica vía Red Team que comprueba si el IDS detecta TTPs reales. Si tu organización va a comprar IDS, ya lo tiene pero genera más ruido que valor, o tiene que documentar capacidad de monitorización bajo NIS2 o DORA, escríbenos a través de contacto o consulta nuestros servicios gestionados.