Nodo de monitorización DNS doméstico con Raspberry

Contexto y motivación

En entornos domésticos y de laboratorio es habitual que exista una gran cantidad de dispositivos heterogéneos conectados a la red local:

estaciones Windows y Linux

móviles

Smart TVs

consolas

dispositivos IoT

navegadores y aplicaciones con telemetría constante

Aunque estos entornos no suelen disponer de herramientas SOC tradicionales, sí presentan superficie de ataque real:

uso de DNS externo no controlado

exposición a dominios sospechosos o de baja reputación

malware o PUPs generando tráfico anómalo

dispositivos desconocidos uniéndose a la red

configuraciones inseguras difíciles de ver sin telemetría

El objetivo de este proyecto es crear una capacidad de visibilidad y detección temprana en una red doméstica usando hardware de bajo coste, concretamente una Raspberry Pi Zero 2 W, actuando como:

resolutor DNS local

sensor de comportamiento DNS

punto de inventariado básico de clientes

base experimental de laboratorio Blue Team

2. Justificación técnica

Este enfoque se basa en una premisa clave:

El tráfico DNS es una de las fuentes de telemetría más útiles, ligeras y accesibles para detección temprana en entornos pequeños.

Razones para instrumentar DNS

permite observar qué dominios solicitan los dispositivos

permite detectar dominios inusuales o nuevos

ayuda a identificar beaconing, DGA, staging y abuso de resoluciones

permite construir una baseline de comportamiento

consume menos recursos que inspección profunda de paquetes

es más viable en hardware limitado

Razones para usar una Raspberry Pi Zero 2 W

bajo coste

consumo energético reducido

tamaño compacto

suficiente para tareas de DNS y logging ligero

útil como laboratorio reproducible

Razones para descartar una solución pesada

Se evaluó una aproximación basada en Maltrail, pero en este hardware aparecieron limitaciones:

consumo elevado de memoria

inestabilidad operacional

necesidad de feeds y procesamiento más intensivo

peor encaje para servicio 24/7 estable

Por ello se adoptó una arquitectura simplificada y robusta.

3. Objetivo general

Diseñar e implantar un sistema de monitorización ligera centrado en DNS para una red doméstica, que permita:

observar qué clientes usan el DNS local

registrar eventos y anomalías DNS

detectar nuevos dispositivos

construir una baseline de comportamiento

facilitar troubleshooting y ampliaciones posteriores

servir como proyecto documentable y presentable en portfolio Blue Team

4. Objetivos específicos

desplegar unbound como servidor DNS local

redirigir clientes de la red al DNS de la Raspberry Pi

registrar actividad DNS observada

detectar clientes nuevos y dominios nuevos

generar alertas básicas persistentes

mantener el sistema ligero y estable

dejar preparada una senda de integración con dashboards y herramientas SOC

5. 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

documentación técnica y troubleshooting

No incluido

inspección completa del tráfico cifrado

visibilidad total de dispositivos que usen DoH/DoT o DNS manual

IDS/IPS de red completo

correlación avanzada multi-fuente

EDR en endpoints

captura 24/7 de todo el tráfico

6. Arquitectura propuesta

Componentes principales

Router doméstico

entrega por DHCP la IP de la Pi como DNS primario

Raspberry Pi Zero 2 W

unbound: resolución DNS local

dns-spy: detección de anomalías y persistencia

arpwatch: detección de cambios ARP y nuevos dispositivos

journald y logs locales persistentes

Clientes de red

PCs, móviles, IoT y otros equipos que usen la Pi como DNS

PC principal / estación de análisis

revisión de logs

posible dashboard futuro

documentación y portfolio

Flujo lógico

El cliente de red solicita resolución DNS.

El router le ha entregado la Pi como servidor DNS.

unbound recibe y resuelve la petición.

dns-spy analiza patrones observados.

Las alertas se almacenan localmente.

arpwatch detecta dispositivos nuevos o cambios de MAC/IP.

La información puede revisarse por CLI o exportarse a un dashboard futuro.

7. Componentes desplegados

7.1 Unbound

