Nodo de Monitorización DNS Doméstico con Raspberry Pi

Contexto y motivación

En entornos domésticos y de laboratorio conviven dispositivos heterogéneos (Windows, Linux, móviles, Smart TVs, IoT) con superficie de ataque real: DNS externo no controlado, exposición a dominios sospechosos, malware generando tráfico anómalo y dispositivos desconocidos uniéndose a la red.

El objetivo es crear visibilidad y detección temprana con una Raspberry Pi Zero 2 W actuando como:

Resolutor DNS local
Sensor de comportamiento DNS
Punto de inventariado básico de clientes
Laboratorio Blue Team reproducible

Justificación técnica

El tráfico DNS es una de las fuentes de telemetría más útiles, ligeras y accesibles para detección temprana:

Permite observar qué dominios solicitan los dispositivos
Detecta dominios inusuales, beaconing, DGA y staging
Ayuda a construir una baseline de comportamiento
Consume menos recursos que la inspección profunda de paquetes

Se descartó Maltrail por exceder los recursos de la Pi Zero 2 W (OOM, inestabilidad). La arquitectura final es ligera y robusta.

Arquitectura

Componentes

Componente	Rol
Router doméstico	Entrega por DHCP la IP de la Pi como DNS primario
Unbound	Resolución DNS local y punto de observación
dns-spy	Detección de anomalías DNS y persistencia de baseline
arpwatch	Detección de cambios ARP y nuevos dispositivos
journald + logs	Persistencia local de eventos

Flujo lógico

Cliente de red solicita resolución DNS → el router entrega la Pi como servidor DNS
Unbound recibe y resuelve la petición
dns-spy analiza patrones observados (nuevos dominios, TLDs raros, bursts NXDOMAIN)
Alertas se almacenan en /var/log/soc_alerts.log
arpwatch detecta dispositivos nuevos o cambios MAC/IP

Alcance

Incluido

Monitorización DNS de dispositivos que usen la Pi como resolver
Baseline simple de dominios y clientes
Alertado local por eventos relevantes
Inventario básico mediante arpwatch

No incluido

Inspección de tráfico cifrado (DoH/DoT)
IDS/IPS completo
Correlación avanzada multi-fuente
EDR en endpoints

Artefactos del sistema

Ruta	Descripción
`/home/analyst/dns_spy.py`	Script principal de detección
`/etc/systemd/system/dns-spy.service`	Servicio systemd 24/7
`/etc/dns-spy/whitelist.txt`	Lista blanca de dominios
`/var/log/soc_alerts.log`	Log persistente de alertas
`/var/lib/dns-spy/seen_domains.txt`	Baseline de dominios observados
`/var/lib/dns-spy/seen_clients.txt`	Baseline de clientes
`/var/log/dns-spy/`	CSVs diarios

Implementación

1. Despliegue de Unbound

Instalación del servicio y ajuste de escucha en red local
Control de acceso para subred LAN
Verificación con consultas reales

2. Configuración del router

DHCP activo con DNS primario apuntando a la IP de la Pi
Recomendación: usar también la Pi como DNS secundario para evitar bypass por 8.8.8.8
Renovación de leases en clientes

3. Verificación de clientes

sort /var/lib/dns-spy/seen_clients.txt

4. Despliegue de arpwatch

Instalación y asociación a la interfaz local
Validación de eventos

Comandos de operación y diagnóstico

Servicio dns-spy

# Ver en tiempo real
sudo journalctl -u dns-spy -f
 
# Estado resumido
sudo systemctl status dns-spy.service --no-pager
 
# Logs del boot actual
sudo journalctl -u dns-spy -b --no-pager

Logs de alertas

# Últimas 50 líneas
tail -n 50 /var/log/soc_alerts.log
 
# Seguimiento en tiempo real
tail -f /var/log/soc_alerts.log
 
# Solo alertas de nivel alto
grep -E 'ALERT|HIGH|WARN' /var/log/soc_alerts.log

Unbound

# Estado del servicio
sudo systemctl status unbound --no-pager
 
# Logs en tiempo real
sudo journalctl -u unbound -f -o cat
 
# Logs del boot actual
sudo journalctl -u unbound -b --no-pager
 
# Solo consultas DNS
sudo journalctl -u unbound -o cat | grep 'info:'
 
# Resumen por campo 4 (dominios)
sudo journalctl -u unbound -o cat | grep 'info:' | awk '{print $4}' | sort | uniq -c

Baseline de dns-spy

# Clientes detectados
sort /var/lib/dns-spy/seen_clients.txt
 
# Total de dominios aprendidos
wc -l /var/lib/dns-spy/seen_domains.txt
 
# Primeros 50 dominios
head -n 50 /var/lib/dns-spy/seen_domains.txt

Arpwatch

# Estado
sudo systemctl status arpwatch --no-pager
 
# Eventos en tiempo real
sudo journalctl -u arpwatch -f
 
# Logs del boot actual
sudo journalctl -u arpwatch -b --no-pager

Wi-Fi y conectividad

# Estado del enlace
iw dev wlan0 link
 
# Power save
iw dev wlan0 get power_save
 
