FortiMail MO-18 : répondre à une vague de spam active

Une vague de spam active — qu'elle soit entrante ou sortante — génère une pression opérationnelle immédiate sur les équipes messagerie et sécurité. En cas de spam entrant massif, les files d'attente s'engorgent et les utilisateurs reçoivent des vagues de messages frauduleux ; en cas de spam sortant, le risque est celui de la mise en liste noire des adresses IP de l'organisation et de l'atteinte à la réputation. Le MO-18 FortiMail définit la procédure de crise à appliquer dans les deux cas. Il distingue clairement le scénario entrant du scénario sortant, séquence les actions de blocage d'urgence, de confinement, d'investigation et de post-mortem, et précise les seuils de décision et les critères de clôture. Ce mode opératoire s'intègre dans le processus CSIRT de l'organisation et référence les outils de diagnostic FortiMail disponibles en CLI et GUI.

MO-18 — RÉPONSE À UN SPAM ACTIF : mesures de blocage et de confinement

Nouveau module — complément aux MO-01 à MO-17 et à la fiche de durcissement

Ce module traite ce que les autres ne traitent pas : la crise. Le durcissement est une démarche de fond ; ici on est à T0, une campagne passe maintenant, et il faut arrêter l’hémorragie en quelques minutes sans casser le flux légitime.

Deux scénarios distincts, à ne jamais confondre : - Scénario A — vague entrante : une campagne de spam/phishing atteint les boîtes. - Scénario B — émission sortante : votre FortiMail émet du spam (compte compromis, relais ouvert, backscatter). Bien plus grave : risque de blacklist de votre IP publique et perte de tout le courrier sortant.

Règle d’or de ce module : toute mesure d’urgence est temporaire, tracée et datée. Chaque règle créée en crise reçoit un commentaire URGENCE-<ticket>-<date>-REVOIR-LE-<date+7>. Une mesure d’urgence non revue devient une dette de configuration, puis un trou.

PARTIE 0 — Les 5 premières minutes (commun A et B)

• Ouvrir le tableau de bord : Dashboard > Status + FortiView. Regarder le volume horaire : est-ce un pic entrant, sortant, ou les deux ?
• Monitor > Mail Queue — quatre files à regarder : Deferred, Spam Outbreak, Incoming, Outgoing. Une file Outgoing ou Deferred anormalement pleine = scénario B jusqu’à preuve du contraire.
• Monitor > Log > AntiSpam sur la dernière heure : quelles techniques déclenchent, lesquelles restent muettes.
• Monitor > Reputation > Sender Reputation : y a-t-il une ou deux IP qui dominent ?
• Décider A ou B, et sauvegarder la configuration avant toute modification : Maintenance > Configuration > Backup — ou en CLI execute backup config ....

Ne pas commencer par modifier le profil AntiSpam. C’est le réflexe naturel et c’est le plus lent : le profil AS agit après acceptation du message, coûte du CPU, et le tuning demande des heures. En crise, on bloque en amont (session, ACL, listes), puis on affine.

PARTIE A — VAGUE DE SPAM ENTRANTE

A.1 Qualifier l’invariant de campagne (5–10 min)

Sans invariant, pas de blocage chirurgical — et un blocage non chirurgical crée des faux positifs qui coûtent plus cher que la vague.

Monitor > Log > History → filtrer sur la fenêtre de temps → ouvrir 5 à 10 messages de la campagne → Cross Search sur chacun. Chercher, dans l’ordre de préférence :

Noter chaque invariant dans le ticket. C’est ce qui permettra de retirer les mesures une fois la vague passée.

A.2 Blocage immédiat par block list système — 2 min, totalement réversible

Le premier geste, parce qu’il est instantané et sans effet de bord structurel.

GUI : Security > Block/Safe List > System → onglet Block List → [New] : - Type : adresse e-mail complète, ou domaine (*@domaine-campagne.tld), ou IP/plage selon ce que propose votre version ; - Ajouter les invariants de rang 1 et 2 ; - Commenter chaque entrée avec la référence du ticket et la date de revue.

