Suricata vs Snort vs Zeek: cómo trabajan los IDS y cómo montarlos con pfSense

Tu firewall decide qué entra y qué sale. Pero hay una pregunta que un firewall, por bueno que sea, no responde del todo: ¿qué está pasando realmente dentro de tu red ahora mismo? ¿Qué dominios está resolviendo ese servidor a las 3 de la madrugada? ¿Por qué un equipo de contabilidad abre conexiones periódicas cada 60 segundos exactos hacia una IP de otro continente? ¿Quién se está llevando 40 GB por la interfaz WAN un domingo? Para responder eso necesitas ver el tráfico, no solo filtrarlo. Y de ahí nace toda una familia de herramientas que desciende del humilde sniffer. Elegir bien tu sistema de detección —la eterna comparación Suricata vs Snort vs Zeek— empieza por entender qué mira cada uno. Verlo y protegerlo forma parte de una estrategia de seguridad informática bien planteada.

En el mundo open source hay tres nombres que dominan esta conversación desde hace dos décadas: Snort, Suricata y Zeek. Los tres miran los mismos paquetes, pero trabajan de formas radicalmente distintas — dos son vigilantes que comparan el tráfico contra firmas de ataques conocidos, y el tercero es un analista que lo registra y lo entiende todo sin buscar nada en concreto. Elegir bien exige entender esa base de trabajo, porque no compiten tanto como se complementan.

En esta guía explicamos cómo funciona cada uno por dentro, con ejemplos concretos de qué detecta cada enfoque, y aterrizamos la parte práctica con pfSense: el firewall open source que permite montar un IDS/IPS serio — con Suricata o Snort integrados — sobre hardware modesto y sin pagar licencias. Si leíste nuestra guía de cómo poner un firewall detrás del router de tu operadora, este es el siguiente capítulo natural: primero controlas la puerta; ahora aprendes a ver quién anda por el pasillo.

1. Del sniffer al IDS: la base de trabajo común

Todo empieza con la captura pasiva de paquetes: poner una interfaz de red en modo promiscuo y copiar todo lo que pasa por el cable. Eso es un sniffer, y herramientas como tcpdump o Wireshark llevan décadas haciéndolo para diagnóstico. Un IDS (Intrusion Detection System) es, conceptualmente, un sniffer con cerebro: captura el tráfico igual, pero además lo interpreta — reensambla flujos TCP, entiende protocolos de aplicación y decide si lo que ve es normal o sospechoso. Si además puede cortar el tráfico malicioso en línea, hablamos de IPS (Intrusion Prevention System).

La segunda decisión de base es dónde escuchar. Hay tres colocaciones clásicas: en el propio firewall (que ya ve todo el tráfico entre red e Internet), en un puerto espejo (SPAN) de un switch gestionado que copia el tráfico hacia un sensor dedicado, o inline (el tráfico atraviesa físicamente el sensor, imprescindible para bloquear). Cada una tiene su papel, y lo veremos al llegar a pfSense.

Con la base común clara, vamos a lo que de verdad diferencia a los tres protagonistas: qué hacen con los paquetes una vez capturados.

2. Snort: el veterano de las firmas

Snort nació en 1998 y es, literalmente, el estándar que definió la categoría. Su base de trabajo es la detección por firmas: cada regla describe un patrón de ataque conocido — cabeceras, contenido del payload, puertos, secuencias — y el motor compara cada paquete y flujo contra miles de esas reglas. Cuando hay coincidencia, alerta (IDS) o bloquea (IPS). El flujo interno es un pipeline: decodificación del paquete → preprocesadores que normalizan y reensamblan (fragmentos IP, flujos TCP, HTTP) → motor de coincidencia de firmas → alerta.

