Courriel : Brute force sur IMAP/SMTP — sécurisez sans vous verrouiller

Savoir ce que vous combattez : brute force vs spraying vs credential stuffing

Brute force

Le brute force classique consiste en des tentatives répétées contre un compte (ou un petit ensemble) jusqu’à ce que ça passe. Sur IMAP/SMTP,
il cible souvent des noms d’utilisateur communs comme admin, info, sales, ainsi que des adresses réelles
récupérées sur votre site. Ces attaques sont bruyantes : beaucoup d’échecs, souvent depuis un petit nombre d’IP, parfois
depuis des botnets qui tournent sur des plages de VPS bon marché.

Password spraying

Le spraying est le cousin « subtil » : essayer un ou quelques mots de passe courants sur de nombreux comptes. Il évite les blocages
de compte et ressemble moins à une panne, plutôt à un fond ambiant — jusqu’à ce qu’il touche un mot de passe réutilisé et devienne votre incident.
Le spraying est particulièrement fréquent sur IMAP car il est largement exposé et la boucle de retour est rapide.

Credential stuffing

Le stuffing, c’est lorsque les attaquants utilisent des paires utilisateur/mot de passe compromises ailleurs. Le serveur mail est juste la destination ;
la fuite a eu lieu ailleurs. L’attaque a tendance à être plus efficace que le brute force. Les motifs dans les logs peuvent sembler
« valides » : une tentative par compte, parfois réussie, puis une activité immédiate depuis la boîte ou envoi via SMTP AUTH.

Pourquoi IMAP/SMTP sont des cibles si tentantes

Le courrier est encore la clé universelle en entreprise : réinitialisations de mots de passe, factures fournisseurs, documents RH, et conversations « virement maintenant »
y transitent. Une boîte compromise devient souvent un pivot interne et une plateforme de fraude, pas seulement un problème de confidentialité.
Aussi : beaucoup de piles mail sont anciennes, fortement personnalisées, et traitées comme des « appliances » jusqu’à ce qu’elles prennent feu.

Une règle pratique : ne considérez pas le « brute force sur IMAP/SMTP » comme un problème purement périmétrique. C’est un problème d’authentification, de supervision
et de gestion du changement. Vous pouvez bloquer mille IPs et quand même perdre à cause d’un mot de passe réutilisé.

Blague n°1 : Les attaquants adorent IMAP parce qu’il est toujours là — comme cette imprimante au service compta qui refuse de disparaître.

Quelques faits et contexte historique (parce que le mail ne meurt jamais)

• SMTP précède l’internet moderne. SMTP a été standardisé au début des années 1980 et supposait un réseau plus convivial. « Authentification hostile à grande échelle » n’était pas dans le cahier des charges.
• IMAP est plus ancien que la plupart des stratégies « cloud first ». IMAP est apparu aussi dans les années 1980, optimisé pour l’accès distant aux boîtes avant que les smartphones n’en fassent un souci mondial.
• Le port 25 n’était pas destiné aux connexions utilisateur. SMTP sur 25 sert le transport serveur-à-serveur ; la soumission authentifiée est passée sur 587 pour séparer les responsabilités et la politique.
• Les « applications moins sécurisées » ont créé une longue traîne d’authentification faible. Pendant des années, les clients se connectaient avec des mots de passe en clair pour récupérer le courrier ; le MFA moderne et les mots de passe d’application sont arrivés tard et de façon inégale.
• Le password spraying a augmenté avec les politiques de verrouillage. Dès que les entreprises ont commencé à verrouiller les comptes après N échecs, les attaquants se sont adaptés à des schémas « bas-et-lent » sur de nombreux utilisateurs.
• Les botnets ont rendu le brute force bon marché. Des tentatives distribuées depuis des milliers d’IP transforment le blocage par IP en un jeu de whack-a-mole à moins de limiter les taux et durcir l’authentification.
• Les logs mail sont exceptionnellement riches. Postfix/Dovecot peuvent vous dire qui a essayé, d’où et combien de fois — si vous conservez les logs assez longtemps et ne les noyez pas dans le bruit.
• Le « TLS partout » a aidé, mais pas contre le guessing. Chiffrer le canal empêche l’écoute ; cela ne sert à rien contre un attaquant qui possède déjà des listes de mots de passe.

Plaquette de diagnostic rapide (premières/deuxièmes/troisièmes vérifications)

Quand vous êtes sous attaque active, votre travail est de (1) maintenir le flux pour les utilisateurs légitimes, (2) arrêter l’hémorragie,
et (3) préserver suffisamment de preuves pour apprendre quelque chose. Voici l’ordre qui vous garde honnête.

Première étape : confirmer ce qui échoue et où

• Les utilisateurs échouent-ils à s’authentifier ou à se connecter ? Les échecs d’authentification ressemblent à auth failed ; les échecs de connexion ressemblent à des timeouts/refus.
• Est-ce IMAP, soumission (587), SMTPS (465) ou autre chose ? Ne « corrigez pas SMTP » si c’est IMAP, et ne bloquez pas 587 si vos utilisateurs en dépendent.
• La machine est-elle liée CPU, I/O ou table de connexions ? Sous brute force, vous pouvez saturer le CPU (TLS + auth), l’I/O (logs + backends d’auth) ou le conntrack réseau.