Limite à connaître : la block list agit sur l’expéditeur déclaré. Sur du spoofing avec des expéditeurs jetables, elle sera contournée en quelques minutes. Elle est faite pour les campagnes à expéditeur stable.

A.3 Blocage en Access Control — l’arme lourde propre (5 min)

L’ACL est évaluée avant les politiques, donc avant tout scan : c’est le blocage le moins coûteux et le plus fiable.

GUI : Policy > Access Control > Receiving → [New] : - Sender pattern : *@domaine-campagne.tld (ou *) ; - Source IP/netmask : la plage identifiée (ex. 203.0.113.0/24) ; - Recipient pattern : vos domaines ; - Action : REJECT ; - [Move] la règle au-dessus des règles RECEIVE génériques — sinon elle ne matchera jamais.

Nouveauté 8.0 très utile en crise (licence advanced management) : l’ACL peut matcher sur le From: de l’en-tête, pas seulement sur l’enveloppe :

config policy access-control receive        # ✔ vérifié 8.0
    edit <id>
        set sender-option header-from       # ou envelope-or-header-from
        set action reject
    next
end

C’est ce qui permet enfin de bloquer une usurpation de marque affichée sans toucher à l’enveloppe.

⚠️ Jamais de plage large. Un /16 ou un ASN entier bloqué en urgence vous coûtera un client. Si l’invariant IP est trop large, passez au rang suivant.

A.4 Neutraliser l’infrastructure web de la campagne (5 min)

Les campagnes changent d’expéditeur toutes les heures mais gardent leur domaine de destination pendant des jours. C’est l’invariant le plus rentable.

GUI : Security > URL Filter → URL rating overrides → [New] : saisir le domaine de la campagne → l’assigner à une catégorie bloquée (ou à une catégorie personnalisée créée pour l’occasion, ex. CAMPAGNE-URGENCE).

Puis, dans le profil AntiSpam actif, section FortiGuard > URL Category : vérifier que la catégorie est bien sélectionnée avec une action ferme.

Rappel de comportement : quand IP Reputation et URL Category détectent tous les deux, c’est l’action de URL Category qui prévaut. Réglez-la en conséquence.

A.5 Mettre en place le canal de blocage rapide : threat feed interne (30 min une fois, 30 s ensuite)

À faire à froid, pas en crise — mais c’est ce qui rend les crises suivantes triviales.

Hébergez sur un serveur web interne deux fichiers texte que votre SOC édite : - iocs-ip.txt — une IP ou un CIDR par ligne ; - iocs-url.txt — un URI par ligne (wildcards * en début/fin acceptés, IDN et UTF-8 supportés).

GUI : Security > Threat Feed → [New] : - Nom : TF_SOC_IP / TF_SOC_URL ; - Type : IP / URL filter (catégorie FortiGuard) ; - URI du flux, refresh : 5 minutes ; - Associer : le feed IP dans la section FortiGuard > Threat feed du profil AS ; le feed URL via la catégorie d’URL associée.

Effet : en crise, bloquer un IOC = ajouter une ligne dans un fichier texte. Plus de modification de configuration sous pression, plus de règle orpheline oubliée, et un historique en Git.

A.6 Campagne sans invariant réseau : dictionnaire d’urgence (15 min)

Quand tout change sauf le texte (typiquement le phishing FR de marque).

GUI : Profile > Dictionary > Dictionary → [New] DICT_URGENCE_<ticket> : - 3 à 6 motifs spécifiques à cette campagne (pas de mots génériques), poids 3 chacun, recherche sujet + corps ; - Ajouter la recherche sur le display name et le Reply-To si votre version le permet.

Associer dans un clone du profil AS en production (AS_ENTRANT_DURCI_URGENCE), seuil bas (3–4), action quarantaine, et basculer la recipient policy sur ce clone.

Pourquoi un clone et pas une modification directe ? Parce que le retour arrière est alors une seule action (rebasculer la politique), et non une reconstitution de mémoire à 2 h du matin.

