IDS/IPS con Suricata en OPNsense: configuración sin destruir el rendimiento

Suricata bien afinado te avisa de lo que importa y no se come la CPU. Mal puesto, te ralentiza la red, te inunda de logs y terminas desactivándolo. Esta guía muestra cómo activarlo, qué reglas cargar, qué tocar y qué dejar en paz.

1. Qué es Suricata y por qué OPNsense lo integra

Suricata es un motor de detección y prevención de intrusiones open source. Lee cada paquete de la red, lo compara con miles de reglas y, si alguna casa, registra el evento (modo IDS) o directamente descarta el paquete (modo IPS). La documentación oficial de OPNsense lo describe como un sistema de inspección profunda de paquetes “wire speed” basado en Suricata y acelerado por Netmap.

OPNsense lo integra con un plugin maduro que se controla desde Services ‣ Intrusion Prevention. Tiene cuatro modos de captura:

• PCAP live move (IDS): usa la captura clásica de libpcap, solo genera alertas.
• Netmap (IPS): usa el framework Netmap de FreeBSD, captura y descarta a velocidad nativa, requiere NICs compatibles.
• Divert (IPS): redirige paquetes vía reglas de firewall, no requiere NICs especiales pero es el menos eficiente.

La diferencia entre IDS e IPS es importante: en IDS Suricata solo ve, en IPS puede bloquear. Pasar de IDS a IPS es el momento en el que dejas de tener un observador y empiezas a tener un guardián.

2. Antes de activar: saber qué se puede y qué no

Activar Suricata cambia el rendimiento de OPNsense. El coste depende del procesador, el driver de la NIC, el caudal real, el tamaño de los paquetes, el modo de captura y las reglas activas. Por eso no sirve prometer una cifra universal: mide primero tu línea base y añade inspección por etapas.

Comprueba primero el hardware:

• CPU con varios núcleos y buen rendimiento por núcleo. Suricata puede repartir trabajo, pero una cola saturada seguirá limitando el caudal.
• NIC y driver compatibles con el modo de captura elegido. Revisa la lista y las notas de OPNsense antes de activar IPS en producción.
• RAM con margen. El consumo cambia con los conjuntos de reglas y el tráfico; observa el sistema antes y después en lugar de fijar un mínimo arbitrario.

3. Instalar el plugin y aplicar el primer ajuste

Ve a System ‣ Firmware ‣ Plugins e instala os-intrusion-detection-content-et-open y os-intrusion-detection-content-et-pro-telemetry (opcional, telemetría para reglas comerciales). El plugin base os-intrusion-detection ya viene cuando seleccionas estos.

Una vez instalado, el menú Services ‣ Intrusion Prevention aparece. Antes de tocar nada, revisa Interfaces ‣ Settings y desactiva cualquier opción de offloading (hardware checksum offload, LRO, TSO). La propia documentación advierte de que, con IPS, dejar el offloading activo provoca reglas que no se disparan y falsos negativos. Esto es crítico: si lo dejas, perderás tráfico legítimo y Suricata verá paquetes rotos.

4. Elegir la interfaz correcta

Otro punto donde se suele fallar: poner Suricata en la WAN. La documentación oficial es clara al respecto:

“Si capturas en la interfaz WAN solo verás tráfico después de la traducción de direcciones. No sabrás qué máquina interna fue la afectada.”

En homelab, coloca Suricata en las interfaces internas: la LAN, la VLAN de servidores o las que te interesen. La WAN queda fuera porque el firewall de OPNsense ya deniega el tráfico entrante no solicitado; un IPS ahí duplica trabajo y encima pierde contexto.

Interfaz	¿Activar Suricata?	Por qué
WAN	No	El firewall ya bloquea, además pierdes la IP origen real por NAT
LAN	Sí	Ves todo el tráfico de los PCs
SERVERS	Sí, en modo IDS	Útil para monitorizar el NAS, sin riesgo de auto-bloqueo
GUEST	Opcional, IDS	Mucho ruido, normalmente no vale la pena
IOT	Muy recomendado	Aquí es donde se ven exploits reales contra dispositivos vulnerables