Sus fortalezas son su ecosistema — mantenido por Cisco, con la mayor base de reglas y documentación del sector — y su sobriedad: funciona en hardware muy modesto. Su talón de Aquiles histórico era la arquitectura de un solo hilo, que se ahogaba en redes de alto caudal; Snort 3 lo modernizó con multihilo, pero llegó tarde a una carrera que su sucesor espiritual ya había ganado. La lección clave de Snort sigue siendo válida: las firmas detectan de maravilla lo conocido y no ven en absoluto lo desconocido. Un exploit publicado ayer con regla disponible hoy: detectado. Un ataque a medida sin firma: invisible.

3. Suricata: el sucesor multihilo

Suricata, desarrollado por la OISF desde 2009, tomó el modelo de Snort y lo reconstruyó para el hardware moderno. Su base de trabajo sigue siendo la detección por firmas — de hecho es compatible con las reglas de Snort, lo que le dio de salida todo el ecosistema del veterano — pero con tres saltos cualitativos:

• Multihilo nativo: reparte los flujos entre todos los núcleos de la CPU, con lo que digiere sin despeinarse caudales de 10 Gbps y superiores que atragantaban al Snort clásico.
• Conciencia de capa de aplicación: no solo mira paquetes; entiende HTTP, TLS, DNS, SMB o FTP como protocolos. Una regla puede decir «alerta si se descarga un ejecutable desde un dominio registrado hace menos de una semana», algo impensable mirando bytes sueltos. Puede incluso extraer los ficheros que viajan por la red para analizarlos.
• Salida EVE JSON: además de alertas, emite un registro estructurado de eventos (conexiones, peticiones HTTP, certificados TLS, consultas DNS) que se integra directamente con Elasticsearch, Grafana o cualquier SIEM. Es decir: aunque su corazón sean las firmas, ya te regala una parte del trabajo de análisis que veremos en Zeek.

Para la mayoría de empresas que parten de cero, Suricata es hoy la elección por defecto: rendimiento moderno, reglas gratuitas de calidad (ET Open), doble modo IDS/IPS y una comunidad muy viva.

4. Zeek: el analista que no busca nada (y por eso lo ve todo)

Zeek (antes conocido como Bro) juega otro deporte. Su base de trabajo no son las firmas: es el análisis integral del tráfico. Zeek observa pasivamente la red y transforma cada cosa que ve en registros estructurados y riquísimos: un log de todas las conexiones con su duración y volumen, otro de todas las consultas DNS, otro de cada certificado TLS negociado, cada fichero transferido, cada sesión HTTP. No te dice «he visto el ataque X»: te da la materia prima para que tú — o tus scripts, o tu motor de correlación — encontréis lo que ninguna firma describe.

Porque además de registrar, Zeek se programa: incluye un lenguaje de scripting orientado a eventos con el que expresar lógica del tipo «avísame si un host interno hace más de N consultas DNS a subdominios distintos del mismo dominio en un minuto» (el patrón típico de la exfiltración por DNS). Es la base de muchos productos comerciales de NDR (Network Detection and Response) y el compañero natural de los modelos de detección de anomalías con machine learning. Sus límites son igual de claros: solo detecta, nunca bloquea (no hay modo IPS), y exige más músculo: alguien tiene que mirar, correlacionar y entender esos logs.

5. Ejemplos claros: qué detecta cada enfoque

La diferencia de filosofía se entiende mejor con casos concretos de la vida real:

• Exploit conocido contra tu servidor web. Alguien lanza contra tu WordPress el exploit de un plugin vulnerable publicado el mes pasado. Snort/Suricata: firma disponible, alerta inmediata con nombre y apellidos del ataque (y bloqueo, en modo IPS). Zeek: lo registra como una petición HTTP más; sin lógica adicional, no distingue el ataque.
• Escaneo de puertos desde fuera. Una IP recorre metódicamente tus puertos. Los tres lo ven: Suricata/Snort con firmas de escaneo; Zeek con su detección de barridos incorporada. Empate.
• Beaconing de malware. Un equipo infectado con malware a medida llama a su servidor de control cada 60 segundos exactos con paquetes minúsculos. Firmas: silencio total — no existe firma para malware que nadie ha analizado. Zeek: el patrón de conexiones periódicas idénticas hacia el mismo destino brilla en el análisis de logs como un faro. Este es el caso que justifica su existencia.
• Exfiltración por DNS. Datos robados saliendo codificados en miles de consultas DNS a subdominios aleatorios. Firmas: alguna regla genérica puede saltar, con suerte. Zeek: volumen, entropía y frecuencia de consultas por dominio lo delatan con un script de veinte líneas.
• Certificado TLS sospechoso. Una conexión cifrada hacia un servicio con certificado autofirmado emitido ayer. Suricata: puede alertar sobre los metadatos TLS con reglas. Zeek: lo registra siempre en su log de TLS, listo para correlacionar.

La conclusión práctica que aplican los SOC serios: Suricata y Zeek juntos — el primero grita cuando pasa algo conocido, el segundo guarda el contexto para investigar lo desconocido y hacer forense cuando toca. No es elegir: es sumar.

6. pfSense: el firewall que te regala un IDS

Toda esta teoría se aterriza sorprendentemente rápido con pfSense, el firewall open source basado en FreeBSD que usamos como referencia para perímetros de pyme. Su gestor de paquetes incluye Snort y Suricata como paquetes oficiales, con interfaz gráfica para gestionarlo todo: instalación en dos clics, suscripción a las reglas gratuitas ET Open (o las de pago si quieres menos latencia de actualización), y selección de qué interfaces vigilar.

Decisiones prácticas que importan al montarlo:

• ¿Modo alerta o modo inline? El modo legacy (captura pasiva) solo avisa: ideal las primeras semanas, mientras ajustas reglas y aprendes qué es normal en tu red. El modo inline convierte a pfSense en IPS y bloquea en tiempo real — actívalo solo cuando las falsas alarmas estén domadas, o bloquearás a tus propios usuarios.
• ¿WAN o LAN? Vigilar la WAN te enseña el ruido de fondo de Internet (deprimente y poco útil); vigilar la LAN te muestra qué equipos internos generan cada conexión, con sus IPs reales antes del NAT. Para detectar el equipo infectado de los ejemplos anteriores, LAN siempre.
• ¿Y Zeek? No existe como paquete oficial de pfSense: lo habitual es montarlo en un pequeño sensor aparte (una VM o un mini-PC) colgado de un puerto espejo del switch, escuchando en paralelo sin tocar el tráfico. El firewall bloquea; el sensor analiza.
• Hardware: para una pyme con 100-500 Mbps reales, un equipo modesto con 4-8 GB de RAM mueve pfSense + Suricata con soltura. El presupuesto no es excusa, como ya contamos en ciberseguridad de servidores con poco presupuesto.

Un aviso de realista: instalar el paquete es la parte fácil. El valor está en el ajuste — deshabilitar las reglas que no aplican a tu entorno, revisar las alertas cada semana, y decidir qué se bloquea. Un IDS sin nadie que lo mire es un generador de logs que nadie lee, exactamente el error que ya señalamos al hablar de seguridad informática para pymes desde cero.

7. Afinado y operación: el trabajo real empieza tras instalar

\n\n

El error más común con los IDS no es técnico sino operativo: instalarlos, ver que generan alertas, y abandonarlos tres semanas después ahogados en ruido. La primera semana de un Suricata con reglas ET Open completas en una red normal puede producir miles de alertas diarias, de las cuales la inmensa mayoría son falsos positivos o ruido informativo: escáneres de Internet que golpean a todo el mundo, comprobaciones de certificados, tráfico de actualizaciones que coincide con patrones genéricos. Si nadie lo doma, el día que salte la alerta importante estará enterrada en la página cuarenta.

\n\n