A.7 Durcissement temporaire de la couche session (10 min)

Sur SESSION_ENTRANT_DURCI, mesures réversibles à activer pour la durée de la vague :

Le tempfail (4xx) est votre meilleur ami en crise : il repousse sans perdre. Un émetteur légitime réessaiera ; un botnet non.

A.8 Allonger la fenêtre zero-hour

config system fortiguard antispam           # ✔ vérifié
    set outbreak-protection-period 60
end

Pendant une vague, c’est le réglage qui laisse à FortiGuard le temps de qualifier la campagne. Surveiller Monitor > Mail Queue > Spam Outbreak : la file doit se vider progressivement, pas gonfler indéfiniment.

Rappel (cf. audit C-05) : l’outbreak ne se déclenche que si le contrôle FortiGuard n’a rien retourné, il exempte les IP en safe list et les règles ACL RELAY, et un reject configuré bascule en quarantaine système sur les mails retenus.

A.9 Filtrage géographique ponctuel

Si la vague provient d’une zone géographique sans aucun trafic légitime pour vous : Profile > Email, IP and GeoIP groups → créer un GeoIP group → l’utiliser dans une IP policy dédiée pointant vers un session profile très restrictif, placée au-dessus de la policy Internet.

À manier avec précaution : le geo-blocking a un taux de FP structurellement élevé (VPN, roaming, hébergeurs). Time-boxez-le à 48 h.

A.10 Traiter les messages déjà livrés

C’est le point que la plupart des procédures oublient. Bloquer le flux n’annule pas ce qui est déjà en boîte.

• Mode gateway/transparent (SMTP) : FortiMail ne peut pas rappeler un message déjà remis au serveur interne. La suppression se fait côté messagerie : recherche et purge Exchange / Microsoft Purview (Compliance Search + Purge), ou côté Google Workspace.
• Mode API Microsoft 365 / Google (7.6+/8.0) : FortiMail peut agir a posteriori sur les boîtes — Searching and manual actions permet de rechercher et d’appliquer une action de remédiation sur les messages déjà délivrés. Si vous avez ce mode, c’est ici qu’il justifie son coût.
• Dans tous les cas : avertir les utilisateurs concernés avant de supprimer (un mail qui disparaît sans explication génère plus de tickets que le spam lui-même).

A.11 Communication utilisateurs

• Message court, factuel : ce que c’est, ce qu’il ne faut pas faire, comment signaler.
• Astuce technique : un disclaimer temporaire injecté en tête des mails entrants externes (System > Customization > Disclaimer) — la 8.0 permet de le convertir en HTML et de le masquer de l’aperçu mobile pour ne pas polluer les notifications.
• Rappeler le canal de signalement (spam-signalement@) — c’est le moment où vous aurez le plus d’échantillons de qualité.

A.12 Soumission FortiGuard

Soumettre 3 à 5 .eml complets via le portail FortiGuard (Anti-Spam sample submission). Sur une campagne à volume, la signature revient souvent en quelques heures et rend vos mesures d’urgence inutiles — ce qui est l’objectif.

PARTIE B — ÉMISSION DE SPAM SORTANT (compte compromis / relais)

Priorité absolue. Chaque heure d’émission rapproche votre IP publique d’un listing RBL, dont la sortie prend des jours.

B.1 Confirmer et identifier (5 min)

• Monitor > Mail Queue > Outgoing et Deferred : volume anormal, destinataires externes en masse ?
• Monitor > Reputation > Authentication Reputation et l’onglet Auto Blocklist : quel compte accumule des échecs ou des sessions anormales ?
• Monitor > Log > History, filtre direction = outgoing, tri par expéditeur : un ou deux expéditeurs dominent → compte compromis. Répartition uniforme → relais ouvert ou backscatter.
• Tester immédiatement le statut RBL de votre IP publique (MXToolbox ou équivalent).

B.2 Couper l’émission — dans cet ordre