Funciona como resolutor DNS local y punto de observación principal.

Función operativa

recibir consultas DNS de clientes de la LAN

resolverlas localmente o hacia upstreams configurados

dejar rastro suficiente para observación

7.2 dns-spy

Script ligero orientado a detección básica.

Casos de uso

detectar dominios nuevos

registrar clientes nuevos

detectar TLDs raros

detectar dominios largos o sospechosos

detectar ráfagas de NXDOMAIN

persistir baseline

7.3 arpwatch

Complementa la visibilidad DNS con observación de presencia de dispositivos.

Casos de uso

detectar nuevos hosts

detectar cambios de IP/MAC

ayudar al inventario de red

8. Detalle de artefactos del sistema

Ficheros relevantes

/home/sammi/dns_spy.py

/etc/systemd/system/dns-spy.service

/etc/dns-spy/whitelist.txt

/var/log/soc_alerts.log

/var/lib/dns-spy/seen_domains.txt

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

/var/log/dns-spy/

9. Pasos de implementación

9.1 Despliegue de Unbound

instalación del servicio

ajuste de escucha en red local

control de acceso para subred LAN

verificación de funcionamiento con consultas reales

9.2 Configuración de router

DHCP activo

DNS principal asignado a 192.168.1.150

recomendación de usar también 192.168.1.150 como secundario para evitar bypass por 8.8.8.8

renovación de leases en clientes

9.3 Verificación de uso real del DNS

Se comprobó qué clientes estaban utilizando efectivamente la Pi mediante:

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

9.4 Despliegue de arpwatch

instalación del servicio

asociación a la interfaz local

validación de eventos

9.5 Sustitución de Maltrail

Se intentó inicialmente una aproximación con Maltrail, pero fue descartada por:

OOM

inestabilidad

sobrecarga para la Pi Zero 2 W

Se sustituyó por una arquitectura ligera basada en eventos DNS.

10. Validaciones realizadas

Validación de resolución DNS

Se comprobó que unbound recibía y resolvía peticiones

Validación de clientes observados

Se comprobó qué IPs estaban usando la Pi:

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

Validación de logs y alertas

Se consultaron:

sudo journalctl -u unbound -f -o cat

tail -f /var/log/soc_alerts.log

Validación de salud del sistema

Se verificaron:

temperatura

RAM

swap

throttling

logs de kernel

estado Wi‑Fi

eventos de reboot

11. Incidencias encontradas

11.1 Hardware limitado para sensor pesado

El uso de Maltrail resultó excesivo para la memoria disponible de la Pi Zero 2 W.

11.2 Inestabilidad y reinicios

Se observaron reinicios reales del sistema, no simples cortes de red.

11.3 Cobertura parcial de monitorización

Solo se monitorizan de forma fiable los clientes que usan la Pi como DNS.

11.4 Bypass por configuración cliente

Algunos dispositivos pueden eludir la monitorización mediante:

DNS manual

DNS secundario externo

DoH

DoT

IPv6 DNS del router/ISP

11.5 Limitaciones del medio Wi‑Fi

Para servicio 24/7, la conectividad Wi‑Fi puede introducir:

mayor latencia

microcortes

pérdida de estabilidad frente a Ethernet

12. Troubleshooting documentado

Diagnóstico básico del sistema

date

uptime

free -m

vcgencmd measure_temp

vcgencmd get_throttled

Estado de servicios

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

Estado Wi‑Fi

iw dev wlan0 link

iw dev wlan0 get power_save

cat /proc/net/wireless

sudo journalctl -u wpa_supplicant -n 100 —no-pager

Errores de kernel/sistema

sudo dmesg | grep -iE ‘error|fail|mmc|ext4|reset|watchdog|voltage|under|panic|oom’

sudo journalctl -b -p warning —no-pager

Historial de arranque

uptime -s

who -b

journalctl —list-boots

Revisión de actividad DNS

sudo journalctl -u unbound -f -o cat

tail -n 50 /var/log/soc_alerts.log

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

13. Limitaciones del proyecto

no es un IDS/IPS completo

no ve todo el tráfico cifrado

