nTopNG: Monitorización avanzada de tráfico de red

Introducción
nTopNG es una sonda de análisis de tráfico de red orientada a ofrecer visibilidad en tiempo real y métricas históricas sobre el comportamiento de una infraestructura. Permite identificar hosts, flujos, protocolos y patrones de consumo, aportando contexto operativo más allá del simple conteo de paquetes.
Dentro del stack se integra como herramienta de observabilidad a nivel de host, especialmente útil para analizar tráfico real de las interfaces físicas del sistema. No sustituye a un IDS ni a herramientas como CrowdSec o el firewall, sino que complementa la capa de seguridad aportando análisis agregado y clasificación por aplicación.
El despliegue actual utiliza Redis como backend local de almacenamiento y se ha simplificado para eliminar NAT, redes bridge innecesarias y exposición de puertos.
Enfoque general / Arquitectura
Tanto nTopNG como Redis se ejecutan en 
network_mode: host.
Esta decisión elimina completamente el uso de redes bridge de Docker y cualquier traducción de puertos interna. Ambos servicios comparten la pila de red real del sistema y se comunican exclusivamente mediante loopback (
127.0.0.1).
Arquitectura resultante:
ntopng en modo host para captura directa de tráfico.
redis en modo host como backend local.
Redis enlazado únicamente a 
127.0.0.1.
Volúmenes persistentes para datos de ambos servicios.
Flujo simplificado:
ntopng (host) → 127.0.0.1:6379 → redis (host)
Sin NAT.
Sin redes intermedias.
Sin puertos Docker publicados.
Este enfoque reduce complejidad, elimina dependencias de red internas de Docker y minimiza la superficie expuesta.
Requisitos previos
Interfaces físicas válidas del host (por ejemplo 
enp4s0, 
enp5s0, etc.).
Permisos suficientes para captura de tráfico.
Recursos adecuados si se monitorizan enlaces con alto volumen.
Configuración utilizada
Los archivos completos del despliegue se encuentran versionados en Gitea:
Proyecto en Gitea
Desarrollo
Qué se hizo y por qué
Se utiliza la imagen oficial 
ntop/ntopng en edición community.
El despliegue permite monitorizar múltiples interfaces de red utilizando varios parámetros 
-i.
Parámetros relevantes de nTopNG:
--community
Fuerza el uso de la edición comunitaria.
--dont-change-user
Evita que el contenedor cambie el usuario interno de ejecución. Puede ser necesario cuando aparecen errores de permisos al escribir en el volumen persistente.
-d /var/lib/ntopng
Directorio interno de almacenamiento.
-i InterfazMonitorizada
Permite especificar una o varias interfaces a monitorizar.
Ejemplo:
-i enp4s0
-i enp5s0
Esto permite observar tráfico de varias redes o enlaces simultáneamente.
-r 127.0.0.1:6379@0
Conexión directa al backend Redis por loopback.
-w 0.0.0.0:3000
Expone la interfaz web desde el host.
Redis como backend
Redis se ejecuta con:
redis-server --save 900 1 --bind 127.0.0.1
Esto garantiza que:
Redis no escuche en interfaces externas.
No exista exposición en la LAN.
Solo sea accesible desde el propio host.
Redis actúa como almacenamiento rápido para:
métricas de tráfico
estadísticas de flujos
datos temporales utilizados por nTopNG
La persistencia se gestiona mediante volúmenes dedicados:
/var/lib/ntopng para datos internos.
/data en Redis para snapshots periódicos.
Justificación de la arquitectura
El objetivo principal es coherencia y mínima superficie expuesta.
Ejecutar ambos servicios en modo host permite:
Captura real y directa de interfaces físicas.
Comunicación interna sin NAT.
Eliminación de puertos publicados innecesarios.
Aislamiento efectivo de Redis mediante bind a loopback.
Redis no requiere acceso desde la LAN ni desde otros contenedores, por lo que exponerlo mediante 
ports: o mantenerlo en bridge no aporta valor en este contexto.
En un entorno de producción segmentado o multi‑tenant podría optarse por otro modelo. En un homelab monitorizando la propia red, esta arquitectura es consistente y razonable.
Validación
Comprobaciones básicas tras el despliegue:
Acceso correcto a 
http://<IP_DEL_SERVIDOR>:3000.
Detección de hosts y flujos en tiempo real.
Redis accesible únicamente por 
127.0.0.1.
Ausencia de errores críticos en logs de ambos contenedores.
Escritura correcta en volúmenes persistentes.
Si no aparecen flujos, el problema suele estar en:
interfaz incorrecta
permisos de captura
tráfico inexistente en esa interfaz
Decisiones importantes
Modo host obligatorio para nTopNG: necesario para inspección real de interfaces físicas.
Redis en host con bind a loopback: backend aislado y no expuesto.
Monitorización de múltiples interfaces: permite observar simultáneamente diferentes segmentos de red.
Eliminación de redes bridge y puertos publicados: arquitectura más simple y coherente.
No exposición directa a internet: el panel debe mantenerse en red interna o protegerse mediante proxy inverso y autenticación adicional.
Resumen breve
nTopNG se despliega en modo host para capturar tráfico real de varias interfaces físicas del servidor. Redis también se ejecuta en modo host y enlazado exclusivamente a loopback como backend local.
La arquitectura elimina NAT, redes bridge y exposición innecesaria de puertos, reduciendo complejidad y superficie de ataque dentro del homelab.
Referencias
Repositorio oficial en GitHub
Documentación oficial
Proyecto en Gitea