Una distribución orientada a detección de intrusiones tiene sentido cuando necesitas algo más que alertas sueltas: quieres contexto, historial y pruebas forenses que aguanten una investigación. Security Onion combina visibilidad de red, telemetría de host, captura completa de paquetes y gestión de casos para que un pentest, un ejercicio purple team o una auditoría no se queden en intuición. En este artículo te explico qué hace, cómo se despliega en un laboratorio o en producción y qué límites reales conviene tener presentes antes de montarlo.
Lo esencial para entender su valor en una red real
- Une detección de red, telemetría de host, PCAP y gestión de casos en una sola plataforma.
- Suricata aporta alertas NIDS; Zeek añade contexto de protocolos; Elastic Agent cubre endpoints.
- Para hacking ético sirve para validar detecciones, medir impacto y documentar evidencias.
- Hay varios modos de despliegue: Import, Evaluation, Standalone y arquitecturas distribuidas.
- El cuello de botella real suele ser CPU, RAM, disco y la forma de capturar el tráfico.
Por qué encaja en hacking ético
Cuando trabajo un pentest o un ejercicio de red team, me interesa ver qué deja la actividad en la red y no solo qué “parece” haber pasado. Esta clase de plataforma encaja justo ahí: convierte un ataque, una simulación de exfiltración o un movimiento lateral en una secuencia investigable, con alertas, metadatos, paquetes y trazabilidad. Eso es importante porque una detección sin evidencia suele quedarse corta cuando toca explicar impacto a un cliente o a un equipo interno.
Yo la usaría, sobre todo, para tres cosas muy concretas:
- Validar reglas de detección después de una prueba ofensiva y ver si salta lo que debería.
- Correlacionar tráfico norte-sur y este-oeste para detectar C2, exploración interna o movimiento lateral.
- Documentar el incidente con PCAP y casos, no solo con una lista de alertas que luego nadie puede defender.
Cómo se organiza por dentro
La arquitectura está pensada para repartir funciones: captura, análisis, almacenamiento y respuesta no viven necesariamente en la misma máquina. Esa separación reduce cuellos de botella y permite escalar cuando la red crece. Yo lo resumo así: sensores para ver tráfico, agentes para ver hosts y una consola central para investigar.
| Bloque | Qué aporta | Por qué me importa |
|---|---|---|
| Sensores de red | Suricata genera alertas NIDS y Zeek añade metadatos de protocolos. | Me permiten ver actividad maliciosa, DNS raro, HTTP sospechoso o señales de exfiltración. |
| Visibilidad de host | Elastic Agent, Syslog y consultas vivas a endpoints con Osquery. | Cubre el hueco que deja el cifrado y me da señales del propio sistema comprometido. |
| Consola central | Alertas, dashboards, caza, PCAP, casos y gestión de nodos. | Convierte un mar de eventos en un flujo de investigación que se puede seguir. |
| Honeypots | Servicios señuelo que disparan alertas ante sondeos o conexiones no autorizadas. | Me ayudan a detectar reconocimiento y actividad que quizá no salte en otros controles. |
La clave no está solo en “tener herramientas”, sino en cómo se enlazan. Los datos acaban indexados y eso permite saltar de una alerta a un paquete concreto o a un host concreto sin perder el hilo. Esa es la diferencia entre una pila de logs y una base de trabajo útil para investigación.
Qué despliegue elegir según tu objetivo
La decisión importante no es “instalarlo o no”, sino qué modo encaja con el problema real. La documentación actual distingue escenarios muy distintos, y mezclarlos suele acabar en sobrecoste o en frustración porque el equipo se queda corto antes de tiempo.
| Modo | Cuándo lo usaría | Mínimo orientativo | Límite que asumo |
|---|---|---|---|
| Import | Para cargar PCAP o EVTX y empezar a aprender la consola. | 4 GB RAM, 2 CPU, 100 GB, 1 NIC | No admite agentes ni nodos adicionales. |
| Evaluation | Para probar tráfico en vivo desde un TAP o SPAN en un laboratorio. | 8 GB RAM, 4 CPU, 200 GB, 2 NIC | No lo trataría como base de producción. |
| Standalone | Para un laboratorio serio, una POC o una red pequeña con visibilidad de red y host. | 24 GB RAM, 4 CPU, 200 GB, 2 NIC | Escala menos que un entorno distribuido. |
| ManagerSearch | Para una pyme o un entorno pequeño con logs de host y algo de red. | 16 GB RAM, 8 CPU, 200 GB, 1 NIC | Ya exige pensar mejor en retención y crecimiento. |
| Distribuido | Para crecer con manager, search y sensores separados. | Depende de la carga | Es la vía correcta cuando el volumen ya no cabe bien en una sola máquina. |
Hay una regla práctica que no suelo romper: si solo quieres entender la consola o revisar material forense, empiezo por Import. Si necesitas tráfico en vivo, me muevo a Evaluation o Standalone. Y si ya piensas en producción, prefiero separar roles antes de forzar una máquina a hacer de todo.
Qué hardware y red necesita para rendir
Aquí es donde mucha gente se engaña: el problema rara vez es “si instala”, sino cuánto aguanta sin perder visibilidad. La guía actual deja claro que solo soporta x86-64, así que ARM queda fuera. Además, Suricata y Zeek son intensivos en CPU, y el proyecto maneja una referencia muy útil: unos 200 Mbps por worker. Traducido a algo más tangible, si tu enlace va realmente saturado a 1 Gbps, puedes acabar necesitando al menos 5 workers de Suricata y 5 de Zeek, más CPU extra para captura completa y otros servicios.
- RAM. Para evaluación rápida en VM, la documentación marca 8 GB en Eval, pero también deja entrever que 12 GB es un suelo más realista si no quieres pelearte con swap. En producción pequeña, yo no bajaría de 16 GB.
- Disco. La captura completa consume muchísimo. Un enlace medio de 50 Mbps puede llegar a requerir unos 540 GB por día solo para PCAP, así que la retención hay que planearla con números, no con optimismo.
- NIC y captura. Para tráfico vivo necesitas un TAP o un puerto SPAN bien configurado. En interfaces de sniffing, el instalador desactiva offloading para que la vista del tráfico sea fiel. Y sí, merece la pena usar tarjetas de red de calidad.
- Virtualización. Se puede virtualizar, pero si monitoreas bastante tráfico, yo prefiero hardware físico dedicado. Es la forma más limpia de evitar que el host y otras VMs compitan por recursos.
- Retención. La propia guía recomienda no pasarse de unos 30 días de índices calientes. Si necesitas más histórico, hay que pensar en almacenamiento y arquitectura desde el principio.
Mi lectura es simple: cuanto más cerca quieras estar de la verdad del tráfico, más cuidado tendrás que poner en CPU, disco y origen de captura. Ese es el punto donde la herramienta deja de ser “ligera” y empieza a parecerse a una plataforma seria.
Dónde brilla y dónde conviene ser honesto
Lo que mejor hace esta plataforma es juntar piezas que en muchas organizaciones viven separadas: red, host, búsqueda forense y gestión del caso. Para un equipo de hacking ético, eso vale oro porque reduce el tiempo entre “hemos probado algo” y “tenemos evidencia de lo que pasó”. También me gusta que contemple despliegues airgap, porque no todos los entornos de prueba tienen salida a Internet.
Pero conviene ser realista con sus límites:
- No es magia. Si el sensor no ve bien el tráfico, no hay consola que lo arregle.
- Exige tuning. Las reglas, la retención y la carga de eventos hay que afinarlas; si no, se llena de ruido o se queda corta.
- No sustituye un EDR puro si tu foco es solo endpoint. Aquí gana cuando quieres correlación entre red y host.
- La edición mínima no es el destino final. Sirve para aprender o validar, no para asumir que producción va a ir igual de bien.
Yo la uso cuando necesito profundidad forense y una visión más completa del incidente. Si solo quiero inventario de endpoints o un monitor básico de máquinas, probablemente elegiría algo más simple. Pero si el objetivo es entender el ataque de extremo a extremo, aquí hay bastante más valor que en una pila de logs aislados.
Cómo la arrancaría hoy en un laboratorio pequeño
Si tuviera que empezar desde cero, no intentaría montar un grid complejo el primer día. Haría algo más sobrio y más útil:
- Empezaría por Import si solo quiero analizar PCAP o EVTX. Es la forma más rápida de aprender la consola sin sobredimensionar nada.
- Pasaría a Evaluation o Standalone solo si necesito tráfico en vivo. Para un laboratorio serio, me inclino antes por Standalone que por apurar una VM pequeña.
- Conectaría una sola fuente de tráfico limpia, idealmente un TAP o un SPAN bien controlado, y no mezclaría demasiadas entradas al principio.
- Definiría tres detecciones iniciales: escaneo de puertos, posible C2 y exfiltración básica. Son más útiles que perseguir decenas de reglas sin contexto.
- Revisaría primero Alerts, luego Hunt y después PCAP. Cuando ya tenga criterio, usaría Cases para dejar trazabilidad y compartir hallazgos.
Si el entorno no tiene salida a Internet, el modo airgap resuelve esa parte; y si el proyecto crece, Security Onion rinde mejor cuando separas manager, search y sensores en lugar de exprimir una sola máquina. Esa es la lectura práctica que yo haría en 2026: una base muy sólida para caza, defensa y análisis forense, siempre que la montes con el tamaño adecuado.