no detecta todo comportamiento malicioso

depende del uso real de la Pi como DNS

la Pi Zero 2 W impone límites claros de CPU/RAM/I/O

la conectividad Wi‑Fi no es la mejor opción para uso crítico continuado

14. Recomendaciones operativas

A corto plazo

mantener solo servicios ligeros

evitar sensores pesados

minimizar periféricos USB

revisar estabilidad del medio de red

considerar Ethernet USB para 24/7

A medio plazo

separar resolución DNS y análisis

exportar logs a una estación más potente

mejorar baseline y clasificación de eventos

introducir enriquecimiento externo

15. Futuras actualizaciones recomendadas

15.1 Integración con dashboard tipo SOC

Evolución natural:

exportar logs de alertas a un stack visual

crear paneles de:

dominios nuevos por día

top clientes

top NXDOMAIN

TLDs raros

dispositivos nuevos

tendencias temporales

15.2 Integración con SIEM ligero o conocido

Opciones razonables para documentar y portfolio:

Opción A: ELK / Elastic Stack

Filebeat o rsyslog enviando logs a Elasticsearch

Kibana para dashboards

buena visibilidad visual

muy potente para portfolio

Opción B: Graylog

ingestión sencilla

streams y alertas

fácil de presentar como mini-SOC

Opción C: Wazuh

ampliamente conocido en Blue Team

útil si luego añades agentes en endpoints

muy potente para portfolio defensivo

Opción D: Splunk Free / trial en lab

muy reconocible en mercado laboral

útil para demostrar parsing, dashboards y alertas

15.3 Integración con MISP / Threat Intel

A futuro, dns-spy podría enriquecer dominios observados contra:

MISP

AlienVault OTX

Abuse.ch

URLhaus

OpenPhish

Esto permitiría:

clasificar dominios por reputación

hacer hunting sobre observables

justificar detecciones

15.4 Integración con Zeek en hardware más potente

Si migras a una máquina superior:

usar Zeek para análisis de red avanzado

correlacionar dns.log, conn.log, ssl.log

elevar el laboratorio a nivel Blue Team serio

15.5 Integración con Suricata

Con hardware superior o estación dedicada:

IDS basado en firmas

EVE JSON

paneles en Kibana o Wazuh

16. Propuesta de investigación Blue Team

Este proyecto se puede convertir en una línea de investigación práctica muy válida.

Líneas de investigación sugeridas

16.1 Baseline DNS doméstico

qué dominios aparecen de forma habitual

qué servicios generan más ruido

cómo distinguir normalidad de anomalía

16.2 Estudio de telemetría de aplicaciones

Microsoft

Google

Spotify

navegadores

updates

servicios cloud

16.3 Detección de rarezas DNS

dominios largos

TLD inusuales

NXDOMAIN bursts

dominios recién vistos

cambios bruscos por cliente

16.4 Evasión de visibilidad

impacto de DoH/DoT

bypass por IPv6

DNS manual

hardcoded resolvers

16.5 Threat hunting en red doméstica

Preguntas de hunting:

¿qué clientes consultan dominios nuevos con más frecuencia?

¿qué dominios son exclusivos de un solo host?

¿qué patrones parecen automáticos o periódicos?

¿qué resoluciones coinciden con software potencialmente no deseado?

16.6 Comparativa de sensores ligeros

Unbound + parser

Pi-hole + logs

Dnsmasq + parser

Zeek DNS logs en hardware mayor

17. Posibilidades de análisis para portfolio

Este proyecto tiene mucho valor si lo presentas bien.

Qué puedes mostrar

diagrama de arquitectura

decisiones técnicas y trade-offs

baseline de DNS real

ejemplos de alertas

análisis de clientes

troubleshooting real

evolución desde intento fallido con Maltrail hacia solución estable

plan de madurez del laboratorio

Qué da valor profesional

enfoque defensivo práctico

capacidad de depuración real

ajuste de arquitectura al hardware disponible

criterio para descartar herramientas no adecuadas

pensamiento SOC / detección / observabilidad

18. Cómo llevar los logs a un dashboard conocido de SOC

