Skip to main content

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:

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

Back to top