Introducción al Problema#
Un firewall mira las puertas. Un IDS/IPS mira lo que pasa por las puertas y también dentro de la casa. Es una distinción crítica que muchas organizaciones no entienden hasta que sufren un incidente.
El firewall trabaja con reglas estáticas: este tráfico sí, este tráfico no, basado en origen, destino y puerto. Es eficiente, pero ciego ante el contenido. No sabe si el tráfico HTTPS en el puerto 443 es una conexión legítima a un servidor bancario o un malware exfiltrando datos. No detecta si alguien que ya está adentro está haciendo reconocimiento de la red interna. No identifica patrones de ataque conocidos dentro de flujos permitidos.
Un IDS (Intrusion Detection System) es el sensor que analiza el tráfico en profundidad, reconoce patrones de ataque conocidos y comportamientos anómalos, y genera alertas. Un IPS (Intrusion Prevention System) hace lo mismo pero además tiene la capacidad de bloquear el tráfico malicioso en tiempo real.
La diferencia es sutl pero importante: el IDS ve y avisa; el IPS ve, avisa y actúa. La elección entre uno y otro no es solo técnica — también involucra el riesgo de falsos positivos (bloquear tráfico legítimo), que en producción puede interrumpir operaciones.
Caso Real o Ejemplo Cotidiano#
En noviembre de 2025, una empresa de logística con 180 empleados descubrió, durante una auditoría de rutina, que un atacante había estado presente dentro de su red durante 23 días. Durante ese período accedió a correos internos, planillas de costos y contratos con clientes.
El atacante había ingresado a través de una credencial comprometida de un empleado que usaba la misma contraseña en un servicio externo que fue víctima de un data breach. Con esa credencial, accedió al correo corporativo de forma completamente legítima para el firewall perimetral: era tráfico HTTPS normal, desde una IP no bloqueada.
Una vez adentro, comenzó a hacer reconocimiento de la red interna: escaneos de puertos a otros equipos, consultas de DNS inusuales, descarga de grandes volúmenes de archivos desde el servidor de archivos. Todo tráfico interno — el firewall perimetral ni lo veía.
Un IDS con reglas adecuadas hubiera generado alertas en los primeros días: el escaneo interno es un patrón reconocible, las consultas DNS masivas son una firma de reconocimiento, el volumen de descarga de archivos es una anomalía behavioral. Sin esa visibilidad, 23 días pasaron sin que nadie notara.
El costo estimado en contratos renegociados y pérdida de confidencialidad: alrededor de USD 120.000.
Riesgos para la Empresa#
| Sin IDS/IPS | Consecuencia |
|---|---|
| Tráfico lateral interno sin análisis | Movimiento lateral de atacantes invisible durante semanas |
| Sin detección de patrones de ataque | Exploits conocidos ejecutados sin que nadie lo sepa |
| Sin análisis de comportamiento | Exfiltración de datos pasa como tráfico "normal" |
| Sin correlación de eventos de red | Imposible reconstruir la línea de tiempo de un incidente |
| Firewall como único control | Falsa sensación de seguridad total con visibilidad parcial |
Explicación Técnica Sencilla#
IDS vs IPS: la diferencia concreta#
DETECCIÓN ACCIÓN
IDS: Analiza el tráfico → Genera alerta → Operador decide qué hacer
IPS: Analiza el tráfico → Genera alerta → Bloquea automáticamenteEl IPS tiene la ventaja de respuesta inmediata. La desventaja: si genera un falso positivo (identifica como malicioso algo legítimo), puede interrumpir operaciones. Por eso muchas organizaciones empiezan en modo IDS (solo detección) hasta conocer bien su tráfico y reducir los falsos positivos antes de activar el bloqueo automático.
Snort vs Suricata vs Zeek: ¿cuál usar?#
Snort es el IDS/IPS open source más histórico (1998, ahora mantenido por Cisco Talos). Usa un motor single-thread, es estable y tiene una comunidad enorme. Sus reglas son el estándar de facto de la industria — muchas herramientas son compatibles con formato de reglas Snort.
Suricata es el sucesor moderno (2009, Open Information Security Foundation). Multi-thread desde el núcleo, mejor rendimiento en hardware moderno, soporte nativo de protocolos (HTTP, TLS, DNS, SMB), detección de archivos, y un motor de scripting Lua para reglas avanzadas. Para instalaciones nuevas, Suricata es la recomendación generalizada del sector.
Zeek (antes Bro) es conceptualmente diferente: no es principalmente un IDS basado en firmas sino un analizador de tráfico de red que genera logs estructurados de todo lo que pasa. No genera alertas por firmas de ataque (aunque puede), sino que registra conexiones, extracciones de archivos, sesiones DNS/HTTP/TLS en un formato fácilmente analizable. Es el complemento ideal de Suricata: Suricata detecta ataques conocidos, Zeek da contexto y visibilidad completa.
Tráfico de red
├── Suricata → Detección de firmas + anomalías → Alertas
└── Zeek → Logs estructurados de todo → Análisis forense / SIEMReglas personalizadas: el 20% que marca la diferencia#
Las reglas por defecto cubren miles de ataques conocidos. Pero las reglas personalizadas, adaptadas a tu entorno específico, son las que detectan amenazas relevantes para tu negocio. Algunos ejemplos:
# Alerta si alguien desde la red interna hace un escaneo de puertos
alert tcp $HOME_NET any -> $HOME_NET any (msg:"Escaneo interno sospechoso";
flags:S; threshold: type both, track by_src, count 50, seconds 10;
sid:9000001; rev:1;)
# Alerta si un host interno hace consultas DNS a dominios de lista negra
alert dns $HOME_NET any -> any 53 (msg:"Consulta DNS a dominio malicioso conocido";
dns.query; content:"malware-c2-domain.com"; sid:9000002; rev:1;)Integración con SIEM#
Un IDS sin integración con un sistema de correlación (SIEM) genera alertas que se pierden en logs no revisados. La cadena completa es:
Red → Suricata/Zeek → SIEM (Wazuh/ELK) → Correlación → Alerta operador
Cómo Prevenirlo#
-
Ubicá los sensores en los puntos correctos de la red: El sensor debe ver el tráfico relevante. Para tráfico perimetral: en el segmento entre el firewall y la red interna. Para tráfico lateral: en switches core con port mirroring (SPAN). Sin visibilidad del segmento correcto, el IDS es ciego.
-
Empezá en modo IDS (solo detección) antes de activar el bloqueo: Corré Suricata en modo alertas durante dos semanas. Revisá los falsos positivos, ajustá las reglas, entendé el tráfico legítimo de tu red. Recién entonces activá el modo IPS.
-
Mantené las reglas actualizadas automáticamente: Snort y Suricata tienen feeds de reglas que se actualizan diariamente (Emerging Threats — ET Open es gratuito y excelente). Configurá actualizaciones automáticas para que el sensor conozca los exploits más recientes.
bash# Actualización automática de reglas ET Open con suricata-update suricata-update --suricata-conf /etc/suricata/suricata.yaml # Agregar a cron para ejecución diaria 0 2 * * * /usr/bin/suricata-update && systemctl reload suricata -
Implementá Zeek como complemento para logs de red estructurados: Los logs de Zeek (conn.log, dns.log, http.log, ssl.log, files.log) son invaluables para investigación forense y correlación en SIEM. Sin ellos, cuando ocurre un incidente, la reconstrucción de la línea de tiempo es casi imposible.
-
Integrá las alertas con tu sistema de notificaciones: Un IDS que genera alertas en un archivo de log que nadie lee es inútil. Configurá envío de alertas a Slack, email, o tu SIEM para los eventos de severidad alta/crítica.
-
Considerá Security Onion para una implementación integrada: Security Onion es una distribución Linux que integra Suricata, Zeek, Wazuh y una interfaz de investigación en un solo instalador. Es la forma más rápida de tener un IDS/IPS profesional funcionando.
Herramientas Recomendadas#
Suricata (suricata.io): IDS/IPS open source mantenido por la OISF (Open Information Security Foundation). Multi-thread, soporte nativo de protocolos de capa 7, extracción de archivos, scripting Lua. Reemplaza a Snort en la mayoría de las instalaciones nuevas. Gratuito y con soporte comercial disponible. Compatible con las reglas del formato Snort.
Snort (snort.org): El IDS/IPS open source original, ahora mantenido por Cisco Talos. Motor single-thread más simple que Suricata, pero con décadas de madurez y la base de reglas Talos (gratuita para uso personal/educativo, con suscripción para actualizaciones en tiempo real). Sigue siendo ampliamente usado y la referencia en terms de formato de reglas.
Zeek (zeek.org): Analizador de tráfico de red de alta fidelidad. No es un IDS tradicional basado en firmas sino un motor de análisis que genera logs estructurados detallados de todos los protocolos. Fundamental para correlación en SIEM y análisis forense. Gratuito y open source.
Security Onion (securityonionsolutions.com): Distribución Linux para monitoreo de seguridad de red que integra Suricata, Zeek, Wazuh, Elastic Stack y una interfaz web (SOC Console) en un instalador único. La forma más eficiente de tener visibilidad completa de la red sin integrar manualmente docenas de componentes. Gratuito para uso no comercial; versión empresarial con soporte disponible.
Checklist Final#
- Los sensores IDS/IPS cubren el tráfico perimetral (entre internet y red interna)
- Los sensores cubren el tráfico lateral interno (switch core con port mirroring)
- Las reglas de detección (ET Open o similares) se actualizan automáticamente
- El sistema empezó en modo IDS (solo alertas) antes de activar bloqueo automático
- Los falsos positivos del primer mes están documentados y las reglas ajustadas
- Las alertas de severidad alta/crítica llegan en tiempo real al equipo responsable
- Zeek o equivalente genera logs estructurados de conexiones, DNS y HTTP/TLS
- Los logs se envían a un SIEM para correlación (no solo se guardan en el sensor)
- Existen reglas personalizadas para patrones de tráfico sospechoso propios del entorno
- Se hacen revisiones periódicas de las alertas para identificar patrones no automatizados
- El sensor tiene capacidad de procesamiento suficiente para el volumen de tráfico de la red
CVE / Vulnerabilidades Relacionadas#
CVE-2026-20122 — Cisco ASA / Firepower (Crítico)#
Esta vulnerabilidad ilustra perfectamente por qué el IDS/IPS debe ser independiente del firewall: afecta a los firewalls Cisco ASA y Firepower, permitiendo ejecución de código con privilegios elevados en el dispositivo. Si el IDS/IPS fuera una función del mismo equipo comprometido, ambas capas de defensa caerían simultáneamente.
La arquitectura correcta es tener el IDS/IPS como componente separado y dedicado. Si el firewall es comprometido por CVE-2026-20122 (u otra vulnerabilidad crítica), el sensor IDS sigue operando y puede detectar el comportamiento anómalo del dispositivo comprometido — tráfico de comando y control, modificación de reglas, exfiltración de credenciales VPN.
Este principio de defensa en profundidad — no depender de una única capa de seguridad — es la razón por la que ningún dispositivo de seguridad debe ser el único punto de visibilidad de la red.
Conclusión y CTA#
El firewall controla quién puede entrar. El IDS/IPS te dice qué está pasando adentro — y puede reaccionar antes de que sea tarde. En el caso real que describimos, 23 días de presencia de un atacante sin detección. Con Suricata correctamente configurado, el escaneo interno hubiera generado alerta en el día 1 o 2.
El punto de entrada más accesible para una PyME es Security Onion: una VM, un instalador, y en pocas horas tenés Suricata + Zeek + dashboard de alertas funcionando. El costo de implementación es bajo; el valor de la visibilidad que aporta, incalculable.
¿Necesitás ayuda para planificar la arquitectura de monitoreo de red para tu organización? Hablá con nuestro equipo o seguí con el siguiente artículo: SIEM sin presupuesto millonario: implementá Wazuh paso a paso.