Aquí te dejo una sección documentable para el informe.

Opción recomendada para portfolio: Wazuh o Elastic

Variante 1: Raspberry Pi → syslog/rsyslog → servidor Elastic/Graylog

La Pi genera logs en:

journald

/var/log/soc_alerts.log

Flujo

dns-spy escribe alertas en /var/log/soc_alerts.log

rsyslog o filebeat las envía al servidor central

el servidor indexa y visualiza

Kibana / Graylog muestra paneles

Ejemplo conceptual de eventos a enviar

cliente nuevo detectado

dominio nuevo detectado

TLD raro

burst de NXDOMAIN

dominio longitud anómala

Ventajas

arquitectura clásica SOC

desacopla sensor y análisis

muy buena para portfolio

Variante 2: Raspberry Pi → Wazuh manager

Se puede configurar el fichero de alertas local como fuente de logs.

Beneficios

reglas

dashboards

correlación

marca reconocida en Blue Team

Variante 3: Raspberry Pi → Splunk lab

Enviar soc_alerts.log a Splunk para:

indexación

búsquedas SPL

dashboards

saved searches

Muy útil para enseñar:

parsing

normalización

KPI defensivos

19. KPIs y visualizaciones recomendadas para dashboard

Paneles útiles

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

dominios únicos por host

actividad DNS por hora

dominios sospechosos enriquecidos con threat intel

Casos de uso de dashboard

triage rápido

hunting

inventario dinámico

demostración visual para portfolio

informes mensuales

20. Propuesta de madurez por fases

Fase 1 --- Sensor básico

Unbound

dns-spy

arpwatch

alertas locales

Fase 2 --- Centralización

rsyslog/filebeat

dashboard en Elastic/Graylog/Wazuh

Fase 3 --- Enriquecimiento

threat intel feeds

clasificación por reputación

tagging de observables

Fase 4 --- Correlación

añadir Zeek/Suricata en hardware superior

correlacionar DNS con conexiones y TLS

Fase 5 --- Portfolio profesional

write-up técnico

diagramas

dashboards

hipótesis de hunting

conclusiones

roadmap

21. Conclusiones

El proyecto demuestra que es posible construir una capacidad inicial de monitorización defensiva en una red doméstica con hardware muy limitado, siempre que se adapten correctamente las expectativas y la arquitectura.

La Raspberry Pi Zero 2 W no es adecuada para sensores pesados o pipelines complejos, pero sí puede servir como:

resolutor DNS instrumentado

sensor básico de anomalías

punto de inventario ligero

laboratorio formativo de prácticas Blue Team

El valor técnico del proyecto no reside solo en la herramienta desplegada, sino en las decisiones de ingeniería tomadas:

priorizar estabilidad sobre complejidad

sustituir componentes demasiado pesados

identificar limitaciones de visibilidad

estructurar un roadmap de madurez

preparar integración futura con dashboards y tooling SOC real

22. Cierre orientado a portfolio

Este proyecto es especialmente útil como portfolio porque muestra:

diseño de arquitectura

visibilidad de red

análisis de logs

detección de anomalías

troubleshooting real

criterio técnico bajo restricciones

evolución hacia un mini-SOC doméstico

Si quieres, el siguiente paso útil es uno de estos dos:

te lo convierto en documento formal tipo memoria técnica/proyecto

te lo convierto en versión portfolio/currículum/LinkedIn/GitHub, mucho más orientada a venderlo profesionalmente

Si quieres, también te puedo preparar después una sección adicional con:

diagrama ASCII/mermaid de arquitectura

roadmap de mejoras

KPIs SOC

casos de uso de detección

hipótesis de threat hunting.

1) Objetivo de la arquitectura limpia

La propuesta limpia sustituye el intento con Maltrail por una solución ligera y estable para una Raspberry Pi Zero 2 W:

• Unbound como DNS local y punto de observación.

• dns-spy como detector de eventos DNS y generador de alertas.

• arpwatch como detector de nuevos dispositivos en red.

• logs persistentes para auditoría.

• servicio systemd para operación 24/7.

