En este mismo blog hay una entrada en la que explico como configurar ReadyMedia, Ahora te ensenaré a configurarlo de forma mas segura.

Este servidor es bastante simple de configurar, pero a veces las cosas sencillas se pueden complicar.

El problema.

El problema de ReadyMedia, es debido al permiso predeterminado del directorio de inicio /home.

Anteriormente, el permiso del directorio de inicio del usuario se establecía en 755, lo que permitía a otros usuarios ver el directorio, así como los archivos y subdirectorios que lo contenían. Para evitar este problema de seguridad, los desarrolladores establecieron el permiso para los directorios de inicio como 700, lo que significa que solo el propietario del directorio de inicio puede ver el contenido.

Si quieres compartir cualquier carpeta dentro de tu directorio /home, esto causa un gran problema con minidlna, ya que el propietario del directorio de inicio es el único que puede acceder o atravesar la carpeta ya sea localmente o a través de su LAN. Este cambio se realizó únicamente por razones de seguridad, y creo que fue el camino correcto, ya que no hay ninguna razón por la que otros usuarios puedan ver el contenido del directorio de inicio de los demás.

1-. Instalación.

Como sistema operativo voy a utilizar Debian 12, como servidor DLNA voy a utilizar ReadyMedia en su versión actual 1.3.0 y mi usuario será Pantuflo.

Para instalar el servidor DLNA ReadyMedia en Debian escribe lo siguiente en la terminal:

sudo apt install minidlna

2-. Crea los directorios

Como dije antes, el directorio /home está protegido contra escritura, así que nosotros crearemos en la raiz, un directorio llamado minidlna al que haremos de nuestra propiedad.

Abre tu terminal para iniciar en tu /home, cambia al directorio raíz de la siguiente manera:

cd /

Si haces un ls verás que estás en la raiz del sistema.

Pantuflo@computer:/$ ls
bin   etc         initrd.img.old  lost+found  opt   run   sys  var
boot  home        lib             media       proc  sbin  tmp  vmlinuz
dev   initrd.img  lib64           mnt         root  srv   usr  vmlinuz.old

Ahora crea la carpeta llamada minidlna y dentro de esta, un subdirectorio llamado cache.

sudo mkdir -p minidlna/cache

Una vez creada la carpeta, esta pertenecerá a root, pero nosotros la haremos propiedad del usuario Pantuflo

sudo chown -R Pantuflo:Pantuflo minidlna

Con esto hemos cambiado la carpeta minidlna y el subdirectorio cache a nuestra propiedad.

3-. Configuración de minidlna.

La configuración de este servidor multimedia se encuentra almacenada dentro del fichero “minidlna.conf”

Accedemos a la configuración con el siguiente comando:

sudo nano /etc/minidlna.conf

Nombre de usuario.

Comenzamos por la línea que dice #user=minidlna, sustituye por:

user=Pantuflo

Añade los directorios a compartir.

Se pueden añadir directorios dentro de nuestro propio sistema, o bien desde fuera, como un disco usb. Si nuestros archivos están en otro disco, diferente del sistema operativo, tendrás que montarlos al inicio siguiendo esta guía Montar particiones al inicio en Debian 12

Busca la siguientes lineas

# set this to the directory you want scanned.
# * if you want multiple directories, you can have multiple media_dir= lines
# * if you want to restrict a media_dir to specific content types, you
#   can prepend the types, followed by a comma, to the directory:
#   + "A" for audio  (eg. media_dir=A,/home/jmaggard/Music)
#   + "V" for video  (eg. media_dir=V,/home/jmaggard/Videos)
#   + "P" for images (eg. media_dir=P,/home/jmaggard/Pictures)
#   + "PV" for pictures and video (eg. media_dir=PV,/home/jmaggard/digital_camera)

media_dir=AV,/home/Pantuflo/.aMule/Inconming
media_dir=APV,/mnt/Delos/
media_dir=APV,/mnt/Delfos/

Justamente debajo escribe las rutas a los archivos a compartir. En mi caso voy compartir los audios y vídeos de la carpeta Incoming y los Audios, Vídeos y Fotos de los discos llamados Delos y Delfos.

Según la letra que elijamos (A,V,P) podemos configurar rutas diferentes para:

A audios
V vídeos
P pictures o fotos

Ejemplo de configuración de algunas carpetas.

#Compartir audios de la carpeta Musica
media_dir=A,/home/tu_usuario/Música