Deuxième étape : identifier le schéma d’attaque dominant

• Peu d’IPs qui frappent fort ? Les bans par IP et les limites au pare-feu fonctionnent bien.
• Beaucoup d’IPs, beaucoup d’utilisateurs, faible débit ? C’est du spraying/stuffing. Il vous faut un throttling par utilisateur, une authentification renforcée et de la détection d’anomalies.
• Y a-t-il des succès ? Si oui, vous êtes en situation de compromission : désactivez les comptes, réinitialisez les identifiants, vérifiez le mail sortant et passez en revue le MFA/mots de passe d’application.

Troisième étape : appliquer la mitigation minimale

• Activez ou resserrez les throttles existants (pénalités d’auth Dovecot, limites SASL Postfix, fail2ban) avant de déployer de nouveaux outils en pleine crise.
• Blanchissez votre voie d’administration (egress VPN, bastion, IP bureau) avant un blocage agressif. Vous voulez une porte contrôlée que vous pouvez encore ouvrir.
• Ne « redémarrez pas jusqu’à ce que ça marche ». Les redémarrages peuvent effacer les logs, faire tourner l’état d’iptables et vous donner une fausse impression de progrès pendant que l’attaque reprend immédiatement.

« L’espoir n’est pas une stratégie » est une formule courante en exploitation, mais l’idée paraphrasée tient : préparez les modes de défaillance avant qu’ils n’envahissent votre file de tickets.

Une citation à garder en tête : Idée paraphrasée : « Les systèmes échouent de façon complexe ; la fiabilité vient de la préparation et de l’apprentissage, pas de prétendre que les pannes n’arriveront pas. » — Richard Cook (idée paraphrasée)

Tâches pratiques : commandes, sorties et la décision que vous prenez

Ce ne sont pas des « incantations magiques ». Ce sont les exercices exacts que je veux voir dans un runbook : commande, sortie d’exemple,
ce que ça signifie, et ce que vous faites ensuite. Adaptez chemins et noms de services à votre distro, mais gardez la logique.

Tâche 1 : Confirmer quels ports sont exposés (et par quoi)

cr0x@server:~$ sudo ss -lntp | egrep ':(25|110|143|465|587|993|995)\s'
LISTEN 0      100          0.0.0.0:25       0.0.0.0:*    users:(("master",pid=1123,fd=13))
LISTEN 0      100          0.0.0.0:587      0.0.0.0:*    users:(("master",pid=1123,fd=15))
LISTEN 0      100          0.0.0.0:465      0.0.0.0:*    users:(("master",pid=1123,fd=16))
LISTEN 0      128          0.0.0.0:993      0.0.0.0:*    users:(("dovecot",pid=998,fd=41))
LISTEN 0      128          0.0.0.0:143      0.0.0.0:*    users:(("dovecot",pid=998,fd=40))

Ce que cela signifie : Des services écoutent sur les interfaces publiques pour SMTP (25), la soumission (587/465), et IMAP (143/993).

Décision : Si vous n’avez pas besoin d’IMAP en clair (143) sur Internet, cessez de l’exposer. Si 465 existe mais n’est pas utilisé, envisagez de le désactiver pour réduire la surface.

Tâche 2 : Vérifier la pression de connexions actuelle (êtes-vous inondé ?)

cr0x@server:~$ sudo ss -ant state established '( sport = :993 or sport = :587 )' | wc -l
842

Ce que cela signifie : 842 connexions établies sur IMAPS/soumission. Ça peut être normal pour une grande orga, ou catastrophique pour une petite.

Décision : Comparez avec la baseline. Si c’est 10× la normale, passez au découpage par IP attaquante et à la limitation de débit.

Tâche 3 : Trouver les IP sources dominantes frappant IMAPS en ce moment

cr0x@server:~$ sudo ss -ant '( dport = :993 )' | awk 'NR>1 {print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head
  210 203.0.113.77
  198 198.51.100.22
   95 192.0.2.14
   41 203.0.113.19

Ce que cela signifie : Quelques IPs dominent. C’est le mode facile pour bloquer.

Décision : Si ce ne sont pas vos egress NAT ou vos sondes de supervision connues, bloquez-les ou limitez-les au pare‑feu. Si ce sont « beaucoup d’IPs avec de petits comptes », passez aux contrôles par utilisateur.

Tâche 4 : Compter les échecs d’authentification des 10 dernières minutes (Dovecot)

cr0x@server:~$ sudo journalctl -u dovecot --since "10 min ago" | egrep -i 'auth failed|authentication failure' | wc -l
12458

Ce que cela signifie : C’est actif et intense. À ce rythme, vous allez griller CPU, logs et peut-être le backend d’auth.

Décision : Activez le throttling immédiatement (pénalités d’auth Dovecot) et vérifiez que fail2ban bannit effectivement.

