Cómo proteger WordPress con Fail2Ban

English version: How to protect WordPress with Fail2Ban

Juntos, WP Cerber y Fail2Ban pueden detener los ataques de fuerza bruta antes de que lleguen a tu sitio WordPress. WP Cerber detecta los intentos de inicio de sesión fallidos a nivel de aplicación; Fail2Ban actúa sobre ellos a nivel del sistema operativo, bloqueando a los atacantes con iptables . Esta combinación detiene los ataques de fuerza bruta y DoS con una sobrecarga mínima.

¿Qué es Fail2Ban?

Fail2Ban es un servicio de monitorización de registros que se ejecuta en tu servidor. Revisa los archivos de registro en busca de patrones que indiquen un ataque, como fallos de autenticación repetidos desde la misma dirección, y cuando un host supera un umbral que tú configuras, bloquea esa dirección en el firewall del sistema durante un periodo determinado. Por sí solo, no tiene conocimiento de WordPress; actúa únicamente en función de lo que encuentra en los registros. Aquí es donde entra en juego WP Cerber: monitoriza y registra los intentos de inicio de sesión fallidos en un formato que Fail2Ban puede interpretar, proporcionando al servicio los eventos necesarios para actuar.

Lee más sobre ataques: Ataques de fuerza bruta, DoS y DDoS: ¿cuál es la diferencia?

Nota: necesitarás acceso de administrador (root) a tu servidor Linux para configurar Fail2Ban.

Con WP Cerber tienes tres opciones para usar Fail2Ban.

1. Utilice los encabezados de respuesta HTTP 403 si desea monitorear el registro de acceso de Apache.
2. Uso de archivos syslog para monitorear los intentos de inicio de sesión fallidos
3. Utilizar un archivo de registro personalizado para supervisar los intentos de inicio de sesión fallidos.

Supervise el registro de acceso de Apache para detectar respuestas HTTP 403.

Cuando falla un intento de inicio de sesión, WP Cerber devuelve un código de estado 403 en el encabezado HTTP. Apache registra esta respuesta en su registro de acceso, donde Fail2Ban puede leerla. Este comportamiento está habilitado por defecto. La desventaja es que Fail2Ban tiene que analizar todo el archivo access.log para encontrar esos intentos, lo cual resulta ineficiente en un sitio con mucho tráfico.

Uso de syslog para monitorear los intentos de inicio de sesión fallidos

Por defecto, WP Cerber registra los intentos fallidos en syslog mediante la función LOG_AUTH . Para usar una función propia, defina la constante CERBER_LOG_FACILITY con un valor entero. En cualquier caso, la escritura en syslog o en un archivo personalizado (véase más abajo) solo se produce una vez que active la opción «Escribir los intentos de inicio de sesión fallidos en un archivo de registro» en la configuración principal del plugin.

 define('CERBER_LOG_FACILITY', LOG_AUTHPRIV);

Utilizar un archivo personalizado para supervisar los intentos de inicio de sesión fallidos.

Para enviar cada intento fallido a un archivo de registro de su elección, configure su ruta absoluta con la constante CERBER_FAIL_LOG . No olvide otorgar a su servidor web permisos de escritura en la carpeta o archivo, y habilitar la opción "Escribir inicios de sesión fallidos en un archivo de registro" . WP Cerber crea el archivo de registro si no existe. Una vez definido CERBER_FAIL_LOG , WP Cerber deja de escribir en el syslog predeterminado. Cabe destacar que un archivo CERBER_FAIL_LOG personalizado mantiene los datos bajo su control, a diferencia del syslog, donde el almacenamiento sigue las políticas del servidor o del entorno de alojamiento.

 define('CERBER_FAIL_LOG','/var/log/wp-cerber-auth.log');

Asegúrese de que el proceso PHP de su servidor web tenga permisos de escritura para el archivo especificado.

Sincronizar las marcas de tiempo con el reloj del servidor.

La discrepancia en la zona horaria suele ser el motivo por el que Fail2Ban registra los intentos pero nunca bloquea a nadie, por lo que conviene entenderlo incluso cuando todo lo demás está configurado correctamente.

Fail2Ban solo actúa sobre los eventos que se encuentran dentro de su ventana findtime , y lo determina comparando la marca de tiempo de cada línea del registro con la hora local del servidor. WordPress mantiene su propio reloj en UTC, independientemente de la zona horaria configurada en el sitio. Por lo tanto, en un servidor con, por ejemplo, la zona horaria Europa/Madrid, cada línea que escribe WordPress parece tener una o dos horas de antigüedad. Fail2Ban descarta esos eventos por obsoletos y nunca aplica un bloqueo, aunque los intentos queden registrados.

WP Cerber evita este problema escribiendo sus marcas de tiempo en la zona horaria del sistema de tu servidor en lugar de en el reloj de WordPress, de modo que coincidan con lo que Fail2Ban espera por defecto. En la mayoría de los servidores, esto es automático y no requiere ninguna acción por tu parte.

Cuando WP Cerber no pueda resolver la zona horaria del sistema por sí solo, configúrela usted mismo con la constante CERBER_LOG_TIMEZONE , utilizando cualquier identificador de zona horaria válido:

 define('CERBER_LOG_TIMEZONE', 'Europe/Madrid');

Este valor anula la detección automática, por lo que es la forma más fiable de determinar la zona horaria si observa que las marcas de tiempo varían. Funciona con cualquier identificador de la base de datos de zonas horarias estándar, por ejemplo, 'America/New_York' o 'Asia/Tokyo'. Esta constante está disponible a partir de la versión 9.7.4 de WP Cerber .

¿Qué se registra?

Este registro guarda datos personales, por lo que si su sitio web está sujeto a una normativa de privacidad como el RGPD, le afecta directamente. A continuación, le explicamos su contenido.

Cada intento de inicio de sesión fallido registra una línea con la dirección IP de origen, el nombre de usuario introducido, el nombre de host del servidor, el ID del proceso y la fecha y hora. Las contraseñas nunca se registran, de ninguna forma, ni se guarda ningún otro dato de la cuenta.

Dos de estos campos se consideran datos personales según el RGPD: la dirección IP (la sentencia Breyer estableció que una IP cuenta como tal) y el nombre de usuario. Dado que WordPress permite iniciar sesión con correo electrónico, el nombre de usuario también puede ser la dirección de correo electrónico del usuario . Esto se aplica incluso a los intentos fallidos, que registran que se intentó contactar con una persona específica.

Esto te convierte en el responsable del tratamiento de estos datos, con algunas consecuencias prácticas. Incluye estos registros en tu política de retención y rótalos o elimínalos en lugar de dejar que crezcan sin límite. Controla dónde se almacenan y se reenvían los registros: un archivo CERBER_FAIL_LOG personalizado mantiene los datos bajo tu control, mientras que syslog puede enviarlos a servidores centralizados o externos donde el almacenamiento y el procesamiento siguen políticas del sistema que quizás no hayas configurado. Las solicitudes de acceso o eliminación de datos por parte de los interesados también se aplican a estos registros.

WP Cerber no admite la eliminación automática de estos registros porque no puede controlar qué hace syslog con ellos ni cómo el sistema operativo del servidor procesa los archivos de registro. Una función de limpieza integrada en WP Cerber solo cubriría una parte del problema y podría indicar erróneamente que los datos se eliminaron cuando no fue así.

Este es un resumen práctico, no asesoramiento legal. Si maneja datos de la UE, el Reino Unido o jurisdicciones similares, trate la dirección IP y el nombre de usuario como datos personales y consulte sus obligaciones con la entidad encargada del cumplimiento normativo en su empresa.