Toute installation WHMCS exposée publiquement est assaillie par des tentatives de connexion par force brute quelques heures après sa mise en ligne. Fail2ban surveille vos journaux, détecte les échecs répétés et bloque automatiquement les adresses IP incriminées. Ce guide explique comment le configurer pour WHMCS (et la pile SSH + web associée) sur Ubuntu.

Prérequis

  • Ubuntu 22.04 avec accès root
  • WHMCS fonctionnant derrière nginx ou Apache
  • Journalisation des activités WHMCS activée (elle l'est par défaut)

Étape 1 — Installer Fail2ban

apt update
apt install -y fail2ban
systemctl enable fail2ban

Étape 2 — Créer une configuration de jail locale

Ne modifiez jamais jail.conf directement (les mises à jour l'écraseraient). Créez /etc/fail2ban/jail.local :

[DEFAULT]
# Bannir pendant 1 heure après 5 échecs en 10 minutes
bantime  = 3600
findtime = 600
maxretry = 5
# Ignorer vos propres adresses IP (bureau, domicile, surveillance)
ignoreip = 127.0.0.1/8 ::1 YOUR.OFFICE.IP

[sshd]
enabled = true
port    = 2222

Ajustez port à votre véritable port SSH et ajoutez vos adresses IP statiques à ignoreip afin de ne jamais vous bloquer vous-même.

Étape 3 — Activer les bannissements progressifs pour les récidivistes

La jail recidive bannit les adresses IP qui reviennent après l'expiration de leur premier bannissement — pour une durée bien plus longue :

[recidive]
enabled  = true
logpath  = /var/log/fail2ban.log
banaction = iptables-allports
bantime  = 604800   ; 1 semaine
findtime = 86400    ; 1 jour
maxretry = 3

Étape 4 — Créer un filtre WHMCS

WHMCS enregistre les échecs de connexion administrateur dans sa base de données, mais il écrit également dans le journal du serveur web lors de tentatives répétées. L'approche la plus propre consiste à utiliser un filtre sur le propre journal des échecs de connexion de WHMCS. Tout d'abord, configurez WHMCS pour qu'il pointe vers un fichier journal — ou analysez le journal d'accès web pour le point d'accès de connexion.

Créez /etc/fail2ban/filter.d/whmcs.conf :

[Definition]
# Correspond aux POSTs de connexion admin/client échoués retournant à la page de connexion
failregex = ^<HOST> .* "POST /(dologin|admin/login)\.php.* 200
            ^<HOST> .* "POST /index\.php\?rp=/login.* 200
ignoreregex =

Ceci est un modèle de départ — ajustez failregex à la structure d'URL et au modèle de votre WHMCS. L'essentiel est de faire correspondre le POST de connexion depuis l'adresse IP du client.

Étape 5 — Ajouter la jail WHMCS

Ajoutez à la fin de /etc/fail2ban/jail.local :

[whmcs]
enabled  = true
port     = http,https
filter   = whmcs
logpath  = /var/log/nginx/access.log
maxretry = 5
findtime = 600
bantime  = 7200

Faites pointer logpath vers votre journal d'accès nginx/Apache réel pour le vhost WHMCS.

Étape 6 — Attention au problème de l'IP réelle

Si WHMCS est derrière un CDN ou un proxy inverse, votre journal d'accès affiche l'IP du CDN, et non celle du visiteur — Fail2ban bannirait le CDN et mettrait votre site entier hors ligne.

Corrigez cela dans nginx en restaurant d'abord l'IP réelle. Pour SprintCDN ou Cloudflare, ajoutez leurs plages d'adresses à une configuration real-IP :

# /etc/nginx/snippets/realip.conf
set_real_ip_from 1.2.3.0/24;   # les plages d'adresses de votre CDN
real_ip_header X-Forwarded-For;
real_ip_recursive on;

Incluez-le dans votre bloc serveur et assurez-vous que le format de journal utilise $remote_addr (qui reflète maintenant le client réel). Ce n'est qu'alors que Fail2ban bannira la bonne IP.

Étape 7 — Démarrer et vérifier

systemctl restart fail2ban
fail2ban-client status

Vous devriez voir vos jails actives : sshd, recidive, whmcs. Vérifiez une jail spécifique :

fail2ban-client status sshd

Ceci affiche les adresses IP actuellement bannies et les totaux.

Étape 8 — Tester le fonctionnement

Depuis une IP jetable (un téléphone en données mobiles fonctionne), échouez délibérément la connexion SSH ou WHMCS 6 fois. Ensuite, sur le serveur :

fail2ban-client status sshd
# Devrait lister l'IP de test sous "Banned IP list"
iptables -L -n | grep <TEST_IP>

Débannissez-la une fois terminé :

fail2ban-client set sshd unbanip <TEST_IP>

Étape 9 — Recevoir des notifications de bannissement (facultatif)

Fail2ban peut vous envoyer un e-mail à chaque bannissement. Dans jail.local sous [DEFAULT] :

destemail = you@yourdomain.com
sender    = fail2ban@yourdomain.com
action    = %(action_mwl)s

action_mwl = bannissement + e-mail avec whois + lignes de journal, afin que vous ayez le contexte de l'attaquant.

Défense en couches

Fail2ban gère la couche application, mais les attaques volumétriques (quelqu'un lançant 50 Gbit/s sur votre page de connexion) nécessitent une défense au niveau du réseau. Chez Hostfory, le DDoS scrubbing absorbe la couche volumétrique avant qu'elle n'atteigne votre serveur, et Fail2ban nettoie les attaques par force brute intelligentes et à faible volume qui passent à travers. Utilisez les deux.

Dépannage

Fail2ban ne bannit personne : votre failregex ne correspond pas aux lignes de journal. Testez-le : fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/whmcs.conf. Il indique le nombre de lignes correspondantes.

Fail2ban a banni mon CDN / toute ma base d'utilisateurs : le problème de l'IP réelle de l'Étape 6. Vous lisez l'IP du proxy. Corrigez la restauration de l'IP réelle avant de réactiver.

Vous vous êtes bloqué vous-même : si vous avez un accès console/IPMI (inclus sur tous les serveurs dédiés Hostfory), accédez par ce moyen et ajoutez votre IP à ignoreip. C'est pourquoi l'IPMI est important.

Prochaines étapes

Combinez cela avec un tunnel de gestion WireGuard afin que SSH ne soit même pas exposé publiquement, et restreignez le chemin d'administration WHMCS à l'IP de votre bureau au niveau de nginx. La défense en profondeur l'emporte sur tout contrôle unique.