Tâche 5 : Extraire les noms d’utilisateurs les plus attaqués (indice spraying vs brute force)

cr0x@server:~$ sudo journalctl -u dovecot --since "30 min ago" | egrep -o 'user=<[^>]+' | cut -d'<' -f2 | sort | uniq -c | sort -nr | head
  611 user=info@example.com
  588 user=admin@example.com
  512 user=support@example.com
  498 user=sales@example.com

Ce que cela signifie : Des comptes partagés affichent de forts volumes — indice de brute force. Si vous voyez des centaines d’utilisateurs différents avec de petits comptes, c’est du spraying.

Décision : Pour les boîtes partagées à haute valeur (info@, support@), imposez le MFA/mots de passe d’application ou désactivez l’accès IMAP si possible.

Tâche 6 : Confirmer que fail2ban tourne et a un jail Dovecot

cr0x@server:~$ sudo fail2ban-client status
Status
|- Number of jail:      3
`- Jail list:          dovecot, postfix-sasl, sshd

Ce que cela signifie : Vous avez des jails pertinents. Bien. Maintenant vérifiez s’ils sont efficaces.

Décision : S’il n’y a pas de dovecot ou postfix-sasl, vous comptez sur la chance et le volume de logs.

Tâche 7 : Vérifier combien d’IPs sont bannies et si les bans augmentent

cr0x@server:~$ sudo fail2ban-client status dovecot
Status for the jail: dovecot
|- Filter
|  |- Currently failed: 128
|  |- Total failed:     54122
|  `- File list:        /var/log/mail.log
`- Actions
   |- Currently banned: 317
   |- Total banned:     2901
   `- Banned IP list:   203.0.113.77 198.51.100.22 192.0.2.14

Ce que cela signifie : Des bans ont lieu. Le nombre « Currently failed » vous dit que le jail voit toujours des tentatives.

Décision : Si Currently banned est proche de zéro pendant une attaque évidente, votre regex de filtre est mauvaise, le chemin de log est faux, ou vous loggez uniquement dans journald.

Tâche 8 : Vérifier que vos logs mail sont bien écrits où vous pensez

cr0x@server:~$ sudo ls -lh /var/log/mail.log
-rw-r----- 1 syslog adm 1.8G Jan  4 01:11 /var/log/mail.log

Ce que cela signifie : Le fichier de log existe et est volumineux. Sous attaque, l’I/O des logs peut devenir un goulot.

Décision : Si le log explose et que vous êtes limité en I/O, envisagez une limitation temporaire des connexions et assurez-vous que logrotate est sain. Ne désactivez pas la journalisation en pleine crise sauf si vous n’avez vraiment plus d’espace disque.

Tâche 9 : Vérifier l’espace disque (parce que « mail down » peut être « disque plein » déguisé)

cr0x@server:~$ df -h /var /var/log
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       100G   96G  4.0G  97% /var
/dev/sda2       100G   96G  4.0G  97% /var/log

Ce que cela signifie : Il ne vous reste que 3% avant une panne auto-infligée. Sous brute force, les logs peuvent vous faire franchir la ligne.

Décision : Libérez de l’espace en toute sécurité (rotation/compression, archivage), puis réduisez l’amplification des logs en stoppant les tentatives répétées (throttles/bans).

Tâche 10 : Confirmer que Postfix voit des échecs SASL sur la soumission

cr0x@server:~$ sudo journalctl -u postfix --since "15 min ago" | egrep -i 'SASL.*authentication failed|warning: SASL' | head
Jan 04 01:02:11 mx1 postfix/smtpd[22103]: warning: unknown[203.0.113.77]: SASL LOGIN authentication failed: authentication failure
Jan 04 01:02:12 mx1 postfix/smtpd[22105]: warning: unknown[203.0.113.77]: SASL PLAIN authentication failed: authentication failure

Ce que cela signifie : L’attaque cible aussi SMTP AUTH. C’est courant : les attaquants testent IMAP et la soumission.

Décision : Assurez‑vous que le jail postfix-sasl de fail2ban matche ces lignes, et appliquez des limites de débit sur smtpd si nécessaire.

Tâche 11 : Inspecter les compteurs nftables/iptables pour les ports mail

cr0x@server:~$ sudo nft list ruleset | egrep -n 'dport (25|587|465|993|143)'
42: tcp dport { 25, 587, 465, 993 } ct state new accept

Ce que cela signifie : Vous acceptez les nouvelles connexions sans aucune limitation. Sous attaque, ça peut submerger processus et conntrack.

Décision : Ajoutez une limitation de débit pour les nouvelles connexions vers les ports AUTH IMAP/SMTP, avec des seuils et des listes blanches prudents.

Tâche 12 : Vérifier l’utilisation du conntrack (tueur silencieux lors de floods)

cr0x@server:~$ sudo sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
net.netfilter.nf_conntrack_count = 247812
net.netfilter.nf_conntrack_max = 262144

Ce que cela signifie : Vous êtes proche du max conntrack. Quand vous l’atteindrez, les connexions légitimes commenceront à échouer de façon étrange.

