Comment protéger WordPress avec Fail2Ban

English version: How to protect WordPress with Fail2Ban

Ensemble, WP Cerber et Fail2Ban peuvent bloquer les attaques par force brute avant même qu'elles n'atteignent votre installation WordPress. WP Cerber détecte les tentatives de connexion infructueuses au niveau de l'application ; Fail2Ban agit au niveau du système d'exploitation en bloquant les intrus grâce à iptables . Cette combinaison permet de stopper les attaques par force brute et les attaques par déni de service (DoS) avec une surcharge minimale.

Qu'est-ce que Fail2Ban ?

Fail2Ban est un service de surveillance des journaux qui s'exécute sur votre serveur. Il analyse les fichiers journaux à la recherche de schémas indiquant une attaque, comme des échecs d'authentification répétés provenant de la même adresse. Dès qu'un hôte dépasse un seuil que vous avez défini, il bloque cette adresse au niveau du pare-feu système pour une durée déterminée. Fail2Ban est totalement indépendant de WordPress ; il agit uniquement en fonction des informations contenues dans les journaux. C'est là qu'intervient WP Cerber : il surveille et enregistre les échecs de connexion dans un format compatible avec Fail2Ban, fournissant ainsi au service les événements nécessaires à son action.

Pour en savoir plus sur les attaques : Attaques par force brute, DoS et DDoS – quelle est la différence ?

Remarque : vous aurez besoin d'un accès root à votre serveur Linux pour configurer Fail2Ban.

Avec WP Cerber, vous avez trois options pour utiliser Fail2Ban.

1. Utilisez les en-têtes de réponse HTTP 403 si vous souhaitez surveiller le journal d'accès Apache.
2. Utilisation des fichiers syslog pour surveiller les tentatives de connexion infructueuses
3. Utilisation d'un fichier journal personnalisé pour surveiller les tentatives de connexion infructueuses

Surveillez le journal d'accès Apache pour les réponses HTTP 403.

Lorsqu'une tentative de connexion échoue, WP Cerber renvoie un code d'état 403 dans l'en-tête HTTP. Apache enregistre cette réponse dans son journal d'accès, accessible à Fail2Ban. Ce comportement est activé par défaut. En contrepartie, Fail2Ban doit analyser l'intégralité du fichier access.log pour identifier ces tentatives, ce qui peut s'avérer inefficace sur un site à fort trafic.

Utilisation de syslog pour surveiller les tentatives de connexion infructueuses

Par défaut, WP Cerber enregistre les tentatives d'authentification infructueuses dans les journaux système (syslog) sous le protocole LOG_AUTH . Pour utiliser un autre protocole, définissez la constante CERBER_LOG_FACILITY avec une valeur entière. Dans tous les cas, l'écriture dans les journaux système ou dans un fichier personnalisé (voir ci-dessous) n'est effectuée qu'après avoir activé l'option « Enregistrer les échecs de connexion dans un fichier journal » dans les paramètres principaux de l'extension.

 définir('CERBER_LOG_FACILITY', LOG_AUTHPRIV);

Utilisation d'un fichier personnalisé pour surveiller les tentatives de connexion infructueuses

Pour consigner chaque tentative de connexion infructueuse dans un fichier journal de votre choix, définissez son chemin absolu avec la constante CERBER_FAIL_LOG . N'oubliez pas d'accorder à votre serveur web les droits d'écriture sur le dossier ou le fichier, et d'activer l'option « Enregistrer les échecs de connexion dans un fichier journal » . WP Cerber crée le fichier journal s'il n'existe pas. Une fois CERBER_FAIL_LOG défini, WP Cerber cesse d'écrire dans le journal système par défaut. Il est important de noter qu'un fichier CERBER_FAIL_LOG personnalisé vous permet de garder le contrôle de vos données, contrairement au journal système dont le stockage est soumis aux politiques de votre serveur ou de votre environnement d'hébergement.

 définir('CERBER_FAIL_LOG','/var/log/wp-cerber-auth.log');

Assurez-vous que le processus PHP de votre serveur web dispose des droits d'écriture sur le fichier spécifié.