#Compartir los videos de la carpeta Videos
media_dir=V,/home/tu_usuario/Vídeos

#Compartir las imágenes de la carpeta imágenes
media_dir=P,/home/tu_usuario/Imágenes

#Compartir audio, video e imágenes de directorio
media_dir=AVP,/home/tu_usuario/directorio

Base de datos y caché de carátulas.

Sigue buscando hasta llegar a #db_dir/=/var/cache/minidlna y modifica a lo siguiente:

db_dir=/minidlna/cache

Archivo de Registro:

Hacemos lo mismo con el directorio de logs o registros, #log_dir=/var/log/minidlna, y modifica a lo siguente:

log_dir=/minidlna

Añade un nombre al servidor.

Busca la línea friendly_name y elige el nombre de tu interés. Yo llamaré a mi servidor ReadyMedia

friendly_name=ReadyMedia

Auto-actualizar el contenido.

Si queremos que cada vez que hayamos añadido nuevo contenido a cualquiera de los directorios anteriormente indicados sea detectado por el servidor de forma automática, deberemos de agregar o descomentar la siguiente directiva:

inotify=yes

Tiempo de actualización.

Configurar el intervalo de notificación SSDP, en segundos

notify_interval=60

Una vez termines de cambiar todos estos parámetros guarda con Ctrl + o y sal con Ctrl + x

4-. Configuracion de systemd

Una vez terminada la configuración reiniciamos el servidor con:

sudo systemctl restart minidlna.service

Ahora comprueba el estado del servidor con:

  sudo systemctl status minidlna.service
● minidlna.service - MiniDLNA lightweight DLNA/UPnP-AV server
     Loaded: loaded (/lib/systemd/system/minidlna.service; enabled; preset: enabled)
     Active: active (running) since Thu 2025-01-02 23:13:35 CET; 22h ago
       Docs: man:minidlnad(1)
             man:minidlna.conf(5)
   Main PID: 2630 (minidlnad)
      Tasks: 2 (limit: 9573)
        CPU: 2.230s
     CGroup: /system.slice/minidlna.service
             └─2630 /usr/sbin/minidlnad -f /etc/minidlna.conf -P /run/minidlna/minidlna.pid -S -r

Fíjate en la línea que dice «Loaded» ahí está la ruta de configuración de nuestro servicio y es la que vamos a modificar.

Escribe en consola lo siguiente:

sudo nano /lib/systemd/system/minidlna.service

Esto nos muestra el archivo de configuración, en el que solo vamos a añadir y cambiar un par de cosas de la sección de [Service].

Añadimos la línea ProtectHome=read-only y cambiamos el usuario y el grupo por Pantuflo

[Unit]
Description=MiniDLNA lightweight DLNA/UPnP-AV server
Documentation=man:minidlnad(1) man:minidlna.conf(5)
After=local-fs.target remote-fs.target autofs.service

[Service]
ProtectHome=read-only
User=Pantuflo
Group=Pantuflo

Environment=CONFIGFILE=/etc/minidlna.conf
Environment=DAEMON_OPTS=-r
EnvironmentFile=-/etc/default/minidlna

RuntimeDirectory=minidlna
LogsDirectory=minidlna
PIDFile=/run/minidlna/minidlna.pid
ExecStart=/usr/sbin/minidlnad -f $CONFIGFILE -P /run/minidlna/minidlna.pid -S $DAEMON_OPTS

[Install]
WantedBy=multi-user.target

Guarda con Ctrl + o y salimos con Ctrl + x

Recargamos systemd con:

sudo systemctl daemon-reload

y reiniciamos el servicio minidlna

sudo systemctl restart minidlna.service

Y con todo esto, debemos de tener todo terminado.

5-. Funcionamiento.

Para saber si nuestro servidor está funcionando bien, tecleamos en nuestro navegador lo siguiente:

http://localhost:8200/

Nos ofrece información sobre el número de audios, videos e imágenes compartidas, así como los dispositivos que hay conectados a nuestro servidor.

Busca tus archivos.

Ahora tan solo debes de ir a la aplicación de tu SmartTV, Smartphone o PC para encontrar el contenido multimedia de tu servidor.

Por ejemplo para encontrar los archivos multimedia de tu servidor con el reproductor VLC.