Décision : Limitez les nouvelles connexions, envisagez d’augmenter le max conntrack (en tenant compte de la mémoire), et coupez plus tôt les sources manifestement abusives.

Tâche 13 : Identifier si vous êtes lié CPU sur TLS/auth

cr0x@server:~$ top -b -n 1 | head -20
top - 01:04:33 up 21 days,  2:11,  1 user,  load average: 18.42, 17.90, 14.20
%Cpu(s): 86.5 us,  9.2 sy,  0.0 ni,  1.1 id,  0.0 wa,  0.0 hi,  3.2 si,  0.0 st
PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
998 dovecot   20   0  786972  41280  12624 R  215.0   0.5  52:10.11 dovecot/auth
1123 root     20   0  145772  12204   8560 S   85.0   0.1  31:02.24 master

Ce que cela signifie : L’auth Dovecot bouffe du CPU. Ça peut être la vérification de hash bcrypt/sha512-crypt sous attaque (attendu), ou une latence LDAP provoquant des retries (pire).

Décision : Ajoutez du throttling d’auth et vérifiez la santé du backend d’auth. Ne « réglez pas » les coûts de hash à la baisse ; c’est échanger la sécurité à long terme contre un calme temporaire.

Tâche 14 : Vérifier si votre backend d’auth (LDAP) est le vrai goulot

cr0x@server:~$ sudo journalctl -u dovecot --since "10 min ago" | egrep -i 'ldap|connect\(\) failed|timed out' | tail -5
Jan 04 01:00:17 mx1 dovecot: auth: Error: ldap(example.com): Connection timed out
Jan 04 01:00:21 mx1 dovecot: auth: Error: ldap(example.com): Unable to connect to server: Can't contact LDAP server

Ce que cela signifie : L’attaque est maintenant un DoS du backend d’auth. Même les connexions légitimes peuvent échouer parce que LDAP est saturé ou injoignable.

Décision : Mettez des throttles agressifs devant LDAP (politique d’auth Dovecot, fail2ban), et envisagez du caching ou de l’auth locale pour les comptes critiques.

Tâche 15 : Confirmer que vous n’autorisez pas accidentellement des connexions en clair

cr0x@server:~$ sudo dovecot -n | egrep -i 'disable_plaintext_auth|auth_mechanisms|ssl'
disable_plaintext_auth = yes
auth_mechanisms = plain login
ssl = required

Ce que cela signifie : TLS est requis, l’auth en clair est désactivée, mais vous autorisez encore PLAIN/LOGIN sur TLS (correct). Si ssl = yes et disable_plaintext_auth = no, vous avez un risque.

Décision : Maintenez l’obligation TLS. Si des clients anciens exigent le non‑TLS, corrigez les clients ; ne dégradez pas le serveur.

Tâche 16 : Vérifier les restrictions du service de soumission Postfix (prévenir l’abus après compromission)

cr0x@server:~$ sudo postconf -n | egrep -i 'smtpd_tls_auth_only|smtpd_recipient_restrictions|smtpd_client_message_rate_limit'
smtpd_tls_auth_only = yes
smtpd_recipient_restrictions = permit_sasl_authenticated,reject_unauth_destination
smtpd_client_message_rate_limit = 200

Ce que cela signifie : L’auth via TLS seulement est activée, le relais non authentifié est bloqué, et il existe une limite de messages par client.

Décision : S’il n’y a pas de limite d’envoi, un compte compromis peut envoyer beaucoup avant que vous ne remarquiez. Ajoutez des throttles raisonnables et alertez sur les pics.

Contrôles en couches qui fonctionnent en production

1) Réduire la surface exposée (sans casser les clients)

Chaque port ouvert est un contrat avec Internet. Gardez les contrats nécessaires ; terminez ceux dont vous n’avez pas besoin.
La plupart des organisations peuvent faire tout ceci :

• Exposez IMAPS (993) et la soumission (587). Envisagez de désactiver IMAP en clair (143) sur les interfaces publiques.
• Gardez le port 25 pour le SMTP serveur-à-serveur, mais n’autorisez pas l’auth utilisateur dessus. Les utilisateurs doivent s’authentifier sur 587 (ou 465 si nécessaire).
• Si vous publiez autodiscover/autoconfig, assurez-vous qu’ils pointent vers les ports sécurisés uniquement.

Plus vous exposez de protocoles, plus vous avez besoin d’une politique cohérente. En pratique, la « politique cohérente » est là où naissent les incidents.

2) Limiter les nouvelles connexions au bord réseau

C’est le levier le plus rapide quand vous êtes sous charge. La limitation de débit achète du temps et protège conntrack et les tables de processus.
Elle ne résout pas le spraying, mais elle empêche le martèlement.

Mettez des limites sur les nouvelles connexions vers 993 et 587, par IP source. Soyez conservateur : vous façonnez l’Internet, vous ne le punissez pas.
Aussi : ajoutez en liste blanche vos egress VPN et vos probes de monitoring.