Motivo del cambio

Maltrail resultó demasiado pesado/inestable para este hardware y además complicó la arquitectura al depender de componentes adicionales. La solución basada en DNS ofrece:

• menor consumo

• mayor estabilidad

• mejor mantenibilidad

• visibilidad útil para una red doméstica

2) Qué se limpia / se deja fuera

Se eliminó o dejó fuera de la arquitectura estable:

• maltrail

• captura continua pesada

• modo monitor como función permanente

• dependencias de server en Windows

• feeds pesados de reputación

Se conserva:

• unbound

• arpwatch

• script dns_spy.py

• archivo de alertas /var/log/soc_alerts.log

3) Comandos de logs que te fui dando

Aquí van todos los comandos relevantes, clasificados por finalidad.

3.1 Logs del servicio DNS Spy

Ver el servicio en tiempo real

comando:: sudo journalctl -u dns-spy -f

Ver el estado resumido del servicio

comando:: sudo systemctl status dns-spy.service —no-pager

Ver logs del servicio en el boot actual

comando:: sudo journalctl -u dns-spy -b —no-pager

Ver últimas líneas del log de alertas persistente

tail -n 50 /var/log/soc_alerts.log

Seguir el log persistente en tiempo real

tail -f /var/log/soc_alerts.log

Ver solo alertas de nivel alto o advertencia

grep -E ‘ALERT|HIGH|WARN’ /var/log/soc_alerts.log

3.2 Logs de Unbound

Ver estado del servicio

comando:: sudo systemctl status unbound —no-pager

Seguir en tiempo real los logs de Unbound

comando:: sudo journalctl -u unbound -f -o cat

Ver logs del boot actual de Unbound

comando:: sudo journalctl -u unbound -b —no-pager

Ver las consultas DNS observadas

comando:: sudo journalctl -u unbound -o cat | grep ‘info:‘

Resumen de consultas por “campo 4” del log

comando:: sudo journalctl -u unbound -o cat | grep ‘info:’ | awk ‘{print $4}’ | sort | uniq -c

Nota: ese comando no agrupa por IP cliente de forma fiable en todos los formatos de log; agrupa el campo 4, que en tu caso terminó mostrando dominios. Es útil como resumen bruto, pero no como parser robusto de clientes.

3.3 Ver qué clientes ha aprendido dns-spy

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

Ver cuántos dominios ha aprendido

wc -l /var/lib/dns-spy/seen_domains.txt

Ver primeros dominios almacenados

head -n 50 /var/lib/dns-spy/seen_domains.txt

3.4 Logs de Arpwatch

Estado del servicio

comando:: sudo systemctl status arpwatch —no-pager

Ver eventos en tiempo real

comando:: sudo journalctl -u arpwatch -f

Ver logs del boot actual

comando:: sudo journalctl -u arpwatch -b —no-pager

3.5 Logs Wi‑Fi / conectividad

Logs recientes de wpa_supplicant

comando:: sudo journalctl -u wpa_supplicant -n 100 —no-pager

Logs del boot actual relacionados con Wi‑Fi/red

comando:: sudo journalctl -b | grep -iE ‘wlan0|deauth|disconnect|disassoc|carrier|dhcpcd|wpa’

Estado del enlace Wi‑Fi actual

comando:: iw dev wlan0 link

Estado del ahorro de energía

comando:: iw dev wlan0 get power_save

Calidad general inalámbrica

comando:: cat /proc/net/wireless

3.6 Logs de kernel / hardware

Buscar eventos críticos

comando:: sudo dmesg | grep -iE ‘error|fail|mmc|ext4|reset|watchdog|voltage|under|panic|oom’

Ver advertencias del boot actual

comando:: sudo journalctl -b -p warning —no-pager

Buscar problemas de Wi‑Fi/firmware/kernel

comando:: sudo dmesg | grep -iE ‘wlan0|brcm|firmware|disconnect|deauth|timeout’

Buscar eventos de SD/MMC

dmesg | grep -i mmc

3.7 Estado de reinicios / boots

Hora de arranque del sistema