El proceso de afinado que aplicamos en despliegues reales tiene cuatro movimientos. Uno: deshabilitar categorías enteras que no aplican a tu entorno — si no tienes servidores SCADA ni bases de datos Oracle expuestas, sus reglas solo generan ruido. Dos: crear reglas de supresión para los falsos positivos recurrentes identificados (ese monitor de marca blanca que hace peticiones raras pero legítimas cada minuto). Tres: clasificar lo que queda por severidad y decidir qué merece notificación inmediata (correo, Telegram, SIEM) y qué se revisa en el repaso semanal. Cuatro: automatizar la actualización de reglas — nuevas firmas aparecen a diario, y un IDS con reglas de hace seis meses es un museo.

\n\n

Y una métrica honesta para saber si el sistema está vivo: ¿cuántas alertas revisó una persona la semana pasada, y cuántas terminaron en una acción (bloquear, investigar un equipo, abrir un ticket)? Si la respuesta es cero durante un mes, el problema ya no es la herramienta. Nuestra recomendación mínima para pymes: 30 minutos semanales en calendario para revisar el panel de alertas, igual que se revisan las copias de seguridad.

\n\n

8. Suricata vs Snort vs Zeek: cuál elegir según tu situación

Pyme sin equipo de seguridad dedicado: Suricata dentro de pfSense, modo alerta las primeras semanas, reglas ET Open, y revisión semanal de alertas en calendario. Es el 80% del valor con el 20% del esfuerzo.

Empresa con IT propio y datos sensibles: lo anterior en modo inline (IPS) más un sensor Zeek en puerto espejo alimentando un panel de logs centralizado. Con esta pareja, tanto lo conocido como lo anómalo dejan rastro accionable — y de paso cubres controles de monitorización que piden marcos como la hoja de ruta de ciberseguridad de empresa o el ENS.

Hardware muy limitado o instalación heredada: Snort sigue siendo perfectamente digno — mismo modelo de firmas, menor consumo, ecosistema gigante. Solo asegúrate de estar en Snort 3 y de tener las reglas al día.

Conclusión

En la comparación Suricata vs Snort vs Zeek queda claro que no son tres marcas del mismo producto: son dos filosofías de detección. Las firmas (Snort, Suricata) te protegen de lo que el mundo ya conoce, con nombre, apellido y respuesta automática; el análisis de comportamiento (Zeek) te da los ojos para descubrir lo que nadie ha visto todavía. La arquitectura razonable para casi cualquier empresa hoy es Suricata como vigilante — idealmente integrado en pfSense, donde cuesta cero licencias y una tarde de trabajo — y, cuando la madurez lo permita, Zeek como memoria y lupa de la red.

El orden correcto, en cualquier caso, no cambia: primero un perímetro bien montado, luego visibilidad, luego detección afinada. Saltarse pasos es coleccionar herramientas; darlos en orden es construir seguridad.

Preguntas frecuentes sobre IDS open source

¿Necesito un IDS si ya tengo firewall y antivirus?

Cubren cosas distintas. El firewall decide qué conexiones se permiten; el antivirus vigila lo que se ejecuta en cada equipo; el IDS ve el tráfico que ambos dan por bueno. El malware moderno viaja precisamente por conexiones permitidas (HTTPS hacia fuera), y ahí el único que puede levantar la mano es el que mira la red.

¿Puedo usar las reglas de Snort en Suricata?

Sí, la compatibilidad con la sintaxis de reglas de Snort fue una decisión de diseño de Suricata y es una de las razones de su adopción masiva. Los conjuntos de reglas más usados (como ET Open) se publican para ambos motores. Solo las funciones más específicas de cada motor requieren reglas propias.

¿IDS o IPS: alerto o bloqueo?

Empieza siempre en modo IDS (solo alerta). Toda red genera falsos positivos las primeras semanas, y en modo IPS cada falso positivo es un servicio legítimo cortado. Cuando lleves un ciclo de ajuste fino y las alertas sean fiables, pasa a inline las categorías de mayor confianza (exploits conocidos, C2 confirmados) y deja el resto en alerta. Bloqueo gradual, no interruptor general.