3) Utilisez fail2ban, mais traitez-le comme du code

fail2ban est efficace quand :

• Vos logs sont à l’endroit où fail2ban les lit.
• La regex correspond exactement à votre format de log.
• Bantime/findtime/maxretry correspondent au profil de l’attaquant.
• Vous ne bannissez pas votre propre NAT ni votre scanner de sécurité.

En cas de spraying, maxretry peut être sans objet : les attaquants peuvent faire une tentative par IP. C’est pourquoi le throttling par utilisateur compte.

4) Limiter l’authentification par utilisateur, pas seulement par IP

Les contrôles par IP échouent face aux botnets. Les contrôles par utilisateur échouent face au guessing distribué si vous n’avez pas de bonne protection contre l’énumération d’utilisateurs.
Malgré tout, les throttles par utilisateur font la différence entre « bruit d’attaque » et « LDAP en feu ».

Avec Dovecot, vous pouvez introduire des pénalités d’auth et limiter la concurrence des requêtes d’auth. L’objectif n’est pas d’arrêter chaque tentative ; l’objectif est de rendre l’attaque coûteuse
tout en gardant les vrais utilisateurs fonctionnels.

5) Durcir l’authentification : MFA quand possible, mots de passe d’application quand nécessaire

Si vous pouvez faire du MFA pour IMAP/SMTP, faites-le. En pratique, de nombreux clients IMAP/SMTP traditionnels ne gèrent pas le MFA interactif,
vous utiliserez donc des mots de passe spécifiques à l’application ou des mécanismes OAuth selon votre écosystème.

Si votre environnement est auto-hébergé et non intégré à un fournisseur d’identité moderne, le mouvement pragmatique est :

• Politique de mot de passe forte, appliquée côté serveur (longueur et rejet des mots de passe courants).
• Désactiver la connexion pour les boîtes partagées quand c’est faisable ; utiliser la délégation à la place.
• Exiger TLS, désactiver les authentifications legacy quand possible.

6) Détecter la compromission en observant ce qui se passe après un succès d’auth

Les connexions réussies pendant une attaque sont la vraie urgence. Votre supervision doit déclencher des alertes sur :

• Les premières IPs pour un utilisateur, surtout depuis des géographies inhabituelles.
• Des pics soudains d’envois via SMTP AUTH depuis une boîte qui reçoit habituellement seulement.
• Connexion IMAP réussie suivie d’extractions massives immédiates (les schémas d’exfiltration varient, mais les pics de volume sont parlants).

7) Protégez les admins : construisez un chemin d’accès « toujours fonctionnel »

Le travail de lockdown est là où les équipes se verrouillent elles-mêmes. La solution n’est pas le courage ; c’est de la conception :

• Ayez un VPN avec egress IPs stables et mettez-les en liste blanche pour la gestion et (optionnellement) les ports mail.
• Gardez un chemin console hors bande (console série cloud, iDRAC/iLO) testé mensuellement.
• Conservez les procédures de récupération quelque part d’accès facile quand le serveur mail est down. Si votre runbook vit dans l’email, vous méritez la soirée qui arrive.

Blague n°2 : La façon la plus simple de prouver que vous n’avez pas d’accès hors bande est de bloquer votre propre IP puis « SSH plus fort ».

Trois mini-récits d’entreprise depuis le terrain

Incident n°1 : La mauvaise hypothèse qui a fait tomber « seulement IMAP »

Une entreprise de taille moyenne utilisait la pile classique Postfix + Dovecot. Un brute force IMAP a commencé à monter pendant la nuit.
L’astreinte a vu l’évidence : des milliers d’échecs par minute. L’hypothèse : « Ce n’est que l’IMAP, le SMTP va tenir. »
Ils ont bloqué une poignée d’IPs et sont retournés essayer de dormir.

Au matin, les cadres ne pouvaient plus envoyer de mail. Le problème n’était pas SMTP. C’était l’authentification.
Dovecot était configuré pour interroger LDAP à chaque tentative d’auth, et le brute force était en fait un test de charge soutenu sur LDAP.
La latence LDAP a monté, les requêtes d’auth se sont accumulées, et le même service LDAP soutenait aussi SMTP AUTH (soumission). La soumission a donc commencé à timeout aussi.

La deuxième hypothèse de l’équipe fut pire : « Si on redémarre Dovecot et Postfix, ça va nettoyer la file. » Ça a nettoyé un peu l’état local,
mais les attaquants ont continué. Le redémarrage a aussi provoqué une brève tempête de reconnexions légitimes depuis les clients mobiles.
Cette poussée légitime plus l’attaque a poussé LDAP par‑dessus bord.

La correction n’a pas été héroïque. Ils ont appliqué du throttling d’auth Dovecot et une limite de débit firewall pour les nouvelles connexions IMAPS,
puis ont ajusté fail2ban pour bannir plus rapidement en cas d’échecs répétés. LDAP a récupéré en quelques minutes.
Une fois stable, ils ont revu les comptes ciblés, forcé des réinitialisations de mots de passe sur quelques boîtes partagées, et introduit des mots de passe d’application.