• Suspendre le compte côté annuaire (AD/IdP) : désactivation ou changement de mot de passe + révocation des sessions et des jetons. Un simple changement de mot de passe ne coupe pas une session SMTP AUTH déjà établie ni un jeton OAuth.
• Purger la file sortante : Monitor > Mail Queue > Outgoing → sélectionner les messages de l’expéditeur → supprimer. En CLI : diagnose system mailqueue pour l’état ; ⚠ execute cleanqueue purge sans discernement — à éviter en crise, vous perdriez le courrier légitime en attente.
• Bloquer l’expéditeur en ACL sortante : Policy > Access Control > Receiving → Sender = compte@domaine, source = plage interne → REJECT, placée au-dessus des règles RELAY.
• Réduire drastiquement le profil de session sortant SESSION_SORTANT : sender address rate control (messages et destinataires par expéditeur authentifié et par heure) au strict minimum, et activer la notification admin en cas de dépassement. Si ce réglage n’était pas configuré, c’est la leçon de l’incident.
• Vérifier qu’il ne s’agit pas d’un relais ouvert : depuis une machine externe, telnet <IP publique> 25, puis MAIL FROM:<[email protected]> / RCPT TO:<[email protected]> → réponse attendue 554 5.7.1 Relaying denied. Si le relais passe, corriger immédiatement les règles RELAY de l’ACL (source = uniquement vos IP internes).
• Vérifier le backscatter : si l’émission est faite de DSN/NDR, c’est la vérification des destinataires (MO-07) et/ou BATV (MO-06) qui manquent. Activer la vérification LDAP en rejet 550 au RCPT TO stoppe la source à elle seule.

B.3 Sortie de crise

• Delisting : ne pas demander le retrait des RBL tant que l’émission n’est pas coupée et vérifiée — un second listing est plus long à lever.
• Analyse post-incident sur le compte : d’où venait la connexion, depuis quand, quels autres accès.
• Contrôles à mettre en place s’ils manquaient : MFA sur la messagerie, AUTH interdite sur le 25 public, profil AntiSpam sur les politiques sortantes, alerte sur seuil de file d’attente.

PARTIE C — CLI de crise (aide-mémoire)

# ✔ vérifié — diagnostic
get system status                        # version, licences
diagnose debug rating                    # les serveurs FortiGuard répondent-ils ?
diagnose system mailqueue                # état des files
diagnose system top                      # charge
get system performance

# ✔ vérifié — fenêtre zero-hour
config system fortiguard antispam
    set outbreak-protection-period 60
end

# ✔ vérifié 8.0 — ACL sur le From: d'en-tête
config policy access-control receive
    edit <id>
        set sender-option header-from
        set action reject
    next
end

# Debug SMTP live — À COUPER IMPÉRATIVEMENT APRÈS USAGE
diagnose debug application smtp -1
diagnose debug enable
# ... observer ...
diagnose debug disable

# Capture ciblée d'un émetteur
diagnose sniffer packet port1 "tcp port 25 and host 203.0.113.10" 4 100

# Sauvegarde avant/après intervention
execute backup config scp <fichier> <user@serveur:/chemin/> <port>

⚠ Les autres commandes de crise (gestion des listes, purge sélective de file) varient fortement selon la branche : contrôlez par ? dans le contexte avant exécution. En cluster HA, travaillez sur le maître.

PARTIE D — REGISTRE DES MESURES D’URGENCE (modèle)

À tenir systématiquement. C’est ce document qui empêche les mesures de crise de devenir des trous permanents.

Rituel de sortie de crise (J+7) : pour chaque ligne, se poser une seule question — est-ce que cette mesure doit devenir permanente, être affinée, ou être retirée ? Les trois réponses sont acceptables ; l’absence de réponse ne l’est pas.

PARTIE E — CHECKLIST DE PRÉPARATION (à valider À FROID)

Ces contrôles conditionnent votre capacité à réagir vite. Sans eux, la Partie A vous prendra 4 heures au lieu de 30 minutes.

Module à tester au moins une fois par an sur un exercice à blanc (campagne simulée depuis une boîte externe). Une procédure de crise jamais répétée n’est pas une procédure.