Alignement des horodatages avec l'horloge du serveur

Un décalage horaire est la raison habituelle pour laquelle Fail2Ban enregistre les tentatives mais ne bannit jamais personne ; il est donc important de comprendre ce problème même lorsque tout le reste est correctement configuré.

Fail2Ban n'agit que sur les événements survenant dans sa fenêtre findtime . Pour ce faire, il compare l'horodatage de chaque ligne de journal avec l'heure locale de votre serveur. WordPress utilise l'heure UTC, indépendamment du fuseau horaire défini sur le site. Ainsi, sur un serveur configuré par exemple sur Europe/Madrid, chaque ligne écrite par WordPress semble dater d'une ou deux heures. Fail2Ban ignore ces événements comme obsolètes et n'applique jamais de bannissement, même si les tentatives sont enregistrées dans le journal.

WP Cerber contourne ce problème en enregistrant ses horodatages dans le fuseau horaire de votre serveur plutôt que dans celui de WordPress, afin qu'ils correspondent aux attentes de Fail2Ban. Sur la plupart des serveurs, cette opération est automatique et ne nécessite aucune intervention de votre part.

Lorsque WP Cerber ne parvient pas à résoudre automatiquement le fuseau horaire du système, définissez-le vous-même à l'aide de la constante CERBER_LOG_TIMEZONE , en utilisant un identifiant de fuseau horaire valide :

 définir('CERBER_LOG_TIMEZONE', 'Europe/Madrid');

Cette valeur remplace la détection automatique ; c’est donc la méthode fiable pour déterminer le fuseau horaire si vous constatez des variations dans les horodatages. Tout identifiant de la base de données standard des fuseaux horaires convient, par exemple « America/New_York » ou « Asia/Tokyo ». Cette constante est disponible à partir de la version 9.7.4 de WP Cerber .

Qu'est-ce qui est enregistré ?

Ce journal enregistre des données personnelles ; par conséquent, si votre site est soumis à une réglementation sur la protection des données comme le RGPD, vous êtes directement concerné. Voici les informations qu'il contient.

Chaque tentative de connexion infructueuse génère une ligne : l’adresse IP source, le nom d’utilisateur saisi, le nom d’hôte du serveur, l’identifiant du processus et un horodatage. Les mots de passe ne sont jamais enregistrés, sous aucune forme, et aucune autre donnée de compte n’est conservée.

Deux de ces champs constituent des données personnelles au sens du RGPD : l’adresse IP (l’arrêt Breyer a établi qu’une adresse IP est considérée comme telle) et le nom d’utilisateur. WordPress autorisant la connexion par e-mail, le nom d’utilisateur peut également être une adresse e-mail . Ceci s’applique même aux tentatives infructueuses, qui permettent de constater qu’une personne a été ciblée.

Cela fait de vous le responsable du traitement de ces données, avec quelques conséquences pratiques. Intégrez ces journaux à votre politique de conservation et effectuez une rotation ou une suppression des données au lieu de les laisser s'accumuler indéfiniment. Suivez l'emplacement de stockage et de transmission des enregistrements : un fichier CERBER_FAIL_LOG personnalisé vous permet de garder le contrôle des données, tandis que syslog peut envoyer les enregistrements vers des serveurs centralisés ou externes où le stockage et le traitement sont soumis à des politiques système que vous n'avez peut-être pas définies. Les demandes d'accès ou d'effacement formulées par les personnes concernées s'appliquent également à ces journaux.

WP Cerber ne prend pas en charge la purge automatique de ces journaux, car il n'a aucun contrôle sur le traitement des enregistrements par syslog ni sur la manière dont le système d'exploitation du serveur gère les fichiers journaux. Une fonction de nettoyage intégrée à WP Cerber ne permettrait qu'une résolution partielle du problème et pourrait faussement laisser croire à la suppression des données.

Ce résumé est pratique et ne constitue pas un avis juridique. Si vous traitez des données provenant de l'UE, du Royaume-Uni ou de juridictions similaires, considérez l'adresse IP et le nom d'utilisateur comme des données personnelles et vérifiez vos obligations auprès de l'autorité de conformité de votre entreprise.