La leçon : ne pas isoler mentalement les protocoles quand ils partagent le même backend d’auth. Sous attaque, tout ce qui touche l’auth devient un seul système.

Incident n°2 : L’optimisation qui s’est retournée contre eux (un peu trop maline avec les bans)

Une autre organisation a estimé que fail2ban était « trop lent » car il attendait des entrées de log puis appelait une action pare-feu.
Un ingénieur a mis en place une règle pare-feu agressive qui dropait les nouvelles connexions IMAPS si une IP source ouvrait plus de quelques connexions par seconde.
C’était rapide et élégant. Ça supposait aussi que le monde ressemblait à l’ordinateur portable de l’ingénieur.

L’entreprise avait des télétravailleurs derrière quelques gros FAI grand public et un concentrateur VPN corporate.
Quand une centaine d’utilisateurs se sont reconnectés après une coupure Wi‑Fi, ils sont apparus comme un petit nombre d’IPs source (NAT et egress VPN).
La nouvelle règle a interprété « centaines d’utilisateurs légitimes » comme « un attaquant très enthousiaste ».
IMAP est devenu instable au pire moment.

Pire : le drop du rate-limit n’avait pas de logs. Le support a rapporté « le mail est en panne », les métriques semblaient normales, et le serveur mail lui‑même
n’affichait aucune erreur. Le pare‑feu faisait son travail en silence — contre la mauvaise cible.

Ils se sont remis en ajoutant des whitelists explicites pour les plages egress VPN et NAT de bureau, en passant de « connexions par seconde »
à « échecs d’auth par unité de temps » quand c’était possible, et en ajoutant du logging sur la règle de drop avec un échantillonnage prudent.
Ils ont aussi documenté le comportement des clients : les clients IMAP mobiles peuvent ouvrir plusieurs connexions parallèles et se reconnecter agressivement.

La leçon : les optimisations au bord réseau doivent avoir de l’empathie pour le comportement des clients, pas seulement du mépris pour les attaquants.
Et les drops silencieux sont parfaits jusqu’au moment où il faut déboguer à 03:00.

Incident n°3 : La pratique ennuyeuse qui a sauvé la mise (baseline + whitelist sûre)

Une équipe de services financiers avait l’habitude ennuyeuse suivante : chaque trimestre, ils enregistraient les plages « normales » pour les connexions IMAP, les échecs d’auth,
et le débit de soumission. Ils maintenaient aussi une petite whitelist revue : leurs egress VPN, leur système de monitoring,
et une plage bastion break-glass. Personne n’en parlait en meeting. Ça n’a jamais fait de slide.

Quand le brute force est arrivé, l’astreinte a comparé les stats live à la baseline et a immédiatement vu la différence : les échecs d’auth étaient 50× la normale,
mais les connexions réussies restaient stables. Ça suggérait du brute force plutôt qu’un compte compromis envoyant du spam.
Ils ont activé un changement d’incident pré-approuvé : resserrer les pénalités Dovecot et réduire le taux autorisé de nouvelles connexions IMAPS.

Le détail clé : la whitelist était déjà en place et testée. L’accès admin a continué. La supervision est restée en ligne.
Ils ont pu itérer sur les bans sans craindre de perdre la main sur la machine.

Après l’attaque, ils ont revu les comptes ciblés et ont mis en place une politique : les boîtes partagées ne doivent pas servir à se connecter, seulement à la délégation.
Les réinitialisations de mots de passe ont été ciblées, pas panique‑drive. Personne n’a perdu l’accès à son runbook, parce que le runbook vivait hors de l’email.

La leçon : les baselines ennuyeuses et les whitelists ennuyeuses sont ce qui transforme un événement de sécurité en une journée d’opérations routinière.

Erreurs courantes : symptômes → cause racine → correction

1) Symptôme : IMAP fonctionne pour certains utilisateurs, échoue aléatoirement pour d’autres

Cause racine : Le rate limiting par IP ou fail2ban bannit les egress NAT/VPN. Plusieurs utilisateurs partagent une même IP source.

Correction : Mettez en liste blanche les egress VPN/bureau. Privilégiez le throttling par utilisateur pour les échecs d’auth. Ajoutez du logging/échantillonnage sur les drops du pare‑feu pour voir ce que vous bloquez.

2) Symptôme : Charge élevée du serveur mail, mais le trafic réseau n’est pas énorme

Cause racine : Le CPU chauffe sur les handshakes TLS et la vérification des hashes de mot de passe ; les attaquants n’ont pas besoin d’une grosse bande passante.

Correction : Limitez les nouvelles connexions, activez les pénalités d’auth, et assurez-vous que la réutilisation des sessions TLS est correctement configurée. Gardez des hashes forts ; throttlez les tentatives au lieu de les affaiblir.

3) Symptôme : Pics « Authentication failed », puis alertes LDAP/AD

Cause racine : Le backend d’auth est le point d’étranglement ; le brute force devient un DoS d’authentification.

