Snort vs Suricata: el otro debate de IDS.

Pregunta a cinco profesionales "¿Snort o Suricata?" y obtendrás cinco respuestas distintas, la mayoría desfasadas una década. Snort, lanzado por primera vez por Martin Roesch en 1998 y luego mantenido por el equipo Talos de Cisco, escribió el formato de firmas en el que todo el sector sigue escribiendo reglas — alert, msg, sid, flow, todo ello. Suricata, construido por la Open Information Security Foundation a partir de 2009, tomó ese linaje y reconstruyó el motor por debajo para un hardware que la arquitectura original de Snort nunca tuvo que prever: máquinas de varios núcleos moviendo decenas de gigabits por segundo. Ninguna de las dos herramientas está obsoleta. La verdadera pregunta es qué arquitectura encaja con la red, y con el equipo, que tienes delante.

Veredicto rápido

En qué se diferencian de verdad por dentro

El clásico motor 2.x de Snort ejecuta la detección en un único hilo por proceso. Ese era un diseño razonable a finales de los 90 y siguió siendo adecuado para la mayoría de los enlaces corporativos durante años, pero significaba que escalar Snort para saturar una interfaz de 10G, 40G o más rápida exigía añadir capacidad extra desde fuera — ejecutar varias instancias de Snort tras un balanceador de carga, o repartir manualmente el tráfico entre las colas de la NIC y fijar una instancia a cada una. Funciona, pero es un apaño operativo, no una capacidad nativa. Snort 3, el motor reescrito que alcanzó disponibilidad general en 2021, es una mejora genuina en este punto: añadió procesamiento de paquetes multihilo real y puede usar varios núcleos de forma nativa dentro de un único proceso en ejecución. Eso cierra gran parte de la brecha histórica, y merece reconocerse en lugar de repetir el viejo estribillo de "Snort es de un solo hilo" como si nada hubiera cambiado. También conviene ser honesto: una parte importante de los despliegues de Snort en producción siguen ejecutando la rama 2.9.x, donde la vieja limitación aún se aplica por completo.

Lo que Snort siempre ha tenido, y aún tiene en mayor cantidad que nadie, son reglas y gente que las escribe. La sintaxis que introdujo es la lengua franca de la detección por firmas en red, y Cisco Talos mantiene uno de los feeds de reglas de grado comercial más grandes y curados con más actividad del sector, construido sobre décadas de ajuste acumulado y supresión de falsos positivos.

Suricata se diseñó desde el primer día para ejecutar múltiples hilos repartidos entre todos los núcleos de CPU disponibles en un único proceso, usando métodos de captura de paquetes como AF_PACKET, PF_RING o RSS/hashing simétrico a nivel de NIC para repartir el tráfico entrante entre hilos de trabajo sin que un operador tenga que montar un balanceo de carga externo para lograrlo. Ese diseño nativo es la mayor diferencia estructural entre los dos motores.

La otra diferencia estructural es la profundidad del análisis de protocolos. Suricata trata la inspección de la capa de aplicación — HTTP, TLS, DNS, SMB y más — como una parte central del motor en lugar de como un añadido opcional, y registra los metadatos extraídos directamente en su salida eve.json: sujeto y emisor del certificado TLS, ventanas de validez del certificado, fingerprints TLS JA3/JA3S y extracción completa de ficheros sobre protocolos como HTTP y SMB, todo sin necesitar un montón de reglas personalizadas adicionales para activarlo. Ese registro más rico y estructurado es una ventaja operativa genuina para cualquiera que alimente un SIEM aguas abajo.

Nada de eso deja sin valor la inversión existente en Snort si un equipo cambia de motor. Suricata se construyó deliberadamente para consumir la misma sintaxis de reglas que Snort y los conjuntos de reglas de Emerging Threats (ET), añadiendo por encima solo un modesto conjunto de palabras clave específicas de Suricata. En la práctica, la inmensa mayoría de un conjunto de reglas de Snort o ET ya ajustado se carga y se ejecuta en Suricata prácticamente tal cual — años de ajuste y supresión de firmas no se tiran a la basura solo porque haya cambiado el motor de debajo.

Un ejemplo mínimo hace tangible ese linaje compartido. Esta misma línea de regla es sintaxis válida para ambos motores:

# una regla mínima, válida en ambos motores — señala una ráfaga de intentos de conexión SSH desde un mismo origen
alert tcp any any -> $HOME_NET 22 (msg:"SSH brute-force attempt"; flow:to_server,established; threshold:type threshold, track by_src, count 5, seconds 60; sid:1000001; rev:1;)

# action=alert  proto=tcp  src=any:any -> dst=$HOME_NET:22
# opciones: estado de flow, threshold (dispara una vez por cada 5 aciertos en 60s desde un mismo src), sid/rev para el seguimiento

Dónde se queda corta cada una

La mayor debilidad estructural de Snort ha sido exprimir todo el valor del hardware con muchos núcleos en enlaces de muy alto rendimiento. Incluso con el procesamiento de paquetes multihilo de Snort 3, la mayoría de los benchmarks publicados y de las recomendaciones de los fabricantes siguen apuntando a que Suricata se pone por delante en rendimiento bruto multigigabit por máquina. Y para la parte significativa de la base instalada que sigue ejecutando la rama 2.9.x, el apaño sigue siendo el mismo de siempre: ejecutar varios procesos de Snort ligados a distintas interfaces o colas de NIC. Más piezas móviles que gestionar, no un techo técnico infranqueable, pero sí un peaje operativo real.

La configuración por defecto de Suricata no es ligera. El análisis completo de protocolos, el fingerprinting TLS y la extracción de ficheros cuestan CPU y memoria incluso en un despliegue que no necesita el registro extra, y afinar bien Suricata en hardware limitado — un appliance, una máquina de una oficina remota, una VM con recursos capados — exige un ajuste deliberado: afinidad de hilos y CPU, dimensionado del ring buffer y una decisión consciente sobre qué tipos de log de eve.json merece la pena conservar de verdad. La base de código de Suricata también avanza más rápido y abarca más terreno que la de Snort, lo cual es bueno para seguir el ritmo de los protocolos nuevos, pero implica cambios más frecuentes de una versión a otra en la sintaxis de configuración, el comportamiento de las palabras clave y los formatos de salida por defecto que los operadores tienen que vigilar en cada actualización.

El veredicto que sobrevive a producción

Pon esas concesiones junto al hardware moderno y la balanza se inclina con bastante claridad: la mayoría de los equipos que levantan hoy un despliegue nuevo, sobre máquinas de varios núcleos inspeccionando decenas de gigabits, se decantan por Suricata por su multihilo nativo y por la visibilidad a nivel de protocolo — TLS/JA3, extracción de ficheros, metadatos ricos de DNS y HTTP — que viene integrada en el motor en lugar de acoplada después. Snort sigue siendo una opción totalmente válida y bien respaldada, sobre todo allí donde un equipo ya tiene años de reglas ajustadas, listas de supresión y experiencia institucional con Snort acumulados, donde arrancar un stack de detección que funciona para perseguir una ventaja de arquitectura rara vez sale rentable. Esto no va de que una herramienta esté obsoleta. Va de emparejar la arquitectura del motor, y la memoria muscular operativa que ya hay en casa, con el hardware que de verdad hace la inspección.