# Calidad inalámbrica
cat /proc/net/wireless
 
# Logs recientes de wpa_supplicant
sudo journalctl -u wpa_supplicant -n 100 --no-pager
 
# Eventos Wi-Fi/red del boot actual
sudo journalctl -b | grep -iE 'wlan0|deauth|disconnect|disassoc|carrier|dhcpcd|wpa'

Kernel y hardware

# Eventos críticos
sudo dmesg | grep -iE 'error|fail|mmc|ext4|reset|watchdog|voltage|under|panic|oom'
 
# Advertencias del boot actual
sudo journalctl -b -p warning --no-pager
 
# Problemas de Wi-Fi/firmware
sudo dmesg | grep -iE 'wlan0|brcm|firmware|disconnect|deauth|timeout'
 
# Eventos SD/MMC
dmesg | grep -i mmc

Historial de arranque

# Hora de arranque
uptime -s
 
# Último boot
who -b
 
# Lista de boots
journalctl --list-boots

Salud general

# Temperatura
vcgencmd measure_temp
 
# Throttling / undervoltage
vcgencmd get_throttled
 
# Memoria
free -m
 
# Carga y uptime
uptime

Estado de todos los servicios

sudo systemctl status unbound dns-spy arpwatch --no-pager

Pack de diagnóstico rápido

Para copiar en bloque durante incidencias:

date
echo "### BASIC"
uptime
free -m
vcgencmd measure_temp
vcgencmd get_throttled
 
echo "### SERVICES"
sudo systemctl status unbound dns-spy arpwatch --no-pager
 
echo "### WIFI"
iw dev wlan0 link
iw dev wlan0 get power_save
cat /proc/net/wireless
sudo journalctl -u wpa_supplicant -n 50 --no-pager
 
echo "### WARNINGS"
sudo journalctl -b -p warning --no-pager
 
echo "### KERNEL"
sudo dmesg | grep -iE 'error|fail|mmc|ext4|reset|watchdog|voltage|under|panic|oom'
 
echo "### BOOTS"
uptime -s
who -b
journalctl --list-boots
 
echo "### DNS"
tail -n 50 /var/log/soc_alerts.log
sort /var/lib/dns-spy/seen_clients.txt

Incidencias y limitaciones

Maltrail descartado: Consumo excesivo de memoria en Pi Zero 2 W (OOM, inestabilidad).
Reinicios del sistema: Se observaron reinicios reales, no simples cortes de red.
Cobertura parcial: Solo se monitorizan clientes que usan la Pi como DNS.
Bypass por configuración cliente: DoH, DoT, DNS manual, DNS secundario externo o IPv6 DNS del ISP eluden la monitorización.
Wi-Fi vs Ethernet: Para servicio 24/7, Ethernet USB es preferible frente a Wi-Fi por latencia y microcortes.

Roadmap de madurez

Fase	Descripción
Fase 1 — Sensor básico	Unbound + dns-spy + arpwatch + alertas locales
Fase 2 — Centralización	rsyslog/filebeat → Elastic/Graylog/Wazuh con dashboards
Fase 3 — Enriquecimiento	Threat intel feeds (MISP, AlienVault OTX, Abuse.ch, URLhaus)
Fase 4 — Correlación	Zeek/Suricata en hardware superior, cruzar DNS con conexiones y TLS
Fase 5 — Portfolio	Write-up técnico, diagramas, dashboards, hipótesis de hunting

KPIs y visualizaciones recomendadas

Top dominios por día
Top clientes por volumen DNS
Dominios nuevos por día / clientes nuevos por semana
TLDs raros detectados
Ratio NXDOMAIN por cliente
Actividad DNS por hora
Dominios sospechosos enriquecidos con threat intel

Líneas de investigación Blue Team

Baseline DNS doméstico: dominios habituales, servicios con más ruido, distinguir normalidad de anomalía
Telemetría de aplicaciones: Microsoft, Google, Spotify, navegadores, updates, servicios cloud
Detección de rarezas DNS: dominios largos, TLD inusuales, NXDOMAIN bursts, cambios bruscos por cliente
Evasión de visibilidad: impacto de DoH/DoT, bypass por IPv6, DNS manual, hardcoded resolvers
Threat hunting: ¿qué clientes consultan más dominios nuevos? ¿qué dominios son exclusivos de un solo host? ¿qué patrones parecen automáticos?
Comparativa de sensores: Unbound + parser vs Pi-hole + logs vs Dnsmasq + parser vs Zeek DNS logs

Conclusiones

El proyecto demuestra que es posible construir monitorización defensiva en una red doméstica con hardware limitado, adaptando expectativas y arquitectura. La Pi Zero 2 W no es adecuada para sensores pesados, pero sí como resolutor DNS instrumentado, sensor básico de anomalías y laboratorio formativo Blue Team.

El valor técnico reside en las decisiones de ingeniería: priorizar estabilidad sobre complejidad, sustituir componentes demasiado pesados, identificar limitaciones de visibilidad y estructurar un roadmap de madurez con integración futura a dashboards y tooling SOC real.

Sammi Notes

Explorador