LAN Sheriff (291 Group, AGPL-3.0) observa las conexiones salientes de una máquina leyendo sus propias tablas de sockets, sin privilegios elevados ni captura de paquetes: es el modo Deputy, el que usa este stack. El propio proyecto ofrece también un modo Patrol, con captura pasiva de paquetes, para ver el tráfico de otros dispositivos de la red — pero eso exige colocarse en el router o en un puerto espejo/SPAN, con mucha más preparación de red detrás. Este stack se queda deliberadamente en modo Deputy sobre el propio hipervisor o NAS: es la forma más simple de detectar un contenedor o un servicio comprometido que de repente empieza a hablar con un destino que no toca, sin montar nada más complejo.
Vigila qué habla tu servidor hacia fuera: LAN Sheriff + ntfy
Objetivo
Saber con qué conecta tu servidor homelab hacia Internet, y recibir un aviso en el móvil si contacta con algo que no debería.
13 de octubre de 2026por José Luis Mas y Rubi Rubio
Componentes
Base · Hipervisor
ya deberías tenerlo
Servicio principal · Observador de conexiones salientes
128 MB1 vCPU1 GB
Avisos al móvil
ya deberías tenerlo
Total a reservar (suma de los componentes con recursos propios)
128MB RAM1vCPU1GB disco
Cómo se conecta
Haz clic para ampliar
Ensamblaje
Preparar un LXC o VM con Docker en Proxmox
Puede ser un LXC privilegiado o una VM ligera con Docker instalado; también vale desplegarlo directamente en tu NAS o servidor existente si ya corre contenedores.
Desplegar LAN Sheriff en modo Deputy
El modo Deputy no necesita privilegios elevados ni acceso a la interfaz de red en modo promiscuo, pero sí
network_mode: hostpara leer las tablas de sockets reales de la máquina en vez de las de la red virtual del contenedor. El dashboard escucha en el puerto 2911; déjalo solo en localhost o detrás de un proxy con autenticación.services: lan-sheriff: image: ghcr.io/291-group/lan-sheriff:latest container_name: lan-sheriff network_mode: host restart: unless-stopped volumes: - ./datos:/var/lib/lan-sheriff command: ["serve"]Configurar los avisos hacia ntfy
Las alertas se configuran por línea de comandos, no desde el dashboard. Usa tu propio servidor ntfy self-hosted o el público ntfy.sh con un topic privado. El límite de tasa es de 12 avisos por hora como máximo, y nunca dos en menos de 20 segundos;
--notify-min-score(0-1, por defecto 0,6) controla a partir de qué puntuación de riesgo avisa.docker exec lan-sheriff lan-sheriff serve \ --notify-ntfy https://ntfy.sh/tu-topico-privado \ --notify-min-score 0.6
Entender qué cubre y qué no cubre este stack
En modo Deputy, LAN Sheriff ve las conexiones de la propia máquina identificando la aplicación responsable, pero no el tráfico del resto de dispositivos de tu red — eso exige modo Patrol y un punto de observación real (router o puerto espejo). Tampoco descifra DNS-over-HTTPS ni TLS: lo que viaja cifrado por ahí queda fuera de su visibilidad. Y por diseño no bloquea nada: solo observa y avisa.
Comprobar que las alertas llegan
Genera una conexión de control hacia un destino poco habitual desde la propia máquina y confirma que el aviso llega a tu topic de ntfy antes de dar el stack por terminado.
curl -s https://example.com > /dev/null # comprobar en la app o el topic de ntfy que llegó el aviso
Conclusión
Si llega una alerta real, el primer paso es aislar el contenedor o servicio señalado (pararlo o cortarle la red) y revisar sus logs antes de nada más — LAN Sheriff solo observa, nunca bloquea ni modifica tráfico, así que la reacción depende de ti. Tampoco es una red de seguridad completa: no ve nada de lo que viaja cifrado por DNS-over-HTTPS o TLS, y en modo Deputy solo cubre la máquina donde corre, no el resto de tu red. Si más adelante quieres visibilidad de toda la red (qué habla cada dispositivo, no solo el servidor), el salto natural es montar el modo Patrol con un puerto espejo en tu switch o en tu router — pero eso ya es una ampliación de este mismo stack, no un requisito de partida.