uptime -s

Último boot

who -b

Lista de boots guardados en journal

journalctl —list-boots

3.8 Salud general del sistema

Temperatura

vcgencmd measure_temp

Estado de throttling / undervoltage

vcgencmd get_throttled

Memoria

free -m

Carga y uptime

uptime

3.9 Estado de servicios principales

comando:: sudo systemctl status unbound dns-spy arpwatch —no-pager

3.10 Ficheros de configuración y artefactos importantes

Script principal

/home/sammi/dns_spy.py

Servicio systemd

/etc/systemd/system/dns-spy.service

Whitelist

/etc/dns-spy/whitelist.txt

Log de alertas

/var/log/soc_alerts.log

CSVs diarios

/var/log/dns-spy/

Estado persistente

/var/lib/dns-spy/seen_domains.txt

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

4) Flujo recomendado para documentar una incidencia

Cuando notes que “la Pi se desconecta” o “parece caída”, documenta siempre así:

4.1 Registrar estado básico

date

uptime

free -m

vcgencmd measure_temp

vcgencmd get_throttled

4.2 Revisar servicios principales

comando:: sudo systemctl status unbound dns-spy arpwatch —no-pager

4.3 Revisar conectividad Wi‑Fi

comando:: iw dev wlan0 link

comando:: iw dev wlan0 get power_save

comando:: cat /proc/net/wireless

comando:: sudo journalctl -u wpa_supplicant -n 100 —no-pager

4.4 Revisar errores de sistema

comando:: sudo journalctl -b -p warning —no-pager

comando:: sudo dmesg | grep -iE ‘error|fail|mmc|ext4|reset|watchdog|voltage|under|panic|oom’

4.5 Revisar si hubo reboot real

uptime -s

who -b

journalctl —list-boots

4.6 Revisar actividad DNS

comando:: sudo journalctl -u unbound -f -o cat

tail -n 50 /var/log/soc_alerts.log

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

5) Resumen narrativo para tu documentación

Te dejo un texto base que puedes reutilizar.

Descripción del cambio de arquitectura

Se descartó el uso de Maltrail por inestabilidad y consumo excesivo en Raspberry Pi Zero 2 W. Se optó por una arquitectura ligera basada en Unbound y un detector propio (dns-spy) para monitorización DNS doméstica 24/7.

Componentes desplegados

• Unbound como resolutor DNS local.

• dns-spy como monitor de consultas DNS y generador de alertas.

• arpwatch como detector de nuevos dispositivos en red.

• journald + log persistente /var/log/soc_alerts.log.

• servicio dns-spy.service gestionado por systemd.

Funcionalidades obtenidas

• detección de nuevos clientes

• detección de dominios nuevos

• detección de dominios largos

• detección de TLDs raros

• detección de ráfagas NXDOMAIN

• persistencia de baseline y export CSV

Limitación importante

Solo se monitorizan de forma fiable los dispositivos que usan la Raspberry Pi como servidor DNS. Para ampliar cobertura es necesario:

• configurar DHCP del router para usar la Pi como DNS primario y secundario

• renovar leases en clientes

• tener en cuenta bypass por DoH/DoT/IPv6/DNS manual

6) Comando corto “pack de diagnóstico”

Si quieres un bloque único para copiar en incidencias:

date

echo ”### BASIC”

uptime

free -m

vcgencmd measure_temp

vcgencmd get_throttled

echo ”### SERVICES”

comando:: sudo systemctl status unbound dns-spy arpwatch —no-pager

echo ”### WIFI”

comando:: iw dev wlan0 link

comando:: iw dev wlan0 get power_save

comando:: cat /proc/net/wireless

comando:: sudo journalctl -u wpa_supplicant -n 50 —no-pager

echo ”### WARNINGS”

comando:: sudo journalctl -b -p warning —no-pager

echo ”### KERNEL”

comando:: 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

Si quieres, en el siguiente mensaje te lo convierto en una plantilla de informe técnico completa, en formato:

• objetivo

• arquitectura

• pasos

• validaciones

• incidencias

• troubleshooting

• conclusiones.