Abre tu reproductor VLC ve al menú Ver, Lista de Reproducción y el menú de la izquierda busca Plug’n Play Universal y haz click. Sobre el lado derecho aparecerán los servidores Ready Media que tengas configurados.

Ahora entra en el que te aparece a ti, y busca las carpetas con el contenido multimedia.

SSH, (Secure Shell), es un protocolo de administración remota por el cual los usuarios pueden controlar sus equipos a través de Internet.

Se creó para sustituir a Telnet, un protocolo no cifrado que no ofrecía ningún tipo de seguridad a los usuarios. En cambio, SSH hace uso de las técnicas de criptografía más innovadoras con el claro objetivo de que todas las comunicaciones realizadas entre los usuarios y los servidores remotos sean seguras. Dispone de una herramienta que permite autenticar al usuario remoto para posteriormente transferir las entradas desde el cliente al host y, finalmente, realizar la salida de vuelta a los usuarios.

Instalación del servidor y del cliente

Generalmente SSH suele venir preinstalado en tu distribución Linux, pero si no es así, procede a la instalación de los paquetes correspondientes, que son el servidor (openssh-server) y el cliente (openssh-client).

sudo apt-get install openssh-server openssh-client -y

El paquete openssh-server proporciona el demonio sshd y sftp-server que permite a los clientes ssh y scp establecer conexiones seguras, y a los clientes sftp transferir archivos, también de forma segura.

El paquete openssh-client proporciona los clientes de ssh, scp y sftp, los programas ssh-agent y ssh-add para hacer más cómoda la identificación de clave pública, y las utilidades ssh-keygen, ssh-keyscan, ssh-copy-id y ssh-argv0.

Test SSH

Comprueba que el servidor SSH está habilitado y activo con la siguiente orden:

sudo systemctl status sshd

En la siguiente imagen, resaltado en color verde vemos que es así.

Hay otros comandos como son:

sudo systemctl enable sshd = Habilita el servicio

sudo systemctl disable sshd = Deshabilita el servicio

sudo systemctl start sshd = Inicia el servicio

sudo systemctl stop sshd = Para el servicio

sudo systemctl restart sshd = reinicia el servicio

sudo systemctl reload sshd = recarga el servicio

Nota: La diferencia entre restart y reload es que, en el primer caso, el servicio se detiene y se vuelve a iniciar y en el segundo caso, sigue ejecutándose y vuelve a leer los archivos de configuración.

Archivos de configuración:

SSH dispone de varios archivos de configuración, que son los siguientes:

/etc/ssh/sshd_config: Archivo principal de configuración del servidor SSH.

/etc/ssh/ssh_config: Archivo principal de configuración de los clientes SSH.

~/.ssh/config: Archivo personal de cada usuario. Contiene la configuración utilizada por los clientes SSH. Permite al usuario local utilizar una configuración distinta a la definida en el archivo /etc/ssh/ssh_config.

~/.ssh/known_hosts: Archivo personal de cada usuario. Contiene las firmas digitales de los servidores SSH a los que se conectan los clientes. Cuando éstas firmas cambian, se pueden actualizar ejecutando el comando ssh-keygen -R, pasando el nombre del anfitrión o la IP del anfitrión como argumento. Este comando elimina la entrada correspondiente en el archivo ~/.ssh/known_hosts y, permite añadir de nuevo al anfitrión con una nueva firma digital. La sintaxis genérica sería:

ssh-keygen -R nombre_o_ip_del_servidor_SSH

~/.ssh/authorized_keys: Archivo personal para cada usuario. Contiene los certificados de los clientes SSH, para permitir autenticación hacia servidores SSH sin requerir contraseña.

Configurar SSH

Tras la instalación procederemos a la configuración del servidor, para ello, editaremos el fichero de configuración /etc/ssh/sshd_config.

NOTA: es importante hacer copia de seguridad del archivo /etc/ssh/sshd_config antes de realizar cualquier cambio.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Abrimos el archivo de confirmación con nano

sudo nano /etc/ssh/sshd_config

Una forma de elevar la seguridad del servidor SSH, consiste en cambiar el número de puerto predeterminado por otro que sólo el administrador del sistema conozca. Aunque cambiar de puerto disminuye considerablemente la posibilidad de una intrusión, en internet hay cientos de robots escaneando IPs y sus respectivos puertos abiertos, con lo que al final acabas siendo encontrado.

