Le fail2ban intégré à mailcow fait bien une chose : il intercepte les attaques les plus bruyantes. Dix échecs de connexion en dix minutes valent un bannissement de trente minutes. Puis il les oublie.
Tout ce qui est plus discret passe. Une adresse qui tente un mot de passe toutes les quelques minutes, toute la journée. Un botnet qui répartit ses essais sur des centaines d’adresses pour qu’aucune ne franchisse le seuil. Un scanner qui parcourt votre webmail à la recherche de /.env ou wp-login.php. Une boîte dont le mot de passe a été deviné et qui envoie désormais du spam. Une bonne protection contre la force brute sur mailcow doit voir tout cela, s’en souvenir, et n’agir que lorsque vous le lui demandez.
C’est ce que fait Security pour mailcow. Il lit ce que mailcow journalise déjà, conserve l’historique dans la base de mailcow, applique 13 règles pour ce que fail2ban laisse passer et bannit via le netfilter de mailcow — conçu pour ne pas vous verrouiller. Ce tutoriel vous mène de l’installation à une configuration réglée et automatique.
Prérequis
Avant de commencer, vérifiez que vous disposez de :
- mailcow-dockerized sous Linux avec docker compose et systemd.
- mailcow Toolkit 0.6.0 ou plus récent — ce produit est l’un des modules de ce paquet, avec sa propre licence.
- Un accès root sur l’hôte pour lancer
install.sh. - Un accès HTTPS sortant depuis le serveur vers
medialab.workspour la vérification de licence. - Le conteneur netfilter de mailcow en cours d’exécution — c’est lui qui applique les bannissements. Si Manage external est activé dans les réglages fail2ban de mailcow, netfilter ne touche pas au pare-feu et c’est votre propre pare-feu qui doit appliquer la liste de mailcow.
- Facultatif : un jeton Cloudflare avec Account → Account Firewall Access Rules → Edit, et un jeton de bot Telegram si vous voulez des alertes Telegram.
Étape 1 — Installer le Toolkit et ouvrir Système > Sécurité
Sur l’hôte mailcow, en root, lancez l’installateur du Toolkit comme d’habitude :
sudo ./install.sh --mailcow-dir /opt/mailcow-dockerized --name <instance>
Si vous utilisez déjà le Toolkit, mettez-le à jour depuis Système > Mises à jour (Toolkit).
L’installateur copie data/web/mlw-security/, crée les tables du module dans la base de mailcow, ajoute l’entrée de menu et le minuteur mlw-mailcow-security-<instance>.timer qui s’exécute chaque minute, puis recharge php-fpm. Ouvrez ensuite Système > Sécurité dans le menu d’administration de mailcow.
Étape 2 — Activer la licence
Ouvrez Système > Mises à jour (Toolkit) et trouvez la carte Security pour mailcow : collez la clé et activez-la, ou démarrez l’essai de 30 jours. En shell, dans php-fpm-mailcow :
php /web/mlw-toolkit/cli.php activate mailcow-security <KEY>
Sans licence valide, rien n’est lu, détecté, banni ni envoyé — mais les bannissements existants sont tout de même levés à leur expiration, et rien n’est supprimé. Les détails figurent dans le guide utilisateur.
Étape 3 — Comprendre ce qui est lu
La première exécution importe ce que mailcow conserve encore dans ses journaux (en général les dernières heures) et ne bannit ni n’alerte. Ensuite, la tâche ne lit que les nouvelles lignes, chaque minute, depuis les sources que mailcow écrit déjà :
- dovecot — échecs de connexion IMAP / POP3 / ManageSieve avec comptage des tentatives, connexions qui ne s’authentifient jamais, connexions réussies.
- postfix — échecs d’AUTH SMTP, envois authentifiés, rejets rspamd et listes de blocage DNS, tentatives de relais, sondes de protocole.
- SOGo — échecs et réussites de connexion au webmail.
- fail2ban — chaque bannissement effectué par le fail2ban de mailcow.
- serveur web — réponses 4xx, y compris les chemins d’exploit connus et les autres 404.
- php-fpm — échecs de connexion à l’interface et à l’API de mailcow.
Les enregistrements d’adresses privées (les conteneurs de mailcow, un reverse proxy devant mailcow) et des réseaux que vous ignorez sont écartés. L’historique est conservé 90 jours par défaut. Si Vue d’ensemble > État signale des lignes perdues, mailcow a tronqué ses journaux avant leur lecture — augmentez LOG_LINES dans mailcow.conf.
Étape 4 — Lire l’historique des attaques
Rendez-vous dans Vue d’ensemble. Vous y trouvez les totaux des dernières 24 heures par type, un graphique sur 14 jours des échecs de connexion, scans et spams par jour, les adresses les plus actives avec un bouton Bannir, les boîtes ciblées et les incidents actifs. Un bouclier rouge à côté du menu Système signale les incidents graves ouverts sur chaque page d’administration, pour que vous les remarquiez sans les chercher.
Prenez quelques minutes ici avant de changer quoi que ce soit. Cela vous dit si votre serveur voit surtout du bruit de fond ou une véritable campagne.
Étape 5 — Passer en revue les 13 règles
Chaque règle compte des enregistrements dans une fenêtre glissante et ouvre un incident lorsque le seuil est atteint. Tant que l’attaque continue, le même incident est prolongé, pas répété. Les valeurs par défaut :
| Règle | Compte | Défaut |
|---|---|---|
| Force brute sur les connexions web | échecs de connexion SOGo / interface / API par adresse | 5 en 15 min → bannissement 24 h |
| Force brute lente | échecs de connexion par adresse sur une journée | 20 en 24 h → bannissement 24 h |
| Password spraying | boîtes distinctes sur lesquelles une adresse a échoué | 5 en 60 min → bannissement 7 jours |
| Récidiviste | bannissements fail2ban de mailcow pour une adresse | 3 en 7 jours → bannissement 30 jours |
| Scan d’exploits web | requêtes vers des chemins d’exploit / fuite | 3 en 30 min → bannissement 7 jours |
| Scan de 404 | réponses 404 par adresse | 40 en 30 min → alerte |
| Tentatives de relais | « Relay access denied » par adresse | 3 en 60 min → bannissement 7 jours |
| Scan de protocole | connexions qui ne s’authentifient jamais ou cassent le protocole | 30 en 60 min → alerte |
| Vague de spam | rejets rspamd et listes de blocage par adresse | 20 en 60 min → alerte |
| Boîte ciblée | échecs sur une boîte depuis au moins 5 adresses | 30 en 60 min → alerte |
| Pic d’envoi | messages envoyés par une boîte | 300 en 60 min → alerte |
| Connexions depuis de nombreuses adresses | adresses distinctes depuis lesquelles une boîte se connecte | 8 en 60 min → alerte |
| Connexion après échecs | première connexion depuis une adresse qui avait échoué sur la boîte | 3 échecs en 24 h → alerte (critique) |
Dans Règles, vous pouvez désactiver chaque règle et modifier son seuil, sa fenêtre, son action et la durée de bannissement (0 = permanent). Les règles sur les adresses peuvent alerter ou bannir ; les règles sur les boîtes peuvent alerter, limiter l’envoi ou interdire la connexion. Réinitialiser les valeurs par défaut les rétablit toutes.
Les quatre dernières lignes constituent votre détection des boîtes compromises : un pic d’envoi, des connexions depuis de nombreuses adresses, des échecs répartis sur de nombreuses adresses pour une même boîte et — la plus fine — une connexion depuis une adresse qui avait échoué sur cette boîte auparavant. C’est un mot de passe probablement deviné.
Étape 6 — Observer d’abord en surveillance seule
L’interrupteur en haut de Règles est désactivé au départ. Chaque incident indique ce qui aurait été fait (« aurait banni »). Laissez-le ainsi quelques jours, examinez les incidents, ajustez les seuils, puis activez-le. Les incidents dont l’attaque est toujours en cours sont traités à l’exécution suivante.
Lorsque vous examinez des incidents, utilisez Faux positif le cas échéant : l’adresse est placée sur la liste d’exceptions et ses bannissements sont levés.
Étape 7 — Activer les actions automatiques
Avec les actions automatiques activées, un bannissement va dans la liste noire fail2ban de mailcow pour la durée de la règle. Le netfilter de mailcow l’applique sur chaque port de mailcow en moins d’une minute, et vous le voyez sur la page Fail2ban de mailcow. Le module le lève à l’expiration ; un bannissement que vous supprimez sur la page Fail2ban de mailcow compte comme levé.
Jamais bannis automatiquement :
- les adresses privées et réservées ;
- la liste d’exceptions du module (Paramètres) et celle de fail2ban de mailcow (Configuration > Fail2ban) ;
- les adresses publiques du serveur lui-même ;
- avec protéger les adresses connues activé (par défaut), les adresses qui se sont connectées avec succès à une boîte au cours des 30 derniers jours — pour qu’un collègue qui se trompe de mot de passe ne soit pas bloqué.
Étape 8 — Agir sur les comptes via mailcow lui-même
Pour une boîte qui semble compromise, les actions sur le compte passent par les fonctions de mailcow : interdire la connexion (la boîte reçoit toujours du courrier), terminer les sessions IMAP / POP3, exiger un changement de mot de passe, limiter l’envoi. Vous pouvez le faire depuis la vue d’une adresse ou d’une boîte, qui affiche d’un coup d’œil les échecs, connexions, envois, incidents et bannissements. Chaque action — la vôtre ou celle du module — est consignée dans le journal d’audit.
Étape 9 — Bannissements manuels et Cloudflare
Bannissements affiche les bannissements du module (motif, auteur, échéance, état Cloudflare), les bannissements temporaires fail2ban de mailcow avec Lever ou Prolonger, et le reste de la liste noire de mailcow. Le formulaire en haut bannit une adresse ou un réseau (CIDR) de 1 heure à 30 jours, ou de façon permanente ; votre propre adresse actuelle est refusée.
Si l’interface de mailcow et le webmail sont derrière le proxy Cloudflare, les attaques web atteignent mailcow depuis les adresses de Cloudflare et netfilter ne peut pas les arrêter. Dans Paramètres > Cloudflare, choisissez bannissements des règles web et bannissements manuels cochés ou tous les bannissements : chaque bannissement devient alors aussi une règle d’accès IP Cloudflare au niveau du compte, supprimée en même temps que le bannissement.
Étape 10 — Alertes
Réglez les alertes par e-mail et Telegram à partir de la gravité choisie, avec une limite horaire, et en option un résumé quotidien. Les alertes ne vont qu’à l’adresse et au chat que vous configurez. Tout le reste — journaux, adresses, noms de boîtes, historique — reste dans votre base de mailcow et n’est jamais envoyé à medialab.works.
Un autre point à connaître : lorsqu’une vulnérabilité grave touche PHP, nginx, SOGo ou un autre composant de mailcow, un correctif virtuel peut arriver avec la vérification de licence — une atténuation précise, appliquée automatiquement pour les critiques. Il réduit le risque en attendant la mise à jour ; il ne la remplace pas.
Conseils et dépannage
- Les bannissements n’apparaissent pas dans le pare-feu. Vérifiez que le conteneur netfilter de mailcow est en cours d’exécution. Si Manage external est activé, netfilter ne touche pas au pare-feu et c’est votre propre pare-feu qui doit appliquer la liste de mailcow — la page Bannissements vous en avertit.
- Vous vous êtes verrouillé. Votre adresse actuelle est refusée par le formulaire de bannissement manuel, et les adresses connues sont protégées par défaut. Si vous êtes tout de même bloqué, supprimez le bannissement sur la page Fail2ban de mailcow — il compte comme levé.
- Trop d’alertes. Augmentez les seuils ou les gravités par règle, ou appuyez-vous sur la limite horaire et le résumé quotidien.
- Les attaques web arrivent toujours. Si vous êtes derrière le proxy Cloudflare, configurez Cloudflare dans les Paramètres ; netfilter seul ne peut pas voir le vrai client.
- Des lignes ont été perdues. Augmentez
LOG_LINESdansmailcow.confsur un serveur très sollicité.
Conclusion
fail2ban reste la première ligne, et vous devez la conserver. Security pour mailcow est la seconde : un historique mémorisé, 13 règles pour les attaques lentes et distribuées, la détection des boîtes compromises et des bannissements qui passent par le pare-feu auquel mailcow fait déjà confiance. Commencez en surveillance seule, observez quelques jours, puis laissez-le agir. La page produit contient la liste des fonctionnalités, le guide couvre chaque écran et le journal des modifications suit ce qui a changé. Si quelque chose ne correspond pas à votre installation, la base de connaissances et la FAQ sont une bonne étape suivante, ou contactez-nous.