Problema

En entornos domésticos o de pequeñas oficinas, la visibilidad de tráfico y la identificación de dispositivos conectados suele ser mínima. Los routers de consumo no registran consultas DNS sospechosas, ni generan alertas cuando un dispositivo llega al final de su vida útil. Cuando se depende de soluciones SaaS, los logs salen de la red y se pierde el control sobre la privacidad. El patrón recurrente es la falta de un punto único que correlacione:

  • consultas DNS con indicadores de compromiso (IoC)
  • actividad de dispositivos desconocidos o recién conectados
  • detección de equipos con firmware vulnerable o fuera de soporte

Sin esa correlación, los administradores de homelab o pymes no pueden reaccionar a tiempo ante beaconing, tunneling o a la presencia de cámaras comprometidas.

Causa

  1. Router sin inspección profunda de DNS – la mayoría solo resuelve y delega, sin comparar contra listas de dominios maliciosos.
  2. Inventario estático – se confía en la tabla DHCP del router, que no captura dispositivos que usan direcciones estáticas o que aparecen solo en tráfico pasivo.
  3. Dependencia de servicios en la nube – herramientas que envían logs a servidores externos no ofrecen una opción “offline only”.
  4. Falta de integración entre componentes – Pi‑hole, AdGuard Home o sistemas de detección de intrusiones (IDS) funcionan aislados, lo que obliga a revisar varios dashboards.

Estos factores se combinan para crear “ciegos” en la red, donde un agente malicioso puede operar sin ser detectado.

Solución

Implementar una arquitectura modular que combine:

  1. Core Docker – orquesta los servicios de análisis y almacenamiento.
  2. Sensor nativo – binario pequeño (Go, Rust o Python) que captura paquetes en la interfaz de red y reenvía eventos al core. Disponible para Linux, macOS y Windows.
  3. Motor de detección DNS – compara cada consulta contra feeds públicos (abuse.ch, URLhaus, Feodo, SSLBL).
  4. Módulo de descubrimiento – combina escaneo activo (nmap ping sweep) con escucha pasiva de ARP, DHCP, mDNS y SSDP para generar un inventario actualizado.
  5. Enriquecimiento de EOL – cruza la lista de hardware conocida (FBI IC3 AVrecon, SocksEscort) con la tabla de inventario y eleva la puntuación de riesgo cuando el dispositivo muestra tráfico anómalo.
  6. Opcional: integración con Pi‑hole / AdGuard Home – mediante API REST para marcar dominios bloqueados como potenciales indicadores.

El flujo básico es:

Sensor → Core (Docker) → DB (SQLite / PostgreSQL) → UI (Web)  
               ↘︎
                → Alertas (Telegram, Discord, webhook)

Paso a paso

  1. Prepara el host – Docker Engine 24.x o superior, acceso a la interfaz de red en modo promiscuous (requiere --network host o cap_add: NET_ADMIN).
  2. Descarga el repositorio – clona el proyecto y revisa el docker-compose.yml.
  3. Configura los feeds DNS – agrega URLs de listas de abuso en config/dns_feeds.yaml.
  4. Despliega – docker compose up -d. El contenedor vedetta-core expondrá la API en 0.0.0.0:8080.
  5. Instala el sensor – en cada host objetivo ejecuta el binario con la bandera --target http://<core-ip>:8080/ingest.
  6. Opcional: conecta Pi‑hole – define PIHOLE_API_KEY y PIHOLE_URL en config/integrations.yaml.

Esta arquitectura permite escalar añadiendo sensores en subredes VLAN sin tocar el core.

Cuándo aplicar esta solución

Señales de que la arquitectura encaja

  • Necesitas visibilidad de DNS sin exponer datos a terceros.
  • Tu red incluye dispositivos heterogéneos (Linux, Windows, macOS, IoT).
  • Quieres correlacionar inventario con comportamiento sospechoso.
  • Ya usas Docker y puedes dedicar un nodo (Raspberry Pi 4, mini‑PC) para el core.

Escenarios donde no es apropiado

  • Redes con requisitos de alta disponibilidad donde un único nodo Docker sería un punto de falla.
  • Entornos que requieren inspección profunda de paquetes a nivel de capa 7 (por ejemplo, detección de exfiltración de datos en TLS). En ese caso, un IDS dedicado como Zeek o Suricata sería complementario.

Código

git clone https://github.com/MahdiHedhli/vedetta.git
cd vedetta
docker compose up -d

# Ejemplo de despliegue del sensor en Linux
curl -LO https://github.com/MahdiHedhli/vedetta/releases/download/v0.9.0/vedetta-sensor-linux-amd64
chmod +x vedetta-sensor-linux-amd64
./vedetta-sensor-linux-amd64 --target http://192.168.1.10:8080/ingest --interface eth0 &

# Configuración mínima de feeds DNS (config/dns_feeds.yaml)
feeds:
  - name: "URLhaus"
    url: "https://urlhaus.abuse.ch/downloads/urlhaus-filter-domains.txt"
  - name: "Feodo"
    url: "https://feodotracker.abuse.ch/downloads/ipblocklist.txt"

Verificación

  1. Accede a http://<core-ip>:8080 y verifica que la tabla de dispositivos muestra al menos un host distinto al router.
  2. Genera una consulta DNS a un dominio listado en los feeds (por ejemplo, example.malicious). Observa la alerta en la UI y en el canal de Telegram configurado.
  3. Desconecta temporalmente un dispositivo conocido y revisa que desaparezca del inventario después de 5 minutos (tiempo de expiración configurable).

Si los pasos anteriores muestran datos coherentes, la cadena de captura‑análisis‑alerta está operativa.

Notas adicionales

  • Persistencia de datos – monta un volumen en vedetta-db para evitar pérdida de historial al reiniciar el contenedor.
  • Rendimiento en Raspberry Pi 4 – limitar la captura a solo tráfico DNS (puerto 53) y ARP reduce la carga de CPU a < 10 %.
  • Privacidad – la opción “opt‑out community sharing” simplemente envía hashes de dominios y MAC; si la política lo requiere, desactívala por completo.
  • Actualizaciones de feeds – programa una tarea cron dentro del contenedor (0 * * * * /app/update_feeds.sh) para mantener las listas al día.
  • Extensibilidad – el API REST permite crear plugins que, por ejemplo, consulten Shodan o Censys para enriquecer la información de dispositivos IoT.