Correction : Mettez des throttles côté serveur mail, envisagez du caching quand approprié, et assurez-vous que l’annuaire a des limites de connexion saines et de la supervision.

4) Symptôme : fail2ban affiche zéro bans lors d’une attaque évidente

Cause racine : Mauvais chemin de log, mismatch journald vs fichier, ou filtre regex qui ne correspond pas au format de log Dovecot/Postfix.

Correction : Validez l’entrée de log. Lancez fail2ban-regex contre vos lignes réelles. Confirmez que le jail référence les fichiers réels.

5) Symptôme : Le disque se remplit pendant la nuit, puis les services tombent

Cause racine : Amplification des logs sous attaque + logrotate faible + petit /var. Parfois combiné avec un niveau de debug auth laissé activé.

Correction : Corrigez logrotate, compressez agressivement, stockez les logs sur un FS séparé si possible, et arrêtez le flot d’auth avec throttling/bans.

6) Symptôme : Plaintes d’abus sortant, blacklisting et clients en colère

Cause racine : Credential stuffing réussi ou mots de passe SMTP AUTH faibles. Les attaquants utilisent votre serveur comme relais en s’authentifiant légitimement.

Correction : Réinitialisez les identifiants des comptes affectés, activez MFA/mots de passe d’application quand possible, ajoutez des limites d’envoi par utilisateur et alertez sur des schémas d’envoi anormaux.

7) Symptôme : Vous bloquez « les attaquants », mais l’attaque continue sans changement

Cause racine : Distribution botnet ou attaquants utilisant de larges pools IP ; le blocage par IP seul ne suffit pas.

Correction : Ajoutez des throttles par utilisateur, exigez une authentification plus forte, et concentrez‑vous sur la détection et la réponse rapide plutôt que sur des listes de bans infinies.

8) Symptôme : Après un « durcissement », des clients légitimes ne peuvent plus se connecter

Cause racine : Protocoles/ports désactivés sans inventaire des clients (anciens appareils, imprimantes, monitoring, applications métier).

Correction : Inventoriez les clients, publiez les paramètres supportés (993/587, TLS obligatoire), et proposez une fenêtre de migration. Bloquez l’accès legacy par étapes, pas par un changement fatal un vendredi après-midi.

Listes de contrôle / plan étape par étape

Phase 0 : Ne vous verrouillez pas (faites ceci avant de toucher aux bans)

1. Confirmez que l’accès hors bande fonctionne (console cloud, IPMI, série). Testez la connexion, pas seulement « ça existe ».
2. Mettez en liste blanche l’egress de management (VPN, bastion, bureau) dans le pare‑feu et les ignore lists de fail2ban.
3. Faites un snapshot de la config courante (copiez les configs pertinentes ; notez les règles pare‑feu et les réglages des jails fail2ban).
4. Vérifiez la marge disque sur /var et /var/log. Sous attaque, les logs peuvent devenir la panne.

Phase 1 : Stabiliser le service pendant un brute force actif (15–60 minutes)

1. Confirmez la portée de l’attaque : IMAP seulement, SMTP AUTH seulement, ou les deux. Utilisez journald ou mail.log pour compter.
2. Appliquez une limitation réseau pour les nouvelles connexions vers 993/587 (prudemment ; mettez en whitelist les sources egress partagées connues).
3. Activez/vérifiez les bans fail2ban sur Dovecot et postfix-sasl. Assurez‑vous de la source de log correcte.
4. Activez le throttling Dovecot pour protéger le backend d’auth et le CPU.
5. Surveillez conntrack et les limites de processus. Si vous êtes proche du max, le shaping des connexions n’est pas optionnel.

Phase 2 : Réduire le rayon d’impact (même jour)

1. Identifiez les comptes ciblés (boîtes partagées, dirigeants, finance). Traitez‑les comme haut risque.
2. Réinitialisez les identifiants pour les comptes avec des connexions réussies suspectes, pas pour tout le monde « au cas où ». Les resets paniqués créent des pannes support.
3. Désactivez la connexion IMAP pour les boîtes partagées quand possible ; utilisez l’accès délégué à la place.
4. Appliquez TLS-only et ports modernes : IMAPS 993, soumission 587. Supprimez le 143 public si faisable.
5. Ajoutez des limites d’envoi pour SMTP AUTH afin de contenir les comptes compromis.

Phase 3 : Rendre ça durable (sprint suivant)

1. Baseliner le comportement normal : échecs d’auth/min, connexions, régions sources typiques, débits d’envoi typiques.
2. Alertes sur les anomalies importantes : connexion réussie depuis un ASN/pays nouveau, pics d’échecs d’auth par utilisateur, pics de volume sortant par utilisateur.
3. Durcir les mots de passe : longueur, liste de mots interdits, et politique de rotation alignée sur votre plate-forme d’identité.
4. Planifier une authentification moderne si votre écosystème le supporte. Sinon, planifiez des mots de passe d’application et une portée limitée.
5. Faire des game days : simuler du brute force, vérifier les bans, tester les whitelists, vérifier que vous pouvez toujours administrer le serveur.

FAQ