Si usas VLANs sobre una interfaz padre, la documentación oficial recuerda que hay que activar IPS en la interfaz padre, no en las VLANs hijas. Netmap ve todo el tráfico del parent.

5. Modo IDS o IPS: por dónde empezar

Si es la primera vez con Suricata, empieza en modo IDS:

1. En Services ‣ Intrusion Prevention ‣ General marca “Enabled”.
2. En Capture mode elige “PCAP live move (IDS)”. No requiere NIC especial.
3. En Interfaces marca la LAN o la VLAN de servidores.
4. Pattern matcher: deja “Aho–Corasick” por defecto. Si la plataforma soporta Hyperscan, cámbialo luego; la doc oficial lo marca como la mejor opción cuando está disponible.
5. Aplica cambios y espera 24-48 horas para tener una idea del ruido generado.

Pasar a IPS solo cuando ya entiendas qué reglas disparan alertas y cuáles son legítimas. Cambiar a “Netmap (IPS)” o “Divert (IPS)” implica que una regla mal configurada puede cortar el acceso a un servicio en producción.

6. Reglas: qué descargar, qué no, cómo filtrar

El primer error habitual es instalar todas las reglas disponibles. Suricata te permite descargar listas como ET Open, ET Pro, Abuse.ch, SSL Blacklist, Feodo Tracker. La gracia no es tenerlas todas, sino quedarte con las que aplican a tu tráfico.

6.1 Conjuntos recomendados para empezar

• ET Open / Emerging Threats Open: gratis, mantenido por Proofpoint, contiene miles de reglas actualizadas diariamente. Cubre exploits, malware conocido, actividad de CnC, escaneos, etc.
• Abuse.ch SSL Blacklist: añade dominios y hashes de malware a una lista negra.
• Feodo Tracker: lista de IPs de servidores C2 conocidos, útil en modo drop.
• ET Pro (de pago): mejor cobertura y menos falsos positivos que ET Open, pero requiere licencia.

6.2 Policies, el mecanismo de control de OPNsense

Desde la versión 21.1, OPNsense organiza las reglas mediante Policies, que sustituyen los antiguos filtros del download. Una policy define:

• A qué ruleset aplica (ET Open, Abuse.ch, etc.)
• Qué acción tendrán las reglas (disabled, alert o drop)
• Qué metadata de la regla tiene que casar (producto afectado, severidad, deployment)

Ejemplo de policy razonable para un homelab:

Descripción	Ruleset	Action	Metadata filter
ET Open – malware crítico	ET Open	drop	severity: critical, classtype: trojan-activity
ET Open – exploits web	ET Open	alert	classtype: web-application-attack
ET Open – escaneos	ET Open	drop	classtype: attempted-recon
ET Open -.rules obsoletas o muy ruidosas	ET Open	disabled	classtype: misc-activity
Feodo Tracker – CnC	Feodo Tracker	drop	—
SSL Blacklist – dominios	Abuse.ch	drop	—

El solapamiento se resuelve por prioridad: la policy con el número más bajo gana. Empieza en modo alert y solo cambia a drop cuando estés seguro.

6.3 Suprimir firmas que sabes que son falsos positivos

En Services ‣ Intrusion Prevention ‣ User defined puedes añadir reglas con suppress que cancelan la generación de alertas para SID concretos. Por ejemplo, si el monitor de un servidor dispara alertas constantemente, ahí lo silencias, no en el ruleset global.

7. Patrones y rendimiento: lo que marca la diferencia

Hay tres parámetros que controlan el coste de CPU:

• Pattern matcher: Aho–Corasick por defecto. Hyperscan, cuando está disponible (CPU con SSE3 y AVX2), multiplica el rendimiento por 2-3x. La doc oficial lo recomienda sobre cualquier otro.
• Default packet size: si subes este valor, Suricata procesa más bytes por paquete pero gasta más CPU. Déjalo en 1500 salvo necesidad real.
• Listeners (en modo Divert): igual al número de CPUs para paralelizar.

Para saber dónde te duele, la documentación sugiere monitorizar:

top -H | grep suricata
# Verás el uso de CPU por hilo (cada hilo de Suricata) — Suricata escala por cores

Si un core está al 100% mientras los otros están ociosos, tienes un cuello de botella. En ese caso reduce el número de reglas activas, no bajes el pattern matcher: ahí estás perdiendo lo único que te da velocidad.

8. Hardware offloading, Netmap y compatibilidad

Ya lo mencionamos al instalar, pero conviene recordarlo: todo offloading por hardware debe estar desactivado. En Interfaces ‣ Settings desmarca:

• Hardware CRC
• Disable hardware checksum offload
• Disable hardware TCP segmentation offload
• Disable hardware large receive offload

Si tu NIC no es compatible con Netmap, puedes forzar el modo emulado creando un tunable en System ‣ Settings ‣ Tunables con nombre dev.netmap.admode y valor 1. Pierdes rendimiento, pero funciona.

9. Logs y alertas: qué mirar y qué ignorar

Suricata en OPNsense puede enviar logs a syslog en dos formatos:

• fast.log: una línea por alerta, formato compacto, fácil de grepear.
• EVE (Extensible Event Format): JSON con todo el contexto (payload, IP, puerto, SNI, etc.). Es el formato que mola si vas a montar Grafana o un SIEM.

En System ‣ Settings ‣ Logging / Targets puedes crear un destino remoto, filtrar por aplicación “suricata” y enviarlo a una herramienta de monitorización. Si tienes un stack de monitorización en casa, este artículo sobre monitorización con Grafana y Prometheus explica cómo conectarlo todo.

Truco para no ahogarte: empieza con EVE solo en local y un script de rotación diaria. Cuando tengas claros los eventos que te importan, añade el destino remoto.

10. Errores típicos y cómo recuperarse

• Activar IPS el primer día y quedarse sin acceso al firewall. Si bloqueas tu propia IP, la única salida es la consola. Mitigación: ten un OPNsense de respaldo o sesión local antes de pasar a drop.
• Cargar todas las reglas y no filtrar. Ruido constante, CPU al 100%, alertas inútiles.
• Olvidar desactivar el offloading. Las reglas no se disparan, los paquetes se descartan sin alerta y todo parece mágico.
• Poner Suricata en WAN. Pierdes contexto por NAT y duplicas el trabajo del firewall.
• No usar suppress. Algunos servicios legítimos (VoIP, multicast, plugins de CMS) disparan firmas que tienes que silenciar manualmente.

Si Suricata empieza a comportarse raro, el primer comando de diagnóstico es:

# Logs en vivo del plugin
pfSsh.php playback svc-suricata
# O directamente sobre el binario
suricata -i igc0 -c /usr/local/etc/suricata/suricata.yaml -v

Ahí ves qué regla está bloqueando y por qué. La interfaz igc0 es la que corresponda en tu caso.

Conclusiones

Suricata en OPNsense es una herramienta adulta, no un capricho de seguridad. La clave es empezar en IDS, quedarse solo con las reglas que aplican a tu tráfico, desactivar offloading, usar Netmap solo si la NIC lo soporta y subir a IPS cuando ya confías en el ruido de fondo. Hecho así, te avisa de los ataques reales sin convertirse en otro problema que gestionar.

Preguntas frecuentes

Lee también

• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux
• Guía Definitiva para Sysadmins: Configuración de Bonding de Interfaces de Red en Linux
• Guía Definitiva: Configura AppArmor para Proteger tus Aplicaciones en Linux
• Configura Wireguard en tu teléfono: Accede a todo desde cualquier lugar