Port – De forma predeterminada, el servicio SSH escucha por el puerto 22. Los atacantes buscarán servidores que estén escuchando dicho puerto.Sustituye el 22 a otro puerto, preferiblemente entre el 1024 y 65535.

Veamos algunas otras opciones interesantes a tener en cuenta a la hora de configurar el servidor:

AddressFamily -Especifica qué familia de direcciones debe utilizar sshd. Los argumentos válidos son any (por defecto), inet (sólo IPv4), o inet6 (sólo IPv6).

ListenAddress – De forma predeterminada, el servicio SSH escuchará peticiones a través de todas las direcciones IP correspondientes a todas las interfaces de red del sistema. La directriz por defecto sería: ListenAddress 0.0.0.0. Si queremos que el servidor solo escuche por la interfaz de red con IP 192.168.1.30, a la cual sólo se puede acceder desde la red local:

ListenAddress 192.168.1.30

LoginGraceTime – Establece el tiempo, en segundos, durante el cual la pantalla de login estará disponible para que el usuario introduzca su nombre de usuario y contraseña, si no lo hace durante ese período de tiempo el login se cerrará, evitando así dejar por tiempo indeterminado pantallas de login sin que nadie las use, o que alguien este intentando mediante un script adivinar un usuario y su contraseña. Si el valor es 0, no hay límite de tiempo para que un usuario se autentique, lo cual no es recomendable ya que de esta forma un atacante podría utilizar ataques de fuerza bruta o usando métodos de diccionario para adivinar la contraseña, por lo tanto no es recomendable dejar esta directriz a 0. Lo podemos dejar en 10 segundos.

LoginGraceTime 10

PermitRootLogin – Probablemente sea la directriz de seguridad más importante que podemos establecer para asegurar nuestro servidor SSH. En los sistemas Unix y Linux se crea por defecto al usuario root, lo que implica que ya conocemos la existencia de al menos un usuario, ¡y que usuario!, con privilegios de adnimistrador. Muchos ataques de fuerza bruta se concentran en atacar al usuario root con la esperanza de que tenga una contraseña débil.
Sabiendo una parte de la ecuación (root) solo será cuestión de tiempo para que alguien con paciencia y suerte vulnere el sistema. En esta directriz denegamos el acceso al usuario root y por lo tanto, cualquier intento de ataque directo al usuario root será inútil.
Al denegar el acceso al usuario root, cada vez que necesitemos realizar tareas administrativas, accederemos como un usuario normal y una vez dentro, utilizando alguno de los comandos su o sudo podremos realizar dichas tareas administrativas. Por lo tanto, denegando el acceso al usuario root, el atacante tendrá que acertar tanto el nombre de un usuario del sistema como su contraseña, algo que disminuye notablemente la probabilidad de una intrusión.

StrictModes – En esta directriz se establece que sshd revisara los modos y permisos de los archivos de los usuarios y el directorio $HOME de el usuario antes de aceptar la sesión. Esto es normalmente deseable porque a veces algunos usuarios dejan sus directorios, accidentalmente, con permiso de escritura para cualquiera. El valor predeterminado es yes, por lo tanto, lo dejaremos con su valor predeterminado.

StrictModes yes

MaxAuthTries – El valor de esta directriz establece el máximo número de intentos de autenticación permitidos por conexión, es decir, la cantidad de veces que podemos equivocarnos al ingresar el usuario y/o contraseña. Una vez que los intentos alcanzan la mitad de este valor, las conexiones fallidas siguientes serán registradas. Después del máximo número de intentos se cerrará la conexión. Es posible volver a intentarlo, pero el límite de intentos por vez evita ataques basados en la persistencia de la conexión.

MaxAuthTries 5

MaxSessions – Especifica el número máximo de sesiones abiertas de shell, inicio de sesión o subsistema (por ejemplo, sftp) permitidas por conexión de red. Los clientes que soportan la multiplexación de conexiones pueden establecer múltiples sesiones. Si se establece MaxSessions a 1, se desactivará la multiplexación de sesiones, mientras que si se establece a 0, se evitarán todas las sesiones de shell, login y subsistema, a la vez que se permite el for- warding. El valor predeterminado es 10.

MaxSessions 10

Con todo esto que hemos aprendido ya puedes entrar a tu sistema remoto de la siguiente forma:

ssh -p 22343 tu_usuario@host_o_IP

Si te interesa saber mas de como proteger tu servidor, puedes ver «Instalar Fail2ban en Debian 12 y que funcione«

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.