1) Dois‑je simplement bloquer tous les pays sauf le nôtre ?

Si vos utilisateurs ne voyagent jamais et que vous n’avez pas de fournisseurs globaux, ça peut aider. En réalité, le geo‑blocking est un ralentisseur.
Les attaquants peuvent utiliser des IP nationales aussi. Utilisez‑le comme une couche, pas comme votre stratégie unique.

2) Politiques de verrouillage de compte : bonne idée ou piège ?

Les verrouillages peuvent arrêter le brute force mais aussi permettre des dénis de service contre les utilisateurs (attaquants déclenchent intentionnellement les verrouillages).
Privilégiez le throttling et des règles de risque adaptatives quand possible ; si vous verrouillez, faites‑le court et surveillez.

3) fail2ban suffit‑il ?

Pas seul. fail2ban est excellent contre les échecs répétés depuis la même IP. Il est faible face au spraying distribué et au stuffing.
Associez‑le à du throttling par utilisateur, une authentification forte, et de la détection d’anomalies pour les connexions réussies.

4) Pourquoi ne pas désactiver IMAP complètement ?

Parfois c’est possible, et c’est merveilleux. Souvent ce n’est pas faisable à cause de clients legacy, workflows partagés, ou applications qui interrogent IMAP.
Si vous devez garder IMAP, gardez‑le sur 993 uniquement, exigez TLS, et restreignez qui peut l’utiliser.

5) Dois‑je diminuer le coût des hashes de mot de passe pour réduire l’utilisation CPU pendant les attaques ?

Non. C’est échanger la sécurité long terme pour un confort court terme. Réglez le chemin d’attaque avec des throttles et des limitations de débit.
Gardez des hashes forts ; c’est un des rares contrôles qui compte encore après une fuite de base de données.

6) Comment éviter de bannir notre propre VPN ou NAT de bureau ?

Maintenez une petite whitelist revue, et documentez‑la comme du code de production. Ajoutez ces IPs aux ignore lists de fail2ban et aux règles d’acceptation du pare‑feu.
Testez‑la trimestriellement. « On pense que l’egress VPN est toujours cette IP » n’est pas un test.

7) Quel est le signe le plus clair qu’un compte est réellement compromis ?

Des connexions réussies depuis des IP inhabituelles suivies de pics d’envoi sortant, de modifications de règles de la boîte (si applicable), ou de larges/rapides extractions IMAP.
Aussi : des utilisateurs qui signalent « des mails envoyés que je n’ai pas envoyés » — c’est le système de surveillance humain que vous n’aviez pas prévu.

8) Faut‑il déplacer la soumission sur le port 465 ou 587 ?

587 est le standard moderne pour la soumission ; 465 existe et fonctionne mais peut embrouiller la politique et la supervision si vous utilisez les deux.
Choisissez un seul chemin client supporté, documentez‑le et surveillez‑le correctement.

9) Puis‑je bloquer en toute sécurité le port 25 pour arrêter les attaques ?

Bloquer le 25 entrant casse la livraison de mail des autres serveurs à moins que vous ne relayiez via une passerelle. Si vous avez une passerelle mail, parfait — bloquez le 25 sur le backend.
Si cette machine est votre MX, le port 25 reste ouvert. Concentrez‑vous sur la prévention d’abus et la protection des ressources.

10) Et si l’attaque rend le serveur instable et que j’ai besoin d’un soulagement immédiat ?

Appliquez des limites de connexion pour les nouvelles connexions vers 993/587 et des bans temporaires pour les IPs en tête, puis vérifiez que votre accès admin fonctionne toujours.
Stabilisez d’abord, puis ajustez. Ne faites pas cinq changements architecturaux durant la même fenêtre d’incident.

Prochaines étapes qui ne vous mordront pas plus tard

Si vous ne faites que quelques actions, faites celles‑ci. Ce sont des mesures fiables — celles que vous pouvez défendre lors d’un post‑mortem sans avoir l’air de négocier avec la physique :

• Réduire la surface : IMAPS (993) et soumission (587) sont vos valeurs par défaut ; cessez d’exposer IMAP en clair (143) publiquement sauf exigence forte.
• Stabiliser sous charge : limitez les nouvelles connexions, protégez conntrack, et throttlez l’auth avant que votre annuaire ne devienne dommage collatéral.
• Rendre fail2ban réel : logs corrects, regex correctes, fenêtres de ban sensées, et whitelists explicites pour les egress partagés.
• Prévoir les cas de succès : surveillez les connexions réussies pendant les attaques et bloquez l’envoi sortant pour réduire la fraude et le risque de blacklisting.
• Protégez votre propre accès : console hors bande testée et une whitelist documentée ne sont pas « agréables à avoir ». Ce sont les moyens de réparer la production en sécurité.

Puis planifiez le travail ingrat : baseline du comportement normal, inventaire des clients, et migration loin des authentifications legacy quand vous le pouvez.
Les attaquants ne sont pas créatifs ici. Ils sont constants. Vous pouvez l’être aussi — mais avec de meilleurs résultats.