Nota, no recomiendo usar este hat si estás usando un disco SSD conectado a los puertos usb, si no es a través de un hub, debido a los picos de corriente que genera provocando desconexiones y problemas en los mismos.

En este tutorial, aprenderemos a configurar un sistema de alerta crítica. Si tu conexión a internet falla —ya sea por una avería de tu proveedor (ISP) o un fallo en tu propio router—, la Raspberry Pi detectará la caída de inmediato, te avisará mediante una llamada telefónica y te reportará via Telegram cuando la red sea restablecida.

Para que este sistema sea infalible, no podemos depender de la propia conexión de fibra que estamos monitorizando. Necesitamos una vía de comunicación externa. En este caso práctico, utilizaremos un módulo HAT 4G LTE CAT-1 (A7670E), junta a una tarjeta SIM M2M (machine to machine) como las que emplean Vodafone u Orange para alarmas profesionales, ascensores , etc. Estas tarjetas suelen estar limitadas a voz o SMS y no disponen de datos móviles. Aprovecharemos la robusta red 2G para garantizar que, en caso de caída de la conexión de fibra, la Raspberry Pi ejecute una llamada de voz a nuestro teléfono móvil de forma prioritaria.

¿Por qué es importante este sistema? Si confías en la domótica para la seguridad de tu hogar (alarmas, detectores de inundación o cámaras), una caída de la red, te deja «a ciegas». Saber que tu red ha caído en tiempo real te permite reaccionar antes de que sea tarde.

¿Cómo funciona el flujo de trabajo?

1. Monitorización: La Raspberry Pi realiza «pings» constantes a servidores externos (como los DNS de Google o Cloudflare).
2. Detección: Si el ping falla de forma consecutiva, el script activa el módulo A7670E.
3. Alerta: El HAT ejecuta el comando AT de llamada y marca tu número de teléfono.
4. Acción: Recibes la llamada y sabes, al instante, que algo va mal en casa.

Prepara el software de tu Raspberry.

Para entrar a las funciones del HAT necesitaremos instalar el programa minicom.

sudo apt-get install minicom

Para que nuestro script funcione, necesitas instalar la librería Python Serial:

sudo apt-get install python3-serial -y

