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