Por alguna extraña razón, (que solo he podido observar en Raspberry Pi, ModemManager no se lleva bien con este HAT, intenta secuestrarlo constantemente, como si fuese un módem de los antiguos.

Por eso motivo, ya que no será necesario, optaré por desinstalarlo con:

sudo apt-get purge modemmanager -y

Permisos del usuario.

Tu usuario debe de tener permiso para usar el puerto serie (el módem) por defecto. Si no es así, el script intentará abrir el puerto y al no conseguirlo, se quedará esperando una respuesta que el sistema le bloqueará y no llegará a marcar.

Teclea el siguiente comando para ver los grupos a los que pertenece tu usuario.

groups

Comprueba que tu usuario pertenece al grupo «dialout», si no es así, deberás agregarlo con este comando:

sudo usermod -a -G dialout tu_usuario

Tras ejecutar este comando, reinicia tu Raspberry

sudo reboot

Forzar el modo de alta corriente (Si tu fuente es MUY buena)

En una Raspberry pi 4 es algo común, que si usas varios dispositivos conectados a los puertos USB, Pines GPIO, etc, sufras de cuelgues del sistema y se te queden tus proyectos mas tiesos que la mojama.

Si tienes la fuente oficial de 3A (o una mejor), puedes intentar decirle a la Pi que desbloquee el límite de los USB, aunque esto es automático hasta cierto punto, a veces ayuda asegurar el voltaje. Sin embargo, hay un detalle técnico importante: en la Raspberry Pi 4, el límite de corriente de los USB está fijado por hardware a 1.2A compartidos.

Pero, para «darle chicha» y asegurar que el sistema no entre en pánico cuando el SSD y el HAT 4G trabajen juntos, vamos a aplicar dos ajustes de «estabilidad máxima» que debes tener en cuenta.

1. Evitar el «ahorro de energía» del USB (El culpable del bloqueo)

Cuando el SSD y el HAT piden energía a la vez, el kernel de Linux puede intentar suspender el puerto USB para protegerse, y ahí es donde se congela la Pi. Vamos a prohibirle que lo haga.

Ejecuta este comando para editar el archivo de arranque:

sudo nano /boot/firmware/cmdline.txt

Al final de la línea de texto (sin pulsar Enter, todo en la misma línea), añade un espacio y esto:

usbcore.autosuspend=-1

2. Estabilidad de Voltaje (Config.txt)

Vamos a añadir un parámetro para que la CPU no baje su rendimiento bruscamente cuando detecte picos de consumo del USB, lo que evita que se cuelgue el sistema.

Edita el archivo de configuración:

sudo nano /boot/firmware/config.txt

Añade estas líneas al final:

# Forzar estabilidad de voltaje en puertos USB
avoid_warnings=1

El Hardware: HAT 4G LTE CAT-1 (A7670E)

El HAT 4G LTE CAT-1 para Raspberry Pi (Modelo A7670E), es un módulo compacto pero extremadamente versátil capaz de:

• Realizar y recibir llamadas de voz.
• Enviar y recibir SMS.
• Navegar por internet mediante 4G.
• Obtener datos de GPS

Nota: A partir de este momento, no es necesario tener conectado el cable USB al Módulo 4G, tan solo debe de estar conectado a los pines GPIO

Configurar la Raspberry para usar su puerto serie interno

Por defecto, la Raspberry usa sus pines de transmisión para la «consola» (donde ves letras al arrancar). Hay que liberarlo:

1. Ejecuta:
   sudo raspi-config
2. Ve a Interface Options -> Serial Port.
3. ¿Deseas que la consola sea accesible por serie? NO.
4. ¿Deseas que el hardware del puerto serie esté habilitado? SÍ.
5. Reinicia la Raspberry.

Localizar el nuevo puerto

Una vez iniciado el sistema, vuelve a ingresar a la terminal para que podamos entrar por el puerto físico de los pines de la Raspberry, que suele ser /dev/ttyS0

sudo minicom -D /dev/ttyS0 -b 115200

Si todo va bien, entrarás a la terminal de configuración del módulo. Ahora, debemos comprobar el modo de funcionamiento en el que se encuentra el HAT 4G.

La terminal del módulo 4G

Ahora que estás en la terminal de programación del módulo, escribe el siguiente comando.

AT$MYCONFIG?

Si nos devuelve "usbnetmode"2, es porque el módulo está en modo Serial(modén) que es justo lo que necesitamos.

Pero, si nos devuelve "usbnetmode",0, es porque el módulo está en modo RNDIS (Red) y deberemos desactivarlo.

Cómo desactivar RNDIS

«Muchos tutoriales te obligan a usar el modo RNDIS, pero si tu objetivo es enviar alertas mediante llamadas, el modo Serie (usbnetmode,2) es el secreto para una estabilidad del 100% en placas Raspberry Pi, evitando conflictos de red innecesarios.»

Para dejarlo en modo «serie», que es el la opción indicada para hacer solo llamadas perdidas desde la Raspberry Pi 4, ejecuta esta secuencia exacta en tu terminal:

1. Cambia al modo 2 (Modem/Serie):
   AT$MYCONFIG="usbnetmode",2
2. Desactiva el intento de marcación automática:
   AT+DIALMODE=1
3. Guarda los cambios en la memoria interna (Flash):
   AT&W
4. Reinicia el módulo para que aplique los cambios:
   AT+CRESET

Para salir del terminal del HAT 4G pulsa Ctrl + A y luego Q y volverás a la terminal de Linux.

EL Script

Tras varias pruebas, este script en su versión 4.7, es una solución de monitorización en lenguaje Python, diseñada para informar cuando tu conexión de internet principal falla.

Crea un archivo llamado netguard.py

nano netguard.py

Pega el siguiente código.

No olvides sustituir tu número de teléfono, tu Token de Telegram y tu ID de Telegram.

import os
import time
import serial
import subprocess
import requests
import sys

# --- CONFIGURACIÓN ---
TELEFONO = "600000000"
PUERTO_MODEM = "/dev/serial0"
INTERFAZ_FIBRA = "eth0"
TOKEN_TELEGRAM = "Tu_Token"
ID_CHAT = "Tu_ID"

fibra_estaba_caida = False
llamada_realizada_con_exito = False

def comprobar_fibra():
    try:
        resultado = subprocess.run(
            ["ping", "-I", INTERFAZ_FIBRA, "-c", "2", "-W", "3", "1.1.1.1"],
            stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL
        )
        return resultado.returncode == 0
    except:
        return False

def inicializar_modem(ser):
    """Configuración inicial recomendada para A7670E"""
    comandos = [
        b"AT+CMEE=2\r\n",      # Errores verbosos
        b"AT+CRC=1\r\n",       # Resultados extendidos (útil)
        b"AT+COLP=1\r\n",      # Muestra número cuando contestan (opcional)
        b"AT+CVHU=0\r\n",      # Modo hangup correcto
        b"AT+CLCC=1\r\n",      # (no siempre necesario pero no hace daño)
    ]
    for cmd in comandos:
        ser.write(cmd)
        time.sleep(0.4)
        ser.read_all()  # descartar respuesta

def realizar_llamada_perdida():
    ser = None
    try:
        print(f"\n[{time.strftime('%H:%M:%S')}] ALERTA: Sin internet → Iniciando llamada perdida...", flush=True)
        
        ser = serial.Serial(PUERTO_MODEM, 115200, timeout=1)
        inicializar_modem(ser)

        # Limpieza completa
        ser.reset_input_buffer()
        ser.reset_output_buffer()

        # Registro en red (mejor usar CEREG para LTE, pero CREG también funciona)
        print(" [+] Esperando cobertura...", flush=True)
        for i in range(30):
            ser.write(b"AT+CREG?\r\n")
            time.sleep(1)
            resp = ser.read_all().decode(errors='ignore')
            if ",1" in resp or ",5" in resp:
                print(f" [+] Registrado en red (intento {i+1})", flush=True)
                break
            print(f" [...] Buscando torre... ({i+1}/30)", flush=True)
        else:
            print(" [!] Sin cobertura. Reiniciando módulo...", flush=True)
            ser.write(b"AT+CFUN=1,1\r\n")
            return False

        # Colgar cualquier llamada residual
        ser.write(b"AT+CHUP\r\n")
        time.sleep(0.8)
        ser.read_all()

        # MARCAR
        print(f" 📞 Marcando a {TELEFONO}...", flush=True)
        ser.write(f"ATD{TELEFONO};\r\n".encode())
        time.sleep(1.5)  # esperar OK + VOICE CALL: BEGIN

        print(" [?] Llamada en curso. Esperando que cuelgues (máx 45s)...", flush=True)

        timeout = time.time() + 45
        llamada_activa = False

        while time.time() < timeout:
            # Polling CLCC + lectura de URCs
            ser.write(b"AT+CLCC\r\n")
            time.sleep(0.7)
            resp = ser.read_all().decode(errors='ignore').strip()

            # URC directo del módulo (lo más fiable)
            if "VOICE CALL: END" in resp:
                print(" ✅ Colgado detectado por URC 'VOICE CALL: END'", flush=True)
                return True

            # CLCC desapareció → colgado por receptor
            if "+CLCC:" in resp:
                llamada_activa = True
                print(" → Sonando / activa", flush=True)
            elif llamada_activa and "+CLCC:" not in resp and "OK" in resp:
                print(" ✅ Colgado detectado: CLCC desapareció", flush=True)
                return True

            # Backup: NO CARRIER
            if "NO CARRIER" in resp:
                print(" ✅ Colgado por NO CARRIER", flush=True)
                return True

        # Timeout → colgamos nosotros
        print(" ⏰ Timeout → colgando forzosamente", flush=True)
        ser.write(b"AT+CHUP\r\n")
        return False

    except Exception as e:
        print(f" [!] Error serie: {e}", flush=True)
        return False
    finally:
        if ser and ser.is_open:
            ser.close()

# --- BUCLE PRINCIPAL ---
print("--- Vigilante M2M v5.7 (A7670E optimizado) ---", flush=True)

while True:
    hay_internet = comprobar_fibra()

    if not hay_internet:
        if not fibra_estaba_caida:
            print(f"[{time.strftime('%H:%M:%S')}] Caída de fibra detectada.", flush=True)
            time.sleep(5)
            if not comprobar_fibra():  # doble chequeo
                fibra_estaba_caida = True
                if realizar_llamada_perdida():
                    llamada_realizada_con_exito = True
                else:
                    time.sleep(30)  # reintentar más lento si falló

        elif not llamada_realizada_con_exito:
            if realizar_llamada_perdida():
                llamada_realizada_con_exito = True
            else:
                time.sleep(60)

    elif hay_internet and fibra_estaba_caida:
        print(f"[{time.strftime('%H:%M:%S')}] ✅ Fibra recuperada. Avisando por Telegram...", flush=True)
        try:
            requests.post(
                f"https://api.telegram.org/bot{TOKEN_TELEGRAM}/sendMessage",
                data={"chat_id": ID_CHAT, "text": "✅ Fibra recuperada"},
                timeout=10
            )
        except:
            pass
        fibra_estaba_caida = False
        llamada_realizada_con_exito = False

    time.sleep(20)

Para guardar pulsa Ctrl + o y Ctrl + x para salir

No olvides hacerlo ejecutable con:

chmod +x netguard.py

¿Cómo funciona el script?

El programa actúa como un centinela que vigila la interfaz de fibra (eth0) cada 20 segundos mediante pings ligeros. Su inteligencia reside en cómo gestiona las alertas:

1. El script actúa como un centinela incansable que vigila la interfaz de fibra (eth0) cada 20 segundos mediante pings ligeros. Su inteligencia reside en cómo gestiona las alertas de forma robusta y eficiente, aprovechando al máximo las capacidades del módulo A7670E (según el manual oficial SIMCom A76XX v1.09):
2. Paciencia de Registro (mejorada): No marca a ciegas. Primero interroga al módem con AT+CREG? para confirmar cobertura real (registrado en red roaming o home). Realiza hasta 30 intentos (más margen que antes), con pausas de 1 segundo, dando tiempo al hardware para sincronizarse con la torre más cercana. Si falla tras los intentos, fuerza un reinicio profundo del módulo (AT+CFUN=1,1) para «despertarlo» y buscar señal de nuevo.
3. Inicialización Proactiva del Módem: Antes de cualquier operación crítica, envía comandos de configuración recomendados por SIMCom: AT+CMEE=2 (errores verbosos), AT+CRC=1 (resultados extendidos), AT+COLP=1 (muestra número al contestar, opcional), AT+CVHU=0 (modo colgado correcto). Esto evita errores comunes y mejora la fiabilidad.
4. Detección Inteligente de Colgado (el gran salto): La clave de v5.7 es la detección proactiva y prioritaria usando URCs nativos del módulo:
   • Tras ATD<numero>;, el módem envía automáticamente VOICE CALL: BEGIN cuando empieza a sonar.
   • Mientras la llamada está activa, polling frecuente con AT+CLCC para ver si sigue en lista (+CLCC: presente).
   • Cuando cuelgas desde tu móvil, llega el URC VOICE CALL: END → detección inmediata y casi infalible.
   • Fallbacks: si CLCC desaparece tras haber estado activo, o aparece NO CARRIER.
   • Timeout máximo de 45 segundos (más que suficiente para llamada perdida) → fuerza AT+CHUP si no cuelgas, evitando bloqueos eternos.
5. Flush=True, Timeouts y Limpieza de Buffers: Todas las impresiones usan flush=True para logs inmediatos en journalctl. Las lecturas/escrituras serie tienen timeout=1 y se limpian buffers (reset_input_buffer()) antes y después de comandos clave. Nada se queda «colgado».
6. Reintento Inteligente y Persistencia Educada: Si la llamada falla (sin cobertura, timeout, etc.), el script reintenta en el siguiente ciclo de vigilancia (cada ~20-60 s según estado). Pero una vez que logra que tu móvil suene con éxito (colgado detectado), marca llamada_realizada_con_exito = True y deja de llamar hasta que la fibra se recupere. Así evita saturar tu línea o gastar saldo innecesario.
7. Informe de Retorno por Telegram: Tras la alerta por voz, el script entra en modo «escucha». En cuanto detecta que la fibra ha vuelto (doble chequeo ping para evitar falsos positivos), envía mensaje por Telegram: « Fibra recuperada». Así sabes no solo la caída, sino también el momento exacto de recuperación.

Ademas:

1. Doble verificación de caída (ping + 5 s espera + segundo ping) antes de alertar.
2. Logs limpios: imprime solo lo esencial (puedes reducir aún más los «→ Sonando / activa» editando el contador).
3. Manejo de excepciones y cierre seguro del puerto serie (finally con ser.close()).

En resumen: v5.7 es más fiable, rápida en detección y respetuosa con tu móvil y saldo, gracias a los URC nativos y la configuración proactiva del módulo.

Lanza tu script a ver que ocurre.

python3 netguard.py

Crea el archivo del servicio.

«Haciéndolo Robusto: Creando un Servicio en Systemd» «Un vigilante no sirve de nada si tienes que arrancarlo a mano. Al convertir nuestro script en un servicio de Linux, garantizamos que la vigilancia sea 24/7, incluso si hay un apagón y la Raspberry se reinicia sola. El sistema se encarga de que el script esté siempre vivo.»

Para que este script sea realmente autónomo, debería arrancar al inicio del sistema y si falla o se cierra por un error inesperado, Linux lo reinicia automáticamente en pocos segundos.

Lo ideal es crear un servicio en el sistema (Systemd).

Ejecuta este comando para crear el archivo de configuración:

sudo nano /etc/systemd/system/netguard.service

Copia y pega este contenido (asegúrate de que la ruta /home/tu_usuario/netguard.py sea la correcta donde guardaste el script):

[Unit]
Description=Servicio Vigilante de Fibra por GSM
After=network.target

[Service]
# Fuerza a Python a no guardar nada en memoria intermedia
Environment=PYTHONUNBUFFERED=1
ExecStart=/usr/bin/python3 -u /home/tu_usuario/netguard.py
WorkingDirectory=/home/tu_usuario
User=tu_usuario
# El grupo dialout es clave para que el usuario tenga permiso al módem
Group=dialout
Restart=always
RestartSec=10

# Estas líneas aseguran que Systemd vuelque todo al journal al instante
StandardOutput=journal
StandardError=journal
TTYPath=/dev/ttyS0

[Install]
WantedBy=multi-user.target

Nota: Cambia tu_usuario por el tuyo propio.

Activar y arrancar el servicio

Ahora dale las órdenes a la Raspberry para que lo ponga en marcha:

# Recargar el sistema para que vea el nuevo servicio
sudo systemctl daemon-reload

# Activar para que arranque siempre al encender la Pi
sudo systemctl enable netguard.service

# Arrancar el servicio ahora mismo
sudo systemctl start netguard.service

¿Cómo saber si está funcionando?

Puedes ver el estado del vigilante en tiempo real con este comando:

sudo systemctl status netguard.service

Y si quieres ver los «logs» (lo que el script va imprimiendo):

journalctl -u netguard.service -f

Un ejemplo tras varios dias de funcionamiento del script.

tu_usurio@raspberrypi:~ $ journalctl -u netguard.service -f
mar 01 15:53:48 tu_host python3[3651558]: --- Vigilante M2M v5.7 (A7670E optimizado) ---
mar 01 15:54:13 tu_host python3[3651558]: [15:54:13] Caída de fibra detectada.
mar 01 15:54:22 tu_host python3[3651558]: [15:54:22] ALERTA: Sin internet → Iniciando llamada perdida...
mar 01 15:54:24 tu_host python3[3651558]:  [+] Esperando cobertura...
mar 01 15:54:25 tu_host python3[3651558]:  [+] Registrado en red (intento 1)
mar 01 15:54:25 tu_host python3[3651558]:  📞 Marcando a 600000000...
mar 01 15:54:27 tu_host python3[3651558]:  [?] Llamada en curso. Esperando que cuelgues (máx 45s)...
mar 01 15:54:28 tu_host python3[3651558]:  → Sonando / activa
mar 01 15:54:28 tu_host python3[3651558]:  → Sonando / activa
mar 01 15:54:29 tu_host python3[3651558]:  → Sonando / activa
mar 01 15:54:30 tu_host python3[3651558]:  → Sonando / activa
mar 01 15:54:30 tu_host python3[3651558]:  → Sonando / activa
mar 01 15:54:31 tu_host python3[3651558]:  → Sonando / activa
mar 01 15:55:00 tu_host python3[3651558]:  ✅ Colgado detectado por URC 'VOICE CALL: END'
mar 01 15:55:21 tu_host python3[3651558]: [15:55:21] ✅ Fibra recuperada. Avisando por Telegram...

Troubleshooting (solución de problemas)

Si tu sistema sigue experimentando cuelgues o hace cosas extrañas cuando intenta hacer una llamada, prueba a usar un Hub USB con alimentación propia (La más segura). Conecta el SSD a un Hub USB que tenga su propia fuente de alimentación. Así, la energía para mover el módulo la da el Hub y no la Raspberry. La Pi solo se encarga de los datos. Por lo que, lo más efectivo es separar el consumo.

Prueba final:

Una vez que esté todo funcionando.

1. Desconecta el cable Ethernet para provocar una llamada.
2. Abre abre una terminal y escribe
   ls -R /
3. Si ya no se bloquea, es que la fuente de la Pi 5 y el comando autosuspend=-1 han solucionado el conflicto de energía.

Miscelánea

Estos son los comandos clave para extraer estadísticas y gestionar tu Vigilante como un auténtico administrador de sistemas.

1. El «Resumen de Batalla» (Estadísticas rápidas)

Si quieres saber cuántas veces se ha caído la fibra o cuántas llamadas ha hecho el script sin leer miles de líneas, usa este comando. Filtrará el log y te dará solo los hitos importantes:

journalctl -u netguard.service | grep -E "Caída detectada|Llamada finalizada|Red recuperada"

Esto te mostrará una lista limpia con los días y horas exactas de cada incidente.

2. Comprobar el estado del «Motor»

Si alguna vez dudas de si el script sigue vivo (aunque ya hemos visto que es eterno), este comando te da el informe de salud de Systemd:

systemctl status netguard.service

Fíjate en la línea que dice Active: active (running) since.... Te dirá cuántos días lleva encendido sin interrupciones.

3. Reiniciar tras cambios (SIM, teléfono, etc.)

Si decides cambiar el número de teléfono o el token de Telegram en el archivo .py, no basta con guardar el archivo. Tienes que decirle a la Raspberry que cargue la nueva versión:

sudo systemctl restart netguard.service

Para que mi instalación pueda ponerse en contacto conmigo, necesito la ayuda de sensores online que vigilen constantemente si se produce alguna avería.

El ecosistema Tapo de TP-Link es excelente por su relación calidad-precio, especialmente sus sensores de inundación T300. Sin embargo, tiene un «talón de Aquiles» crítico: la falta de notificaciones por desconexión. Si el Hub H100 o el enchufe P100 se apagan, tu sistema de seguridad muere en silencio.

Aquí te explico cómo convertir tu Raspberry Pi en un vigilante activo que te avisará en segundos si algo falla.

El problema: El silencio de los dispositivos offline

Tanto si la centralita H100 (Hub) como el enchufe P100 que controla el cierre de agua, se avería, sufre un pico de tensión o alguien los desenchufa accidentalmente, el sistema se queda «ciego». El sensor de agua T300 no tiene a quién avisar y la orden de corte nunca se ejecuta.

Lo más preocupante es que la App de Tapo no envía notificaciones si un dispositivo se queda fuera de línea. Para darte cuenta del fallo, tendrías que entrar manualmente en la aplicación y revisar el estado de los iconos uno por uno. En una emergencia o durante unas vacaciones, esta falta de aviso proactivo es un fallo de seguridad inaceptable.

La solución: Un «Watchdog» con Raspberry Pi

Para eliminar este punto ciego, utilizaremos una Raspberry Pi como Watchdog (Perro Guardián). En lugar de esperar a que la App nos avise, la Pi interrogará constantemente a los dispositivos en la red local, si estos no responden, la Pi asume que el sistema está comprometido y dispara una alerta externa.

1. Prepara tu Telegram.

Aprovechando que tenemos telegram (si no lo tienes, ya estás tardando en instalarlo) vamos a utilizarlo para que nos lleguen los avisos de alerta de nuestro script. Para ello crearemos un bot, que será el encargado de gestionar los avisos provenientes de nuestra raspberry.

Crear tu Bot en Telegram (El Emisor)

Primero necesitamos crear la «entidad» que enviará los mensajes desde tu Raspberry Pi.

1. Abre Telegram y busca al usuario @BotFather.
2. Escribe /newbot y dale a enviar.
3. Te pedirá un Nombre para el bot (ejemplo: Vigilante Sótano).
4. Te pedirá un Username (debe terminar en _bot, ejemplo: mi_sotano_seguro_bot).
5. BotFather te responderá con un mensaje largo que contiene el API Token (algo parecido a 74839201:AAH-u7...). Copia y guarda este código, es la clave de acceso.

Obtener tu Chat ID (El Receptor)

Ahora necesitamos saber a qué cuenta de Telegram (la tuya) debe escribirle el bot.

1. Busca en Telegram el bot @userinfobot.
2. Escríbele un mensaje cualquiera (ej. «Hola»).
3. Te responderá con tu ID (un número de 9 o 10 dígitos). Guárdalo también.

2. Crea tu script

Abre tu terminal para crear el archivo con:

nano TapoGuard.py

Pega este código (asegúrate de poner tu Token, tu ID, la IP del H100 y la IP del P100):

import os
import time
import requests

# --- CONFIGURACIÓN ---
TOKEN = "Tu_TOKEN"
CHAT_ID = "TU_ID"

# Diccionario de dispositivos: "Nombre": "IP"
DISPOSITIVOS = {
    "Hub H100": "192.168.1.16",
    "Enchufe Válvula P110": "192.168.1.15"
}

REINTENTOS = 3
SEGUNDOS_ENTRE_CHEQUEOS = 60

# Diccionario para recordar el estado de cada uno (Todos empiezan como Online)
estados_caidos = {nombre: False for nombre in DISPOSITIVOS}

def enviar_telegram(mensaje):
    url = f"https://api.telegram.org/bot{TOKEN}/sendMessage"
    params = {"chat_id": CHAT_ID, "text": mensaje}
    try:
        requests.post(url, params=params, timeout=10)
    except Exception as e:
        print(f"Error de red: {e}")

def chequeo_ip(ip):
    # Lanza un ping. Devuelve True si responde.
    salida = os.system(f"ping -c 1 -W 1 {ip} > /dev/null 2>&1")
    return salida == 0

print("--- Vigilante Tapo Iniciado ---")

while True:
    for nombre, ip in DISPOSITIVOS.items():
        exito = False

        # Intentos de ping para evitar falsas alarmas
        for i in range(REINTENTOS):
            if chequeo_ip(ip):
                exito = True
                break
            time.sleep(1)

        # Lógica de notificaciones individualizada
        if not exito and not estados_caidos[nombre]:
            print(f"[{time.strftime('%H:%M:%S')}] ❌ {nombre} CAÍDO")
            enviar_telegram(f"⚠ ALERTA: El dispositivo '{nombre}' ({ip}) se ha caído de la red.")
            estados_caidos[nombre] = True

        elif exito and estados_caidos[nombre]:
            print(f"[{time.strftime('%H:%M:%S')}] ✅ {nombre} RECUPERADO")
            enviar_telegram(f"✅ OK: El dispositivo '{nombre}' ha vuelto a conectar.")
            estados_caidos[nombre] = False

    time.sleep(SEGUNDOS_ENTRE_CHEQUEOS)

Te aconsejo que pongas una IP fija a tus dispositivos, ya que si esta cambia, el script no funcionará.

Guarda los cambios con Ctrl + o y sal con Ctrl + x

Haz que tu archivo tenga permisos de ejecución.

chmod +x TapoGuard.py

Y pruébalo con:

python3 TapoGuard.py

Desconecta tu Hub del enchufe y observa que ocurre. ¿Te llegaron los mensajes? Ahora conéctalo y vuelve a mirar.

Si todo ha salido bien, tenemos al «cerebro» de la supervisión funcionando.

3. Crea un servicio del sistema (systemd)

Ahora, para que sea un sistema de seguridad permanente, necesitamos que se convierta en un servicio del sistema (un daemon).

De esta forma, si hay un apagón y la Pi se reinicia, el script se levantará solo sin que tengas que teclear nada.

Usa el editor de texto para crear un archivo de configuración en la carpeta del sistema:

sudo nano /etc/systemd/system/TapoGuard.service

Copia y pega este contenido dentro del archivo (ajustando la ruta a tu usuario):

[Unit]
Description=Vigilante del Hub Tapo H100
After=network.target

[Service]
# Asegúrate de que la ruta /home/tu_usuario/TapoGuard.py es la correcta
ExecStart=/usr/bin/python3 /home/tu_usuario/TapoGuard.py
Restart=always
RestartSec=10
User=raspberry

[Install]
WantedBy=multi-user.target

No olvides cambiar tu_usuario por el tuyo propio.

Para guardar Ctrl + o y salir con Ctrl + x

Activa el Servicio

Ahora dale las órdenes a la Raspberry Pi para que lo ponga en marcha:

1. Recarga el sistema para que reconozca el nuevo archivo: sudo systemctl daemon-reload
2. Activa el inicio automático al arrancar: sudo systemctl enable TapoGuard.service
3. Inicia el servicio ahora mismo: sudo systemctl start TapoGuard.service

¿Cómo compruebo que está «vivo»?

Puedes ver el estado de tu vigilante con este comando: sudo systemctl status TapoGuard.service

• Si sale en verde «active (running)», es que está patrullando la IP de tu Hub.
• Ya puedes cerrar la terminal, apagar tu ordenador e irte tranquilo: la Pi se encargará de avisar a tu Telegram si el Tapo H100 deja de responder.

Y si quieres ver los «logs» (lo que el script va imprimiendo):

journalctl -u TapoGuard.service -f

No explicaré aquí como instalar los certificados, ya que lo hice en el primer artículo de este blog Instala WordPress en tu raspberry Pi 4 .

Así, que dando por puesto que ya están instalados en nuestro sistema, ya sea a través de WordPress u otro medio, los reutilizaremos para usarlos con Pi-hole

1. Configuración de puertos.

Entra en Pi-hole desde su interfaz gráfica, ve a Settings, All Settings y Webserver and API y busca el apartado webserver.port y cambia al puerto que necesites configurar.

Originalmente los puertos vienen así:

80o,443os,[::]:80o,[::]:443os

El primer bloque (en azul) corresponde a las direcciones IPV4 y el segundo a IPV6.

A continuación te dejo un ejemplo de puerto HTTP y HTTPS tanto para IPV4 como para IPV6.

7070o,7443os,[::]:7070o,[::]:7443os

Nota: no olvides abrir esos mismos puertos en tu router.

2. Localiza tus certificados.

Lo primero sera buscar la ruta al directorio de tu certificado.

sudo ls -l /etc/letsencrypt/live/

La salida nos mostrará la ruta y con ella el directorio que tendrá el mismo nombre que nuestro dominio.

drwxr-xr-x 2 root root 4096 ago  8 19:00 mi.dominio.org
-rw-r--r-- 1 root root  740 feb 24  2024 README

Por lo que, la ruta completa para tus archivos de certificado será:

sudo ls /etc/letsencrypt/live/mi.dominio.org/

Y el resultado de este último comando, listará los siguientes archivos de certificado.

cert.pem  chain.pem  fullchain.pem  privkey.pem  README

3. Copia tus certificados

Como ya sabemos, los certificados de Let’s Encrypt se guardan en el directorio /etc/letsencrypt/live/mi.dominio.org/.

Tan solo necesitaremos dos archivos del directorio, que son:

• fullchain.pem, que combina los archivos cert.pem seguido de chain.pem, justo en ese orden.
• privkey.pem, que es la clave privada del certificado (nunca la compartas)

Asegúrate de sustituir mi.dominio.org por el nombre de dominio real.

a. – Copia el certificado fullchain.pem a /tmp/

sudo cp /etc/letsencrypt/live/mi.dominio.org/fullchain.pem /tmp/

b. – Copia la clave privada a /tmp/

sudo cp /etc/letsencrypt/live/mi.dominio.org/privkey.pem /tmp/

4. Combina los certificados.

El servidor web interno de Pi-hole v6 requiere que el certificado y la clave privada estén combinados en un solo archivo PEM llamado tls.pem dentro de la carpeta /etc/pihole/.

Situémonos en el directorio /tmp

cd /tmp/

Si listamos el contenido de /tmp, veremos los 2 certificados copiados anteriormente.

me@linuxete:/tmp
$ ls -l
total 32
-rw-r--r-- 1 root root 2872 sep  8 19:57 fullchain.pem
-rw------- 1 root root  241 sep  8 19:58 privkey.pem

Ahora combinaremos los dos archivos que acabamos de copiar, a un único archivo tls.pem:

sudo bash -c "cat fullchain.pem privkey.pem > /tmp/tls.pem"

Verifica que el archivo tls.pem se ha creado correctamente.

me@linuxete:/tmp
$ ls -l
total 16
-rw-r--r-- 1 root root 2872 sep  8 19:57 fullchain.pem
-rw------- 1 root root  241 sep  8 19:58 privkey.pem
-rw-r--r-- 1 root root 3113 sep  8 20:01 tls.pem

5. Permisos de usuario y grupo.

Echa un vistazo al usuario y grupo tiene archivo tls.pem de Pi-hole

me@linuxete:~
$ ls -l /etc/pihole/tls.pem
-rw------- 1 pihole pihole 3113 sep  8 08:18 /etc/pihole/tls.pem

Tanto el usuario como el grupo pertenecen a pihole. Además los permisos están establecidos en 600

Fíjate, que nuestro nuevo archivo (el que se encuentra en /tmp) tiene como usuario a root y los permisos con 644

Vuelve otra vez a directorio /tmp para cambiar eso.

cd /tmp

sudo chown pihole:pihole tls.pem

sudo chmod 600 tls.pem

Ahora ya lo tenemos preparado.

me@linuxete:/tmp
$ ls -l
total 16
-rw-r--r-- 1 root root 2872 sep  8 19:57 fullchain.pem
-rw------- 1 root root  241 sep  8 19:58 privkey.pem
-rw------- 1 pihole pihole 3113 sep  8 20:01 tls.pem

6. Sustituye al viejo tls

Antes de sustituir tu antiguo archivo tls, considera hacer una copia de seguridad.

sudo mv /etc/pihole/tls.pem /etc/pihole/tls.pem.bak

Tan solo nos queda mover el nuevo tls.pem para sustituir al antiguo.

sudo mv /tmp/tls.pem /etc/pihole/tls.pem

7. Reinicia el servicio Pi-hole

Reinicia el servicio de Pi-hole para que cargue el nuevo certificado.

sudo service pihole-FTL restart

Ahora, cuando accedas a la interfaz de administración de Pi-hole en https://tudominio.com:7443/admin, deberías ver que la conexión es segura y que el certificado es válido.

Solución errores y advertencias.

Advertencia, CERTIFICATE_DOMAIN_MISMATCH

La advertencia que ves ahora es solo un mensaje interno del sistema de diagnóstico de Pi-hole que te informa que la configuración predeterminada de su certificado no coincide con su dominio interno (pi.hole).

Si quieres eliminar esa advertencia en la página de diagnóstico, debes decirle a Pi-hole que utilice tu dominio (tu_dominio.org) en lugar de pi.hole como su nombre de host local.

Modo gráfico.

Para solucionar a través de la interfaz web, ve al menú izquierdo de tu pi-hole, abajo verás Settings y dentro verás All settings, en el apartado Webserver and API settings, en el campo Value, cambia pi.hole por tu dominio.

Guarda los cambios y reinicia el equipo.

Modo comandos de terminal

Conéctate a tu Raspberry Pi por SSH o usa la terminal local.

Edita el archivo de configuración TOML

sudo nano /etc/pihole/pihole.toml

Localiza la sección [webserver] y modifica la variable domain: Busca la sección [webserver] (si no existe, créala al final del archivo) y asegúrate de que la línea domain contenga tu dominio:

[webserver] 
# ... otras configuraciones del webserver ... 
domain = "pi.hole"
 # ..

y sustituirla por la de tu dominio.

[webserver] 
# ... otras configuraciones del webserver ... 
domain = "tu_dominio.com"
 # ..

Guarda y cierra el archivo (Ctrl+X, luego Y, luego Enter).

Reinicia Pi-hole FTL para cargar la nueva configuración TOML:

sudo service pihole-FTL restart

Al cambiar domain = "tu_dominio.com" en el archivo pihole.toml, estás estableciendo el nombre de host principal que Pi-hole utiliza para sus comprobaciones internas de HTTPS. Esto debería eliminar el error CERTIFICATE_DOMAIN_MISMATCH de la página de diagnóstico.

Todos sabemos que Linux es muy seguro, pero como alguien acceda físicamente a tu máquina desde un LiveUSB, te hace la pascua. Y es que como se vio en «Como montar tu disco duro desde un Live USB» aprendimos a acceder a los datos de un disco. Ahora ademas, veremos como cambiar la contraseña de un usuario, e incluso la de root.

Para esto se usa Chroot (Change root) que es una utilidad del sistema Unix que se emplea para crear un nuevo entorno separado del directorio raíz del sistema principal. Este nuevo entorno se conoce como una «jaula chroot». Un usuario que opere dentro de la jaula no puede ver ni acceder ficheros fuera del entorno en el que se le ha confinado.

¡Comenzamos!

Inicia cualquier LiveUSB, yo lo haré con Debian 12 XFCE4.

Una vez iniciado el sistema, abre una terminal y escribe:

lsblk -p

Como resultado tendremos esta salida:

demo@mx1:~
$ lsblk -p
NAME                   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
/dev/loop0               7:0    0   2,1G  1 loop /live/linux
/dev/sda                 8:0    0 111,8G  0 disk 
├─/dev/sda1              8:1    0 110,8G  0 part 
├─/dev/sda2              8:2    0     1K  0 part 
└─/dev/sda5              8:5    0   975M  0 part [SWAP]
/dev/sdb                 8:16   0 298,1G  0 disk 
└─/dev/sdb1              8:17   0 298,1G  0 part 
/dev/sdc                 8:32   1  29,3G  0 disk 
├─/dev/sdc1              8:33   1  29,3G  0 part 
│ └─/dev/mapper/ventoy 254:0    0   2,2G  1 dm   /live/boot-dev
└─/dev/sdc2              8:34   1    32M  0 part 
demo@mx1:~

Como puedes observar, se han listado 3 discos:

• /dev/sda que es donde está insalado Debian 12 XFCE (lo sé porque tiene 3 particiones, siendo una de ella la swap)
• /dev/sdb que es un disco que tengo como almacen.
• /dev/sdc que es el propio Pendrive de arranque del Live USB.
• También tenemos el /dev/loop0 que es donde está montado nuestro sistema provisional.

Si con lsblk no tienes toda la información que necesitas para identificar tu disco, puedes usar estos comandos que te dejo a continuación:

• fdisk
  fdisk es otra opción común entre los sysops. Actualmente lista las diferentes particiones (lo que está relacionado con los discos duros, ya que un disco duro puede estar dividido en varias particiones) de su sistema.
  sudo fdisk –list
• parted
  Esta es similar a las anteriores mencionadas, lista todas las particiones y permite gestionarlas. Su principal diferencia es que también te informa de la marca y modelo de tus discos duros e incluso del tipo de conectividad utilizada en el mismo (scsi, sata, etc) y del tamaño total del disco.
  sudo parted -l
• sfdisk
  Esto es muy similar a fdisk, sin embargo sfdisk le permite ver tanto los volúmenes físicos como los lógicos y también le da un «resumen» de las particiones de los volúmenes físicos reales con los cilindros (inicio y final), sectores, tamaño y tipo.
  Probablemente la «s» es por «super», ya que es un fdisk con superpoderes:
  sudo sfdisk -l

Creando el directorio contenedor.

Para el montaje del disco debes crear un directorio al que puedes llamar como quieras, yo lo llamaré disco, y el lugar donde lo haré, será en /media.

Así que en una terminal homologada escribe:

sudo mkdir /media/disco

Montando el disco

Ahora, en la carpeta contenedora llamada disco, montaré el disco sda1 así:

sudo mount /dev/sda1 /media/disco

Si vuelves a hacer un lsblk, verás que sda1, tiene el punto de montaje en esa ruta.

demo@mx1:~
$ lsblk -p
NAME                   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
/dev/loop0               7:0    0   2,1G  1 loop /live/linux
/dev/sda                 8:0    0 111,8G  0 disk 
├─/dev/sda1              8:1    0 110,8G  0 part /media/disco
├─/dev/sda2              8:2    0     1K  0 part 
└─/dev/sda5              8:5    0   975M  0 part [SWAP]
/dev/sdb                 8:16   0 298,1G  0 disk 
└─/dev/sdb1              8:17   0 298,1G  0 part 
/dev/sdc                 8:32   1  29,3G  0 disk 
├─/dev/sdc1              8:33   1  29,3G  0 part 
│ └─/dev/mapper/ventoy 254:0    0   2,2G  1 dm   /live/boot-dev
└─/dev/sdc2              8:34   1    32M  0 part 
demo@mx1:~

Enjaular disco

Para que Chroot funcione, este debe de ser montado dentro de un disco que tenga un sistema linux instalado, ya que bash necesitará estar instalado ahí. Si lo haces sobre un disco vacío, no funcionará ningún comando.

Y ahora que ya lo tenemos montado, ejecutamos el comando chroot para enjaularnos dentro de nuestro disco y poder ejecutar comandos como si estuviésemos operando desde ese disco

sudo chroot /media/disco

En este momento, todo lo que hagamos solo afectará al disco donde estamos enjaulados.

Cambia el password de root así:

passwd root

Y el de usuario, así:

passwd tu_usuario

Ya solo queda reiniciar el equipo, quitar el Live Cd, e introducir las nuevas contraseñas.

Si has llegado hasta aquí, te recomiendo que leas:

• Instala WordPress en tu Raspberry Pi
• Instalar Fail2ban en Debian 12 y que funcione.

Hasta aquí, tenemos un blog funcionando con WordPress y un sistema de bloqueo de accesos como fail2ban.

Ahora vigilaremos los accesos e intentos de acceso al servidor WordPress.

Veamos como configurar todo esto.

Crea el filtro

Crearemos el siguiente fichero /etc/fail2ban/filter.d/wordpress.conf con el contenido:

sudo nano /etc/fail2ban/filter.d/wordpress.conf

Ahora pega lo siguiente:

[Definition]
failregex = ^ .* "(GET|POST) /+wp-login.php
^ .* "(GET|POST) /+xmlrpc.php

Guarda con Crtl + o y cierra con Crtl + x

Crea el jail

Crea también la siguiente jail con:

sudo nano /etc/fail2ban/jail.d/defaults-debian.conf

Pega el lo siguiente a continuación de la última línea:

[wordpress]
enabled = true
port = 443
filter = wordpress
logpath = /var/log/apache2/access.log
maxretry = 3
findtime = 15m
bantime = 1h
action = %(action_mwl)s

Como antes, guarda con Crtl + o y cierra con Crtl + x

Reiniciamos fail2ban:

sudo systemctl restart fail2ban

Comprobaciones.

Vamos a realizar una serie comprobaciones para ver si se están ejecutando correctamente los servicios, estados y advertencias.

Test estado del servicio

Comprobamos el estado del servicio con:

sudo systemctl status fail2ban

De momento todo correcto, el servicio está activo y corriendo.

Test estado general de fail2ban

Comprobamos el estado y la cantidad de jails en funcionamiento.

sudo fail2ban-client status

Perfecto, tenemos dos jail, el primero (ssh) que creamos en Instalar Fail2ban en Debian 12 y que funcione, y el segundo el que acabamos de crear para wordpress.

Test estado de Jails específicos

Comprobemos el estado para la jail de WordPress.

sudo fail2ban-client status wordpress

La salida nos muestra bastante información sobre las IPs baneadas (ninguna por el momento), el número de intentos de conexión, el número de baneos etc etc

Visualizar el log de eventos

Veamos si el archivo log de fail2ban contiene algún error. Visualiza el archivo log en tiempo real para ver los cambios que se van produciendo instantáneamente.

Copia y pega el siguiente comando:

sudo tail -f /var/log/fail2ban.log

En la siguiente imagen verás el log en tiempo real de los jail sin errores.

Test de Fail2ban

Fail2ban tiene un comando testear la configuración. Para esta comprobación tienes que usar este comando:

sudo fail2ban-client --test

Esto demuestra que todo está bien y no tenemos ningún problema con la configuración.

Internet está lleno de gente con menos vergüenza que un gato en una matanza, así que imagino que mi Raspberry Pi, al estar las 24 horas conectada a Internet, estará siendo atacada regularmente. Por este motivo, he decidido instalar Fail2ban.

Si logras poner este tutorial en marcha, descubrirás que no estoy exagerando.

¿Qué es Fail2ban?

Fail2ban es una aplicación que te ayudará a proteger tu servidor contra ataques maliciosos y con la que podrás mantener tus datos seguros.

Fail2ban evitará los accesos de bots, es decir, de máquinas automatizadas que realizan intentos de acceso indiscriminados a los servidores. Este tipo de bots son muy comunes en Internet y simplemente se dedican a intentar loguearse en los servidores, probando diferentes usuarios y claves de acceso, para autorizarse correctamente y tomar el control de la máquina.

Fail2ban se encarga de monitorizar los registros de acceso al servidor en busca de fallos de acceso e impidiendo nuevos intentos de login desde las direcciones IP involucradas, por un tiempo determinado.

Como instalar Fail2ban

Para instalar fail2ban deberemos abrir una terminal y escribir lo siguiente:

sudo apt install fail2ban python3-systemd

Configuración

La configuración de Fail2ban se encuentra en la carpeta «/etc/fail2ban/«. Allí encontraremos un archivo llamado «jail.conf» con las configuraciones del sistema.

Pero nosotros trabajaremos con una copia del archivo jail.conf a la que llamaremos jail.local, ya que así evitaremos que tras una actualización este pueda ser sustituido por la versión por defecto, cambiando así toda nuestra configuración.

El archivo jail.local se carga después de jail.conf y en él realizaremos nuestra configuración, por lo que todo lo que se escriba en jail.local es lo que se va a tener en cuenta definitivamente.

La copia del archivo jail.conf, la haremos desde la terminal con el comando cp (copy)

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Ahora abre el archivo en cuestión

sudo nano /etc/fail2ban/jail.local

Configuración Default (por defecto)

En la sección [DEFAULT] encontramos las configuraciones predeterminadas que afectarán a todos los jail. Todas las configuraciones que pongas en [DEFAULT] son heredadas por los jail

En la sección «[DEFAULT]» encontramos la configuración global de las opciones. Allí veremos diversas variables a definir como las siguientes:

• ignoreip: Aquí puedes añadir direcciones IP que nunca serán baneadas por Fail2ban. Por ejemplo, nuestra propia dirección IP.
• bantime: es el tiempo que una IP será baneada, expresado en segundos, minutos, horas, días …. (por defecto en 10 minutos)
• findtime: es el tiempo que transcurre entre intentos de conexión antes de ser baneado. (por defecto en 10 minutos)
• maxretry: es el número máximo de intentos de login que podrán realizarse antes de que la IP sea baneada. (por defecto en 5 intentos)

Nota si quieres que se ignoren todas las ips procedentes de tu red local, escribe la primera dirección IP (que suele ser la del router) seguido de un /24, esto hará que no se tengan en cuenta las direcciones de la 1 a la 254.

Seguimos cambiando otras cosas de la sección Default.

Como yo no uso iptables, ya que el firewall lo tengo activo a nivel de router, haremos algunos cambios.

Busca las siguientes líneas y comenta con el signo #

[Default]

banaction = iptables-multiport
banaction_allports = iptables-allports

Pega debajo las siguientes líneas.

banaction = nftables
banaction_allports = nftables[type=allports]

Quedando como en la siguiente imagen.

Guarda con Ctrl + o

Configuración de Jail

Baja hasta la sección JAILS, SSH servers, [sshd].

#
# JAILS
#

#
# SSH servers
#

[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and det>
#mode   = normal
port    = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s

Justo debajo de #mode = normal, añade lo siguiente:

enabled = true

Esto habilitada el jail sshd.

Debajo, moddifica las líneas en negrita, que son, el puerto de conexión, la ruta de log de eventos y el backend

[sshd]
enabled = true
port    = 2353
logpath = %(sshd_log)s
backend = systemd

Quedando todo así:

#
# JAILS
#

#
# SSH servers
#

[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and det>
#mode   = normal
enabled = true
port    = 2353
logpath = %(sshd_log)s
backend = systemd

Nota: Cambia port por el puerto que usas en tu servidor ssh

Reinicia el el servicio fail2ban así:

sudo systemctl restart fail2ban

Hasta aquí todo listo, ya solo queda comprobar que todo va bien.

Comprobaciones.

Vamos a realizar una serie comprobaciones para ver si se están ejecutando correctamente los servicios, estados y advertencias.

Test estado del servicio

Comprobamos el estado del servicio con:

sudo systemctl status fail2ban

Es posible que después de hacer una status, el servicio aparezca inactivo, como se muestra en la siguiente imagen.

Para arreglar esto, haz lo siguiente. En una terminal, escribe:

sudo echo "sshd_backend = systemd" >> /etc/fail2ban/paths-debian.conf

Reinicia el servicio con:

sudo systemctl restart fail2ban

Y volvemos a ver el estado de como está el servicio:

sudo systemctl status fail2ban

Ahora está todo correcto, el servicio aparece activo y corriendo.

Test estado general de fail2ban

Comprobamos el estado y la cantidad de jails en funcionamiento.

sudo fail2ban-client status

Test estado de Jails específicos

Para comprobar si una jail específica funciona, en mi caso, ssh, ejecuta el siguiente comando:

sudo fail2ban-client status sshd

La salida nos muestra bastante información sobre las IPs baneadas, el número de intentos de conexión, el número de baneos etc etc

Visualizar el log de eventos

Veamos si el archivo log de fail2ban contiene algún error. Visualiza el archivo log en tiempo real para ver los cambios que se van produciendo instantáneamente.

Copia y pega el siguiente comando:

sudo tail -f /var/log/fail2ban.log

En la siguiente imagen verás que no aparece ningún error y se carga nuestro jail sshd

Test de Fail2ban

Fail2ban tiene un comando testar la configuración. Para esta comprobación tienes que usar este comando:

sudo fail2ban-client --test

Vaya! tenemos un mensaje de advertencia. No es un error, tampoco afectará al funcionamiento de fail2ban, pero se puede arreglar.

Corregir advertencia Warning IPV6

Para arreglar esto tendremos que abrir el archivo de configuración que se encuentra en /etc/fail2ban/fail2ban.conf

sudo nano /etc/fail2ban/fail2ban.conf

Ve al apartado [Definition], verás que está vacío y escribe debajo lo siguiente:

 allowipv6 = auto

Quedando de la siguiente manera:

Volvemos a repetir el test y ahora se habrá quitado el mensaje de advertencia.

Test de Baneo

Provocamos un ban sobre nosotros para ver si la configuración es correcta.

Intento entrar por ssh desde mi teléfono móvil con una contraseña errónea. Debe de haber 5 intentos de conexión y un baneo de 10 minutos.

Al quinto intento nos banea y como vimos antes, hasta transcurridos 10 minutos no dejará que volvamos a probar.

Pasados 10 minutos, tal como está configurado en [Default] se levanta el baneo y dará permiso para volver a dejarnos entrar.

Mi teléfono vuelve a dejarnos escribir la contraseña.

Desbanear una IP

Las IP baneadas pueden ser sacadas de la lista de ban sin tener que esperar al tiempo de ban por defecto. Para ello usa unban y la ip a desbanear.

sudo fail2ban-client unban 192.168.1.1

Envío de alertas por email.

Para que fail2ban envíe alertas por email, debes de tener instalado y configurado algún programa que envíe correos electrónicos. En mi caso uso sSMTP y la configuración que usaré en fail2ban, será con este programa.

sSMTP es un programa que envía correo electrónico desde un equipo a un servidor de correo configurado. Es decir que este no es un servidor de correo como si lo es sendmail o postfix sino que solo se encarga del envío de correos.

Fail2ban te avisará cuando una IP sea baneada, aportando una valiosa información acerca de su procedencia, proveedor etc etc

Importante, es indispensable instalar y configurar sSMTP

Si no tienes instalado y configurado sSMTP entra aquí «Como enviar emails con sSMTP» y seguir los pasos que allí te indico.

Si ya tienes configurado sSMTP, puedes seguir con la configuración jail.local ….

En una terminal homologada, escribe el siguiente comando:

sudo nano /etc/fail2ban/jail.local

Ve al apartado Actions

Busca la líneas que dicen, destemail y mta

# Some options used for actions

# Destination email address used solely for the interpolations in
# jail.{conf,local,d/*} configuration files.
destemail = root@localhost

# Sender email address used solely for some actions
sender = root@<fq-hostname>

# E-mail action. Since 0.8.1 Fail2Ban uses sendmail MTA for the
# mailing. Change mta configuration parameter to mail if you want to
# revert to conventional 'mail'.
mta = sendmail

En destemail escribe la dirección de correo a la que llegarán las alertas, por ejemplo mi_email@gmail.com
En mta aquí usa el modo en que tu programa envía mails, en el caso de sSMTP pondré sendmail

# Some options used for actions

# Destination email address used solely for the interpolations in
# jail.{conf,local,d/*} configuration files.
destemail = mi_email@gmail.com

# Sender email address used solely for some actions
sender = root@<fq-hostname>

# E-mail action. Since 0.8.1 Fail2Ban uses sendmail MTA for the
# mailing. Change mta configuration parameter to mail if you want to
# revert to conventional 'mail'.
mta = sendmail

Ve al Jail [sshd ] de la ruta /etc/fail2ban/jail.local

sudo nano /etc/fail2ban/jail.local

Añade al fina la siguiente línea

action = %(action_mwl)s

action = “mw” después de “action_” le dice a Fail2ban que le envíe correos electrónicos. “mwl” además adjunta los registros.

Ahora nuestra Jail sshd queda de la siguiente manera:

[sshd]
enabled = true
port    = 2353
logpath = %(sshd_log)s
backend = systemd
action = %(action_mwl)s

Reinicia el servicio fail2ban

sudo systemctl restart fail2ban

Vuelve a visualizar el log de eventos a ver si todo está correcto

sudo tail -f /var/log/fail2ban.log

Si todo anda bien y no recibes errores, puedes intentar loguearte por ssh de forma errónea por 5 veces consecutivas y recibirás un bonito mail de baneo.

Fallo de email al inicio (corrección)

Aunque todo marcha bien, es muy probable que al arrancar el sistema, no lleguen los emails de inicio del servicio.

Esto se debe a que Fail2ban inicia su servicio de envío de correo antes de que el servicio de red esté completamente disponible. Como resultado, no puede alcanzar el servidor SMTP y el proceso falla. Cuando reinicias el servicio manualmente, la red ya está en pleno funcionamiento y la conexión se realiza sin problemas.

Visualiza en busca de errores

Una vez iniciado el sistema, haz un tail al registro de fail2ban para ver si tienes algún error

raspberry@pi5:~
sudo tail -f /var/log/fail2ban.log
To: mi_email@gmail.com\n
Hi,\n
The jail sshd has been started successfully.\n
Regards,\n
Fail2Ban" | /usr/sbin/sendmail -f "email@gmail.com" "mi_email@gmail.com"
2025-08-30 06:30:04,525 fail2ban.utils          [932]: ERROR   7fff679379b0 -- stderr: 'sendmail: Cannot open smtp.gmail.com:587'
2025-08-30 06:30:04,525 fail2ban.utils          [932]: ERROR   7fff679379b0 -- returned 1
2025-08-30 06:30:04,526 fail2ban.actions        [932]: ERROR   Failed to start jail 'sshd' action 'sendmail-whois-lines': Error starting action Jail('sshd')/sendmail-whois-lines: 'Script error'
2025-08-30 06:30:05,506 fail2ban.filtersystemd  [932]: INFO    [sshd] Jail is in operation now (process new journal entries)
2025-08-30 06:38:04,525 fail2ban.filter         [932]: INFO    [sshd] Ignore 192.168.1.50 by ip

El primer error sendmail: Cannot open smtp.gmail.com:587, nos indica que fail2ban no pudo establecer una conexión con el servidor de correo de Gmail

Como resultado del fallo anterior Failed to start jail 'sshd' action 'sendmail-whois-lines': Error starting action Jail('sshd')/sendmail-whois-lines: 'Script error'nos dice que Fail2ban intentó ejecutar una acción (sendmail-whois-lines) para notificar que la jail de sshd se había iniciado, pero debido a que el envío de correo falló, la acción completa no pudo completarse.

Solución al problema.

Dentro de la ruta etc/systemd/system/ crearemos un directorio con el nombre fail2ban.service.d y a su vez dentro de este crearemos un archivo con el nombre override.conf. Systemd lo detectará y le dará prioridad sobre la configuación original del servicio.

Nota, nunca edites los archivos originales de la ruta /lib/systemd/system/ ya que pueden ser modificados tras un actualización del sistema.

Usa el comando mkdir -p para crear el directorio.

sudo mkdir -p /etc/systemd/system/fail2ban.service.d/

Utiliza el comando sudo nano para crear el archivo.

sudo nano /etc/systemd/system/fail2ban.service.d/override.conf

Dentro del archivo pega las siguientes líneas:

[Unit]
After=network.target network-online.target
Wants=network-online.target

Guarda el archivo, presiona Ctrl + O (para «Write Out», que es guardar), confirma el nombre del archivo y luego presiona Enter.
Sal del editor. Presiona Ctrl + X.

Estas tres líneas de configuración en systemd le dicen al sistema cómo y cuándo iniciar un servicio en relación con el estado de la red. Sirven para asegurar que un servicio, como Fail2ban, no se inicie antes de que la conexión a Internet esté completamente operativa.

Ahora, recarga systemd para que lea el nuevo archivo de configuración.

sudo systemctl daemon-reload

Reinicia el sistema

sudo reboot

Cuando cargue el sistema completamente, mira en tu bandeja de entrada y comprobarás los email de stopped, pero sobre todo los de started te aparecen.

Control de fallos (incremento de la seguridad)

Tenemos una opción con la que incrementar el tiempo de baneos de una ip. Con esta configuración, proporcionamos una protección más dinámica contra ataques de fuerza bruta, por lo que, si los atacantes persisten, serán bloqueados por períodos de tiempo cada vez más largos, lo que dificulta sus intentos de acceso.

Esto lo realizaremos con fail.increment, con lo que fail2ban aumentará el tiempo de bloqueo para cada intento fallido adicional de una IP.

¿Cómo funciona?

Si una IP falla X veces en X minutos, se bloqueará durante X horas.

Si la misma IP intenta conectarse nuevamente y falla otras X veces en X minutos, el tiempo de bloqueo se multiplicará por X horas.

Este proceso continúa, aumentando el tiempo de bloqueo en cada intento fallido adicional, hasta alcanzar el tiempo máximo de bloqueo definido en fail2ban_increment_max_bantime.

¿Cómo lo hago?

Vuelve a editar el archivo jail.local desde la terminal.

sudo nano /etc/fail2ban/jail.local

Ahora en nuestro jail sshd, continua añadiendo las siguientes líneas.

maxretry = 3
findtime = 10m
bantime = 1h
bantime.increment = true 
bantime.factor = 1.5 
bantime.maxtime = 1d

Quedando de la siguiente manera

[sshd]
enabled = true
port = 2353
logpath = %(sshd_log)s
backend = systemd
action = %(action_mwl)s
maxretry = 3
findtime = 10m
bantime = 1h
bantime.increment = true
bantime.factor = 1.5
bantime.maxtime = 1d

Explicación de los parámetros clave

• enabled = true: Activa el jail para SSH.
• port = ssh: Especifica el puerto SSH (generalmente 22).
• logpath = %(sshd_log)s Define la ruta al archivo de registro de autenticación.
• maxretry = 3: Establece el número máximo de intentos fallidos antes de bloquear una IP.
• bantime = 1h: Tiempo de bloqueo inicial de 1 hora.
• findtime = 10m: Tiempo en el que se buscan los intentos fallidos (10 minutos).
• fail2ban_actions: Define las acciones que se realizarán al bloquear una IP (bloqueo, envío de correo electrónico, etc.).
• bantime.increment = true: Habilita la función de incremento de tiempo de bloqueo.
• bantime.factor = 1.5: Factor por el cual se multiplicará el tiempo de bloqueo en cada intento fallido adicional.
• bantime.maxtime = 1d: Tiempo de bloqueo máximo de 1 día.

¿Cómo funciona fail.increment?

En el ejemplo anterior, fail2ban aumentará el tiempo de bloqueo para cada intento fallido adicional de una IP. Por ejemplo:

Si una IP falla 3 veces en 10 minutos, se bloqueará durante 1 hora.

Si la misma IP intenta conectarse nuevamente y falla otras 3 veces en 10 minutos, el tiempo de bloqueo se multiplicará por 1.5 (1.5 horas).

Este proceso continúa, aumentando el tiempo de bloqueo en cada intento fallido adicional, hasta alcanzar el tiempo máximo de bloqueo definido en fail2ban_increment_max_bantime.

Reincidentes

¿Y que pasa con aquellos que son como moscas cojoneras, esos que no se dan por vencidos, y duran y duran como el conejito de Duracell? A esos los llamaremos los reincidentes, y para ellos existe un lugarl llamado Recidive Jail (cárcel para reincidentes).

¿Qué es el recidive jail?

La palabra «recidive» se refiere a la reincidencia. El recidive jail es un jail especial de fail2ban diseñado para detectar y banear a las direcciones IP reincidentes, es decir, aquellas que han sido baneadas en múltiples ocasiones por diferentes jails (o el mismo jail) en un corto período de tiempo.

En lugar de banear a una IP por un único ataque de fuerza bruta, el recidive jail la considera una amenaza persistente y la castiga con un bloqueo mucho más largo.

¿Cómo funciona?

A diferencia de otros jails que monitorean archivos de registro de servicios específicos (como SSH o Apache), el recidive jail monitorea el propio archivo de registro de fail2ban (/var/log/fail2ban.log). Busca entradas que indiquen que una IP ha sido baneada y, si el mismo atacante ha sido baneado varias veces, aplica un nuevo bloqueo, mucho más largo.

¿Cómo lo activo?

El recidive jail suele venir preconfigurado en las instalaciones de fail2ban. Para activarlo, generalmente solo necesitas editar tu archivo de configuración jail.local y asegurarte de que la sección [recidive] esté habilitada (enabled = true).

Escribe en tu terminal homologada:

sudo nano /etc/fail2ban/jail.local

Busca las siguientes líneas, donde dice [recidive] (si usas el editor nano, Crtl + w te permite buscar por palabra clave)

# Jail for more extended banning of persistent abusers
# !!! WARNINGS !!!
# 1. Make sure that your loglevel specified in fail2ban.conf/.local
#    is not at DEBUG level -- which might then cause fail2ban to fall into
#    an infinite loop constantly feeding itself with non-informative lines
# 2. Increase dbpurgeage defined in fail2ban.conf to e.g. 648000 (7.5 days)
#    to maintain entries for failed logins for sufficient amount of time
[recidive]

logpath  = /var/log/fail2ban.log
banaction = %(banaction_allports)s
bantime  = 1w
findtime = 1d

Si no lo tienes o lo tienes en false, añade debajo de [recidive] la variable enabled=true

# Jail for more extended banning of persistent abusers
# !!! WARNINGS !!!
# 1. Make sure that your loglevel specified in fail2ban.conf/.local
#    is not at DEBUG level -- which might then cause fail2ban to fall into
#    an infinite loop constantly feeding itself with non-informative lines
# 2. Increase dbpurgeage defined in fail2ban.conf to e.g. 648000 (7.5 days)
#    to maintain entries for failed logins for sufficient amount of time
[recidive]

enabled = true
logpath  = /var/log/fail2ban.log
banaction = %(banaction_allports)s
bantime  = 1w
findtime = 1d
maxretry = 3

También he añadido un maxretry = 3, ya que no tampoco estaba en la configuración inicial.

Que significa esto:

• bantime: Este es el tiempo que durará el bloqueo por reincidencia. En este ejemplo, es 1 semana (1w). Puedes ajustarlo a tu gusto (por ejemplo, 1d para 1 día, 24h para 24 horas, o incluso 1y para 1 año, tambien con -1 sería por tiempo indefinido).
• findtime: Este es el período de tiempo durante el cual fail2ban buscará reincidencias. En este ejemplo, el jail buscará si una IP ha sido baneada en cualquier otro jail durante el último día (1d).
• maxretry = 3: Este valor significa que si una misma IP es baneada en cualquiera de tus jails (SSH, WordPress, etc.) 3 veces en el período de 1d (findtime), el recidive jail se activará y le aplicará el baneo de 1 año. El valor de 3 es un buen punto de partida, ya que un atacante podría haber sido baneado dos veces en sshd o en wordpress y la tercera vez, independientemente del servicio, será baneado por el recidive jail.

Nota: Revisando la documentación de fail2ban, la manera en que el recidive jail detecta la reincidencia es mediante la lectura de su propio registro (/var/log/fail2ban.log). El jail se activa cuando encuentra la palabra «Ban» un número de veces dentro del findtime especificado.

Veamos ahora que nos dice nuestro fail2ban.log

sudo tail -f /var/log/fail2ban.log

raspberry@pi5:~
$ sudo tail -f /var/log/fail2ban.log
2025-08-25 22:50:46,292 fail2ban.filter         [374644]: INFO    [wordpress] Ignore 192.168.1.1 by ip
2025-08-25 22:51:26,359 fail2ban.filter         [374644]: INFO    [wordpress] Ignore 192.168.1.1 by ip
2025-08-25 22:52:26,340 fail2ban.filter         [374644]: INFO    [wordpress] Ignore 192.168.1.1 by ip
2025-08-25 22:52:31,651 fail2ban.actions        [374644]: NOTICE  [wordpress] Unban 59.125.157.215
2025-08-25 22:53:37,381 fail2ban.filter         [374644]: INFO    [wordpress] Found 65.109.154.253 - 2024-08-29 22:53:37
2025-08-25 22:53:37,563 fail2ban.filter         [374644]: INFO    [wordpress] Found 65.109.154.253 - 2024-08-29 22:53:37
2025-08-25 22:53:44,556 fail2ban.filter         [374644]: INFO    [wordpress] Found 65.109.154.253 - 2024-08-29 22:53:44
2025-08-25 22:53:44,881 fail2ban.actions        [374644]: NOTICE  [wordpress] Ban 65.109.154.253
2025-08-25 22:53:44,885 fail2ban.filter         [374644]: INFO    [recidive] Found 65.109.154.253 - 2024-08-29 22:53:44
2025-08-25 22:54:54,188 fail2ban.filter         [374644]: INFO    [sshd] Ignore 192.168.1.50 by ip
2025-08-25 22:58:51,595 fail2ban.filter         [374644]: INFO    [wordpress] Found 101.68.43.75 - 2024-08-29 22:58:51
2025-08-25 22:58:52,296 fail2ban.filter         [374644]: INFO    [wordpress] Found 101.68.43.75 - 2024-08-29 22:58:52
2025-08-25 22:58:58,201 fail2ban.filter         [374644]: INFO    [wordpress] Found 101.68.43.75 - 2024-08-29 22:58:57
2025-08-25 22:58:58,261 fail2ban.actions        [374644]: NOTICE  [wordpress] Ban 101.68.43.75
2025-08-25 22:58:58,266 fail2ban.filter         [374644]: INFO    [recidive] Found 101.68.43.75 - 2024-08-29 22:58:58

La línea INFO [recidive] Found 65.109.154.253 e INFO [recidive] Found 101.68.43.75 significan que recidive se ha dado cuenta de que esa IP ha sido baneada en mas de una ocasión, pero aún no han sido baneadas por recidive porque no han cumplido los criterios de reincidencia.

Como podemos ver en la salida del comando:

sudo fail2ban-client status recidive

Esto no significa que recidive haya enviado ya la haya baneado.

raspberry@pi5:~
$ sudo fail2ban-client status recidive
Status for the jail: recidive
|- Filter
|  |- Currently failed:	19
|  |- Total failed:	19
|  `- File list:	/var/log/fail2ban.log
`- Actions
   |- Currently banned:	0
   |- Total banned:	0
   `- Banned IP list:	

En la salida de fail2ban-client status recidive, observamos que:

• Currently failed: 19 y Total failed: 19: Esto confirma que el filtro del recidive jail ha detectado 19 baneos totales en otros jails. El recidive jail está haciendo su trabajo de contar los baneos.
• Currently banned: 0 y Total banned: 0: Esto indica que ninguna de las IPs ha alcanzado el umbral para ser considerada reincidente. Las IPs anteriormente mostradas en el log (65.109.154.253 y 101.68.43.75) han sido baneadas una sola vez en el log, por lo que no han activado la acción de ban del recidive jail.

Mi configuración.

Y para terminar, después de un tiempo de uso, he estado probando varias configuraciones, y estas son las que uso actualmente:

Configuración [sshd]

[sshd]
enabled = true
port    = 2353
logpath = %(sshd_log)s
backend = systemd
action = %(action_mwl)s
maxretry = 3
findtime = 10m
bantime = 1h
bantime.increment = true
bantime.factor = 24
bantime.maxtime = 5w

Configuración [recidive]

# Jail for more extended banning of persistent abusers
# !!! WARNINGS !!!
# 1. Make sure that your loglevel specified in fail2ban.conf/.local
#    is not at DEBUG level -- which might then cause fail2ban to fall into
#    an infinite loop constantly feeding itself with non-informative lines
# 2. Increase dbpurgeage defined in fail2ban.conf to e.g. 648000 (7.5 days)
#    to maintain entries for failed logins for sufficient amount of time
[recidive]

enabled = true
logpath  = /var/log/fail2ban.log
banaction = %(banaction_allports)s
bantime  = 1y
findtime = 1d
maxretry = 3

Tal vez te estés preguntando, ¿para que usamos bantime.increment con un bantime.maxtime de 5 semanas, si en un día los reincidentes serán expulsados por un año?. ¿No le dará tiempo a bantime.increment a echar a nadie por 5 semanas?

Pues tiene su lógica, imaginemos 2 escenarios distintos:

Escenario 1: Ataques que no cumplen los criterios de recidive

• Un atacante muy lento y persistente: Un atacante podría hacer un par de intentos, ser baneado, y no volver a intentar nada por 36 horas. Luego, repite el proceso. Como el findtime de tu recidive jail es 1d (un día), los intentos de este atacante podrían quedar fuera del rango de detección de recidive. En este caso, el bantime.increment seguirá aumentando el tiempo de baneo con cada nuevo intento, sin que recidive se active.

Escenario 2: Ataques contra un solo servicio y de forma intermitente

• Si un atacante solo se enfoca en SSH y va incrementando su tiempo de espera entre ataques, el bantime.increment del sshd jail se encargará de él. Un atacante podría ser baneado por 1 hora, luego 24 horas, y luego 5 días. Si el atacante vuelve a intentar después de los 5 días, el bantime.increment seguiría su progresión hasta alcanzar las 5 semanas, castigando el comportamiento persistente en ese servicio en particular, sin que el recidive jail se active si no cumple con sus criterios de frecuencia.

Conclusión

Pensemos en nuestros jails como una defensa por capas:

1. Capa 1: Jails individuales (sshd, wordpress, etc.). Son tu primera línea de defensa, con reglas para bloquear ataques de fuerza bruta rápidos.
2. Capa 2: bantime.increment. Es la capa que maneja la persistencia contra un único servicio. Su propósito es hacer cada vez más costoso para un atacante seguir intentando contra ese servicio.
3. Capa 3: recidive jail. Es la defensa definitiva contra la reincidencia general en tu sistema. Se encarga de los atacantes más serios que atacan múltiples servicios o persisten a pesar de los baneos iniciales.

El bantime.maxtime garantiza que la Capa 2 sea muy efectiva por sí misma, incluso si el atacante no cumple los criterios para ser considerado «reincidente» por el recidive jail. Por lo que conviene usarlo, ya que cubre escenarios que el recidive jail no. Esta configuración es muy sólida y está bien pensada, ya que combina de manera excelente estas diferentes capas de seguridad.