FortiMail : modes opératoires GUI pas-à-pas

Configurer FortiMail via l'interface graphique requiert de naviguer dans une arborescence de menus dense, dont la logique n'est pas toujours évidente pour les équipes qui découvrent l'appliance. Ce recueil de 18 modes opératoires GUI a été conçu pour les administrateurs système et les ingénieurs sécurité qui prennent en charge FortiMail pour la première fois, ou qui souhaitent standardiser leurs procédures d'exploitation. Chaque mode opératoire est présenté sous forme de séquence pas-à-pas avec le chemin de menu exact, les valeurs recommandées et les points de contrôle à vérifier après chaque opération. Les sujets couverts vont de la création des profils antispam à la configuration des politiques de réception et d'émission, en passant par l'activation de DKIM et DMARC, la gestion de la quarantaine utilisateur, et la lecture des journaux de filtrage. Compatibles FortiMail 7.4 à 8.0.

FortiMail — MODES OPÉRATOIRES GUI PAS-À-PAS

Complément de la fiche de durcissement antispam — 100 % interface graphique

Base : FortiMail 7.4 / 7.6. Convention : Menu > Sous-menu > Onglet — ☑ = case à cocher — [Bouton] = bouton à cliquer.

⚠️ FortiMail 8.0 a refondu le framework de la GUI d’administration. Les libellés des fonctions sont conservés, mais l’agencement des écrans diffère. Sur 8.0, retrouvez chaque écran par sa fonction plutôt que par son chemin exact.

MO-01 — Vérifier la licence et la connectivité FortiGuard (15 min)

Objectif : s’assurer que les moteurs FortiGuard AntiSpam répondent — cause n°1 des passoires.

• Se connecter à la GUI d’administration (https://<ip-fortimail>/admin).
• Dashboard > Status, widget License Information :
• ligne AntiSpam : statut vert / Licensed, date d’expiration future ;
• ligne AntiVirus : idem ;
• si rouge ou expiré → renouveler le contrat, puis Maintenance > FortiGuard > Update > [Refresh].
• Maintenance > FortiGuard > Update :
• colonne Last Update Time des définitions AntiSpam/AntiVirus : moins de 24 h, idéalement moins d’une heure ;
• FortiGuard Update Options : ☑ Scheduled update → Every 1 hour ; ☑ Allow push update si présent ;
• [Apply], puis [Update Now] pour forcer une mise à jour et vérifier qu’elle réussit.
• Maintenance > FortiGuard > AntiSpam :
• vérifier que la requête de rating est configurée ;
• en cas d’échec, changer de port (essayer 443, puis 8888, puis 53), [Apply], retester.
• Contrôle de preuve — Monitor > Log > AntiSpam :
• colonne Classifier : sur les dernières 24 h, des verdicts FortiGuard doivent apparaître (IP reputation, URL category) ;
• si aucun verdict FortiGuard n’apparaît alors que du spam est détecté par d’autres techniques, la connectivité rating est cassée : ouvrir sur le pare-feu les flux sortants nécessaires depuis l’IP du FortiMail vers les serveurs FortiGuard, puis reprendre à l’étape 4.

MO-01bis — Vérifier que l’IP réelle du client SMTP est visible (10 min)

Objectif : s’assurer qu’aucun équipement en frontal ne masque l’IP source. Sans cela, la sender reputation et la FortiGuard IP reputation sont neutralisées sans aucun message d’erreur.

• Monitor > Reputation > Sender Reputation : observer la répartition des IP. Si une seule IP — celle d’un load-balancer, d’un reverse-proxy ou d’un service anti-DDoS — concentre l’essentiel du trafic, le diagnostic est posé.
• Recoupement : Monitor > Log > History, colonne Client IP sur des messages provenant d’expéditeurs manifestement différents. Si l’IP est identique, elle n’est pas la bonne.
• Correction, deux voies :
• 8.0 : System > Configuration > Web Service → activer l’identification de l’IP client d’origine à partir des en-têtes HTTP X-Forwarded-For ;
• sinon, reconfigurer l’équipement amont en mode transparent (préservation de l’IP source), ou placer le FortiMail en frontal direct.
• Contrôle : après correction, la liste des IP dans Sender Reputation doit se diversifier en quelques heures.

MO-02 — Purger les Safe Lists dangereuses (30 min)

Objectif : supprimer les bypass qui laissent passer le spam sans analyse. Une safe list court-circuite le scan et exempte également le message de la protection outbreak.

A. Listes système

• Security > Block/Safe List > System.
• Onglet Safe List.
• Passer chaque entrée en revue et supprimer (sélectionner la ligne → [Delete]) :
• toute entrée en wildcard large : *@*.com, *.fr, *.edu, un TLD entier ;
• toute entrée contenant vos propres domaines protégés (*@votredomaine.fr) — c’est la porte ouverte au spoofing ;
• les grands fournisseurs génériques : *@gmail.com, *@outlook.com, *@yahoo.com…
• Ne conserver que des adresses complètes de partenaires identifiés, chacune notée dans le registre d’exceptions (qui, pourquoi, date de revue).

B. Listes par domaine

• Security > Block/Safe List > Domain.
• Sélectionner chaque domaine protégé → onglet Safe List → même purge qu’en A.

C. Listes personnelles

• Security > Block/Safe List > Personal : parcourir les comptes ayant des entrées (tri par nombre d’entrées) ; supprimer les entrées manifestement dangereuses — votre domaine, wildcards.
• Encadrement à la source, deux options selon votre politique :
• 8.0 (licence advanced management) : fixer une limite de taille des listes personnelles, avec suivi de l’usage sur cette même page. C’est l’approche recommandée : elle conserve l’autonomie des utilisateurs tout en bornant le risque.
• Ou désactiver l’usage des listes personnelles dans le profil AntiSpam.

D. Access Control « SAFE »

• Policy > Access Control > Receiving.
• Repérer toute règle dont la colonne Action vaut SAFE ou SAFE & RELAY :
• source large (0.0.0.0/0, domaine générique) → supprimer ou passer l’action à RECEIVE ;
• partenaire identifié → vérifier que la justification est documentée, sinon passer à RECEIVE.

E. Les deux bypass silencieux du profil AntiSpam

Profile > AntiSpam > AntiSpam > [chaque profil] > Scan Option : - ☐ Bypass scan on SMTP authentication : décocher. Cette option est activée par défaut en sortie d’usine ; laissée telle quelle, tout client authentifié — dont un compte interne compromis — échappe au filtrage. - ☐ Apply default action without scan upon policy match : décocher. Cochée, elle applique l’action par défaut sans aucun scan.

MO-03 — Créer le profil de session durci SESSION_ENTRANT_DURCI (45 min)

Objectif : rejeter le gros du spam dès la connexion SMTP.

• Profile > Session > Session → [New].
• Profile name : SESSION_ENTRANT_DURCI — Direction : Incoming si le champ existe.
• Section Connection Settings :
• ☑ Reject connections without HELO/EHLO ;
• Restrict number of connections per client (per 30 minutes) : 60 ;
• Idle timeout : 60 secondes ;
• ☑ Prevent open relay si l’option figure ici selon la version.
• Section Sender Reputation :
• ☑ Enable sender reputation checking ;
• Throttle client at : 50 — Temporarily fail client at : 70 — Reject client at : 80. > Ces valeurs sont un point de départ, pas une cible. Les laisser une semaine en place, puis consulter Monitor > Reputation > Sender Reputation pour lire la distribution réelle des scores sur votre trafic, et réajuster. Des seuils repris d’un document sans mesure produisent soit aucun effet, soit des faux positifs.
• Section Session Settings / SMTP Limits :
• Restrict number of messages per session : 20 ;
• Restrict number of recipients per message : 50 ;
• ☑ Reject commands before HELO/EHLO si présent ;
• (Level 2, semaine 2) ☑ Reject if HELO/EHLO argument is not a valid FQDN.
• Section Sender Validation :
• ☑ Reject if MAIL FROM domain has no A or MX record ;
• (Level 2) Reverse DNS check : commencer par l’option Temporarily fail (4xx) si elle est proposée. Le tempfail repousse sans perdre : un émetteur légitime réessaiera, un botnet non.
• Section SMTP AUTH : ne pas cocher Allow SMTP authentication sur ce profil entrant. L’AUTH sera portée par le profil de soumission (MO-04).
• Section TLS : laisser STARTTLS proposé en opportuniste, ne pas l’exiger.
• Section Advanced / Bypass : vérifier qu’aucune case de bypass n’est cochée — bounce verification, antispam.
• [Create].

L’association de ce profil à la politique IP « Internet » se fait au MO-10.

MO-04 — Créer le profil de session sortant SESSION_SORTANT (20 min)

• Profile > Session > Session → [New] → nom : SESSION_SORTANT.
• ☑ Allow SMTP authentication ; exiger TLS pour l’AUTH si l’option existe (☑ SMTP AUTH over TLS only).
• Limites anti-compromission de compte :
• Restrict number of messages per session : 50 ;
• Restrict number of recipients per message : 100 ;
• Section Sender address rate control : limiter le nombre de messages et de destinataires par expéditeur authentifié et par heure (par exemple 500 destinataires/h) et ☑ notifier l’administrateur en cas de dépassement. > Ce réglage est la meilleure protection contre un compte compromis. C’est lui qui transforme une compromission en incident de dix minutes plutôt qu’en listing RBL de trois jours. Ne pas le sauter.
• Désactiver le greylisting et les vérifications DNSBL sur ce profil : inutiles pour vos propres serveurs.
• [Create].

MO-05 — Activer le Greylisting (Level 2, 20 min)

À classer en Level 2 assumé. Sur un flux déjà couvert par la sender reputation et la FortiGuard IP reputation, le gain est marginal — les botnets modernes réessaient — alors que le coût en latence perçue est immédiat et visible par les utilisateurs. À activer après les autres couches, pas avant.

• Security > Other > Greylist :
• Onglet Setting : TTL initial 25 minutes ; période de rétention 30 jours ; [Apply].
• Onglet Exempt → [New] : expéditeurs de codes OTP/MFA par mail (banques, IdP) ; partenaires critiques sensibles au délai. M365 et Google réessaient correctement et n’ont généralement pas besoin d’exemption.
• Activer dans le profil de session : Profile > Session > Session > SESSION_ENTRANT_DURCI → section Session Settings → ☑ Apply greylisting → [OK].
• Suivi : Monitor > Greylist pour observer les entrées en attente et les émetteurs qui ne réessaient jamais.

MO-06 — Bounce Verification (BATV) (15 min)

Pré-requis impératif : tout le flux sortant passe par le FortiMail. Sinon, les DSN légitimes de vos propres envois seront rejetés.

• Security > Other > Bounce Verification :
• [New] → saisir une clé (chaîne aléatoire ≥ 16 caractères) → Status : Active → [Create] ;
• ☑ Enable bounce address tagging and verification ;
• pour l’action de vérification, sélectionner Use antispam profile settings ;
• [Apply].
• Retirer les bypass :
• System > Mail Setting > Domains → éditer chaque domaine → section Advanced : décocher ☐ Bypass bounce verification → [OK] ;
• Profile > Session > Session → éditer chaque profil : décocher ☐ Bypass bounce verification check → [OK].
• Contrôle à J+1 : Monitor > Log > History → filtrer sur les DSN entrants (MAIL FROM vide, <>) : les bounces illégitimes doivent apparaître rejetés.

MO-07 — Vérification des destinataires via LDAP/AD (45 min)

Objectif : rejeter au RCPT TO (550) les destinataires inexistants — stoppe les attaques par dictionnaire et le backscatter.

A. Créer le profil LDAP

• Profile > LDAP → [New].
• Profile name : LDAP_AD_INTERNE.
• Server : IP ou FQDN du contrôleur de domaine — Port : 636 avec ☑ Use secure connection (LDAPS) (recommandé), ou 389.
• Base DN : DC=votredomaine,DC=local.
• Bind DN : compte de service en lecture seule, par exemple CN=svc-fortimail,OU=Services,DC=votredomaine,DC=local, avec son mot de passe. Éviter le bind anonyme.
• Section User Query Options :
• Schema : Active Directory si proposé ;
• User query : (|(mail=$m)(proxyAddresses=smtp:$m)) — $m est remplacé par l’adresse du destinataire, proxyAddresses couvre les alias.
• [Test] (Test LDAP Query) : une adresse existante doit retourner un succès ; une adresse inexistante doit retourner not found. Ne pas continuer tant que les deux tests ne sont pas conformes.
• [Create].

B. Activer la vérification sur chaque domaine

• System > Mail Setting > Domains → éditer le domaine.
• Section Recipient Address Verification :
• Use LDAP server to verify → LDAP_AD_INTERNE ;
• s’assurer que le rejet se fait en session SMTP (550 5.1.1 User unknown au RCPT).
• [OK] — répéter pour chaque domaine protégé.

C. Test

Depuis une boîte externe, envoyer un message à [email protected] : l’expéditeur doit recevoir un NDR généré par son serveur (FortiMail a refusé au RCPT), et Monitor > Log > History doit montrer le rejet 550.

MO-08 — Créer le profil AntiSpam durci AS_ENTRANT_DURCI (75 min)

• Profile > AntiSpam > AntiSpam → sélectionner le profil actuellement utilisé → [Clone] → nom : AS_ENTRANT_DURCI → éditer le clone. On ne casse pas l’existant ; la bascule se fait au MO-10.

En 8.0, si vous avez plusieurs profils à durcir de la même façon, la fonction d’édition par lot (batch editing) applique les mêmes réglages à plusieurs profils en une opération.

• Champ Default action (en haut du profil) : sélectionner AS_ACTION_DURCI (créé au MO-09). Chaque technique pourra ensuite surcharger cette action par la sienne.
• Section FortiGuard :
• ☑ Level 1 (réputation la pire) → action Reject ;
• ☑ Level 2 → action Quarantine ;
• ☑ Level 3 (mauvaise réputation) → action Quarantine ou Tag ;
• ☑ URL Category → sélectionner les catégories Phishing, Malicious Websites, Spam URLs, Newly Observed Domains, Newly Registered Domains, ainsi que vos catégories personnalisées (MO-18bis) → action Quarantine ; > Si IP Reputation et URL Category détectent toutes deux, c’est l’action de URL Category qui s’applique. La régler au moins aussi fermement que celle des niveaux d’IP reputation.
• ☑ Threat feed si des flux IP sont configurés (MO-18bis) → action selon la fiabilité du flux ;
• (Level 2) ☑ Extract IP from Received Header — étend la requête à toutes les IP publiques des lignes Received:. Utile derrière un relais, mais une IP intermédiaire mal notée peut faire basculer un message légitime : activer après mesure ;
• ☑ Spam outbreak protection → rétention 30 à 60 minutes. > Trois comportements à connaître : elle ne se déclenche que si le contrôle FortiGuard n’a rien retourné ; sur un message retenu puis qualifié spam, une action reject bascule en quarantaine système ; les messages venant d’IP en safe list ou de règles ACL RELAY en sont exemptés. La file se surveille dans Monitor > Mail Queue > Spam Outbreak.
• Section Behavior analysis : ☑ activer, sensibilité High. Ce moteur apprend du trafic local, il s’adapte donc naturellement à votre langue et à vos correspondants.
• Section Header analysis : ☑ activer.
• Section Business email compromise — la section la plus rentable contre le phishing ciblé :
• ☑ Sender alignment → action Quarantine. Compare le From: d’en-tête au domaine d’autorisation et au Reply-To:. Disponible sur toutes les versions couvertes par ce document : à activer sans réserve.
• ☑ Impersonation analysis → sélectionner le profil IMPERSONATION_VIP (MO-13) → action System quarantine.
• ☑ Cousin domain → sélectionner COUSIN_DOMAINES (MO-13) → options de scan header + body → action Quarantine.
• ☑ Weighted analysis → sélectionner WA_ANALYSE_PONDEREE (MO-13bis). C’est le mécanisme qui cumule les signaux faibles ; démarrer en action tag.
• Section Heuristic : ☑ activer. Noter la valeur de seuil par défaut avant toute modification. Les ajustements se font ensuite par petits pas, avec mesure des faux positifs entre chaque pas.
• Section SURBL : ☑ activer le SURBL FortiGuard en priorité — couvert par la licence, sans contrainte de résolveur. Les serveurs tiers (multi.surbl.org) sont un complément et exigent un résolveur dédié.
• Section DNSBL : ☑ activer → [Edit] la liste → ajouter zen.spamhaus.org. > Rappel : Spamhaus et SURBL refusent les requêtes venant des grands résolveurs publics. Sans résolveur dédié ou interne, ces vérifications ne matchent jamais — le trou est totalement silencieux. Tester avec execute nslookup 2.0.0.127.zen.spamhaus.org.
• Section Banned word / Safelist word : vérifier que ces listes sont vides ou maîtrisées. Une liste de mots sûrs mal maîtrisée est un bypass.
• Section Dictionary : ☑ activer si vous utilisez des dictionnaires pondérés → sélectionner le profil ou le groupe → fixer le score minimum → action. Voir la fiche francophone pour le corpus et les poids.
• Section Image spam : ☑ activer. C’est aussi le prérequis du scan des QR codes (étape 15).
• Section Bayesian : ☑ activer en complément, jamais comme moteur principal, et jamais avec une action de rejet. Voir la fiche francophone pour l’entraînement.
• Section Newsletter / Suspicious newsletter :
• ☑ Suspicious newsletter → action Quarantine ;
• ☑ Newsletter → action Tag ([NEWSLETTER]) ou quarantaine personnelle selon votre politique.
• Section SPF / DKIM / DMARC / ARC :
• ☑ Enable SPF checking — Fail → Reject (ou Quarantine les deux premières semaines) ; SoftFail → Tag ; None / Neutral / PermError → None, aucun blocage ;
• ☑ Enable DKIM checking — signature invalide → Tag, jamais de rejet sec : les listes de diffusion cassent régulièrement les signatures ;
• ☑ Enable DMARC checking — ☑ appliquer la politique publiée par l’expéditeur (reject → Reject, quarantine → quarantaine système, none → Tag) ;
• ☑ ARC verification — préserve les messages ayant transité par des listes ou relais légitimes.
• Section Scan Option — les deux contrôles décisifs :
• ☐ Bypass scan on SMTP authentication : décocher. Activée par défaut en sortie d’usine.
• ☐ Apply default action without scan upon policy match : décocher.
• ☑ Scan PDF attachment : activer (corps vide + PDF porteur du contenu est une technique d’évasion courante ; c’est aussi le prérequis du scan QR dans les PDF).
• Max message size to scan : laisser la valeur par défaut, ou ≥ 10 Mo.
• [OK].

MO-08bis — Activer le scan des QR codes (quishing) (20 min)

Objectif : couvrir le vecteur qui contourne toute analyse d’URL textuelle. Un QR code ne contient aucune URL dans le corps du message, seulement une image.

• Security > Antispam preferences (ou Configuring antispam preferences selon la version) : activer Attachment image. C’est le prérequis — sans lui, rien ne sera scanné.
• Profile > AntiSpam > AntiSpam > AS_ENTRANT_DURCI → section Scan Option → ☑ Scan PDF attachment.
• 8.0 : le scan des QR codes s’étend aux PDF et aux archives contenant des PDF. Les réglages associés (activation du scan QR dans les PDF, nombre maximal de pages analysées) se font en CLI, sous config antispam settings.
• L’URL extraite du QR code est ensuite soumise aux catégories d’URL et aux threat feeds : la chaîne du MO-08 étape 3 s’applique.
• Mesurer la charge : le scan d’images est le traitement le plus gourmand du produit. Relever get system performance avant et après, et plafonner le nombre de pages PDF analysées si la latence augmente.

MO-09 — Profil d’action AntiSpam + quarantaine (30 min)

A. Profil d’action

• Profile > AntiSpam > Action → [New] → nom : AS_ACTION_DURCI.
• Action principale : Quarantine → Personal quarantine (quarantaine individuelle avec digest). Ne pas choisir « Tag subject » comme action principale : c’est précisément ce qui donne l’impression de passoire, le message arrivant malgré tout en boîte.
• ☑ Insert header : utiliser un préfixe propre à votre organisation, par exemple X-ORG-Spam-Verdict: quarantine. > Ne pas utiliser X-FEAS-* : ce préfixe est réservé à FortiMail (X-FEAS-Spam-outbreak, etc.). Une collision rend l’analyse post-incident ambiguë.
• ☐ Notify sender : laisser décoché — notifier l’expéditeur génère du backscatter.
• [Create].
• Créer de la même façon les profils complémentaires :
• ACT_REJECT — action Reject, pour les verdicts de très haute confiance ;
• ACT_DISCARD — action Discard, à préférer sur les verdicts de type signature : un rejet 5xx confirme au spammeur que l’adresse existe ;
• ACT_TAG — sujet préfixé [SUSPECT], pour les phases de mesure ;
• ACT_TAG_NEWS — sujet préfixé [NEWSLETTER].

B. Digest de quarantaine

• Security > Quarantine > Quarantine Report :
• Schedule : deux envois par jour, par exemple 07:30 et 13:30 ;
• ☑ liens Release ;
• ☐ décocher Safelist sender — recommandé au moins pendant toute la phase de durcissement, pour garder la maîtrise des listes ;
• [Apply].
• Security > Quarantine > System Quarantine / Personal Quarantine → Setting :
• Rétention : 21 jours ;
• vérifier le quota disque et l’action en cas de saturation.
• 8.0 — Security > Quarantine > Quarantine Control : ☑ activer le re-scan à la libération (contenu et DLP). Sans cela, un utilisateur qui libère un message libère aussi sa pièce jointe sans nouvelle analyse.
• 8.0 — Monitor > Quarantine affiche désormais le décompte des messages libérés et non libérés : c’est un bon indicateur de faux positifs, à croiser avec votre échantillonnage manuel.

MO-10 — Assembler les politiques (45 min)

A. IP Policies

• Policy > IP Policies.
• Vérifier ou créer, dans cet ordre (utiliser [Move] pour réordonner) :
• #1 — Internes sortants : Source = IP et plages de vos serveurs de messagerie et relais applicatifs → Session profile = SESSION_SORTANT ;
• #2 — Internet entrant : Source = 0.0.0.0/0 → Session profile = SESSION_ENTRANT_DURCI.
• Sur chaque IP policy : ouvrir et vérifier la case « Take precedence over recipient based policy match ». La décocher sauf besoin documenté — sinon elle écrase les profils AntiSpam de vos recipient policies, trou classique et difficile à diagnostiquer.
• [OK].

B. Recipient Policies entrantes

• Policy > Recipient Policies → onglet Inbound.
• Pour chaque domaine protégé, éditer ou créer la politique *@domaine.fr :
• AntiSpam : AS_ENTRANT_DURCI ;
• AntiVirus : votre profil AV durci ;
• Content : CONTENT_ENTRANT (MO-11) ;
• Action : AS_ACTION_DURCI si le champ est au niveau politique ;
• ☑ politique Enabled.
• 8.0 — pour traiter un faux positif récurrent, utiliser le sender exclusion disponible dans la recipient policy plutôt qu’une safe list globale : l’exception ne porte alors que sur cette politique.
• Vérifier qu’aucune politique au-dessus — évaluation de haut en bas, premier match gagnant — ne matcherait le même trafic avec des profils vides. Au besoin, [Move] la politique principale vers le haut, sous les seules politiques d’exception légitimes.
• Onglet Outbound : vérifier que les politiques sortantes portent aussi un profil AntiSpam. C’est ainsi qu’on détecte un compte interne compromis avant que l’IP publique ne soit listée.

MO-11 — Profil de contenu : pièces jointes dangereuses (25 min)

• Profile > Content > Content → [New] → nom : CONTENT_ENTRANT.
• Section Attachment filter / File filter :
• [New] règle → extensions : exe, js, vbs, vbe, scr, bat, cmd, ps1, hta, lnk, iso, img, jar, cab, msi, reg, chm, wsf → Action : Replace with message ou System quarantine ;
• ☑ analyse des archives, profondeur 2 ; archives chiffrées ou non analysables → System quarantine.
• 8.0 — pièces jointes protégées par mot de passe : la fonction Password-protected Attachment Scan permet de demander le mot de passe à l’utilisateur avant scan, plutôt que de bloquer ou de laisser passer en aveugle.
• Section URL / Click protection (si licencié) : ☑ URL rewrite / click protection. Indispensable contre les URL « armées » après livraison — propres au moment du scan, malveillantes une heure plus tard. Prévenir les utilisateurs du changement d’apparence des liens.
• Section CDR / Content disarm (si licencié, Level 2) : ☑ désarmement des documents Office et PDF actifs. 8.0 : le CDR peut en outre retirer les métadonnées des fichiers Office et les contenus HTML cachés — textes et images transparents, minuscules ou dissimulés. Technique d’évasion très courante, à activer.
• Section Image classification (si disponible) : profils de classification pour les contenus visuels indésirables.
• [Create], puis association dans les recipient policies (MO-10.B).

MO-12 — DKIM sortant pour vos domaines (20 min par domaine)

• System > Mail Setting > Domains → éditer le domaine → Advanced Settings > DKIM Setting → [New] :
• Selector : par exemple fm2026 → [Create] ;
• sélectionner la ligne créée → récupérer l’enregistrement DNS TXT (fm2026._domainkey.votredomaine.fr).
• Publier cet enregistrement TXT dans votre zone DNS publique.
• Une fois propagé, revenir sur la ligne du sélecteur → Status : Active + ☑ Sign outgoing messages.
• Test : s’envoyer un message vers une boîte externe → afficher l’original → vérifier DKIM: PASS.

MO-13 — Anti-usurpation : vos domaines, VIP, cousin domains (45 min)

A. Bloquer le spoofing de vos domaines depuis Internet

• Pré-requis : SPF publié, DMARC publié, DMARC checking activé (MO-08 étape 15). Une fois DMARC passé en p=quarantine ou p=reject, le spoofing exact est traité automatiquement.
• En complément immédiat, pendant la phase d’observation DMARC :
• 8.0, licence advanced management — la solution propre : dans Policy > Access Control > Receiving, une règle peut matcher l’expéditeur sur le From: d’en-tête et non plus seulement sur l’enveloppe. C’est ce qui permet de bloquer l’usurpation affichée, celle que voit réellement l’utilisateur. Le paramètre se règle en CLI (set sender-option header-from) ; voir le MO CLI.
• Versions antérieures : placer d’abord une règle « source = vos IP internes + sender interne → RECEIVE ou RELAY », puis en dessous une règle « sender *@votredomaine.fr depuis n’importe où → REJECT ». Positionner l’ordre avec [Move].
• ⚠️ Avant activation : lister les émetteurs SaaS légitimes qui envoient en votre nom — paie, marketing, ticketing, signature électronique — et les intégrer à votre SPF/DKIM, ou créer pour leurs IP une règle RECEIVE au-dessus. C’est la cause n°1 d’incident sur cette mesure.
• Test : depuis un outil externe d’envoi SMTP, envoyer un message From: [email protected] vers une boîte interne → il doit être rejeté.

B. Impersonation (display names des VIP)

• Profile > AntiSpam > Impersonation → [New] :
• Nom : IMPERSONATION_VIP ;
• [New entry] pour chaque VIP : Display name pattern — Prénom Nom, et les variantes P. Nom, NOM Prénom → Email : adresse légitime ;
• couvrir : direction, DAF, RH, comptabilité, IT.
• Mode dynamique (si licencié) : il exige d’activer au préalable le Mail Statistics Service, désactivé par défaut, en CLI. Sans cette activation, la fonction ne produit rien — c’est la raison la plus fréquente pour laquelle elle « ne marche pas ». Une fois le service actif, le bouton Impersonation Lookup permet d’interroger la base dynamique : saisir une adresse, obtenir le display name associé.
• Association : faite au MO-08 étape 6.
• Test : envoyer depuis une boîte externe un message portant le display name du dirigeant et une adresse gmail → doit partir en quarantaine.

C. Cousin domains

• Profile > AntiSpam > Cousin domain → [New] → COUSIN_DOMAINES.
• Déclarer vos domaines, et si l’option le permet ceux de vos banques et partenaires critiques.
• Options de scan : header + body.
• Association : faite au MO-08 étape 6.

MO-13bis — Weighted analysis : le scoring pondéré (30 min + 2 semaines de mesure)

Objectif : attraper les messages qui ne déclenchent aucun signal fort isolé mais en cumulent plusieurs faibles. C’est le cas de la quasi-totalité du phishing bien rédigé.

• Profile > AntiSpam > Weighted analysis → [New] → nom : WA_ANALYSE_PONDEREE.
• Le profil attribue un poids à plusieurs comportements suspects : cousin domains, caractères suspects, sender alignment, mots-clés d’action, catégories d’URL, et déclenche le verdict quand le total dépasse un seuil.
• Réglage recommandé :
• augmenter le poids de cousin domain, suspicious characters et URL categories — les marqueurs les plus fiables ;
• laisser bas celui des action keywords : le courrier commercial légitime est prescriptif par nature, le risque de faux positif y est élevé ;
• fixer le seuil global de façon à exiger au moins deux signaux distincts. Ne jamais déclencher sur un seul.
• Association : MO-08 étape 6, en action tag pendant deux semaines.
• Mesure : relevé hebdomadaire dans Monitor > Log > AntiSpam des déclenchements, par signal. Ajuster les poids en fonction, puis basculer en quarantaine.

Les suspicious characters génèrent des faux positifs sur du courrier légitime contenant des alphabets mixtes ou des caractères accentués inhabituels — noms propres étrangers, citations. Mesurer avant de durcir.

MO-14 — Journalisation, alertes, rapports (30 min)

• Log & Report > Log Setting > Local : ☑ AntiSpam, ☑ History, ☑ Event, ☑ AntiVirus — niveau Information.
• Log & Report > Log Setting > Remote → [New] : IP du SIEM ou syslog, ou FortiAnalyzer via son onglet dédié → ☑ mêmes catégories → [Create]. > 8.0 : le statut de délivrance des messages est stocké et mis à jour sur FortiAnalyzer, avec un nouvel état Delivering et le motif d’échec en cas de non-délivrance. Utile pour distinguer un message bloqué d’un message simplement en attente.
• Log & Report > Alert Email :
• Configuration : SMTP local, destinataire = boîte d’équipe, jamais une personne seule ;
• Categories : ☑ License expiry, ☑ FortiGuard update failure, ☑ Disk quota, ☑ Deferred queue threshold, ☑ HA events, ☑ Critical events → [Apply].
• Log & Report > Report → [New] : rapport hebdomadaire RAPPORT_AS_HEBDO — sections Spam by technique, Top spam senders, Mail statistics ; planification lundi 07:00 ; destinataire : l’équipe → [Create].
• FortiView : prendre l’habitude de consulter Threat statistics, Outbreak statistics et TLS connection statistics (8.0) — c’est le premier écran à ouvrir quand quelque chose semble anormal.

MO-15 — Durcissement de l’administration (30 min)

• System > Administrator > Administrator, pour chaque compte :
• Trusted Hosts : uniquement les IP ou sous-réseaux d’administration ; 0.0.0.0/0 interdit ;
• comptes nominatifs ; supprimer ou désactiver les comptes génériques inutilisés ; profil de droits minimal (System > Administrator > Admin Profile).
• MFA — obligatoire sur tous les comptes d’administration. Options : Local + FortiToken, RADIUS (le RADIUS sécurisé sur TLS est supporté en 8.0), SAML vers votre IdP, ou FortiIdentity Cloud (8.0, anciennement FortiToken Cloud).
• System > Network > Interface : éditer l’interface exposée à Internet → Access : décocher ☐ HTTP, ☐ SSH, ☐ PING. Ne laisser que SMTP et ce qui est strictement nécessaire (webmail et quarantaine en HTTPS si publiés). L’accès à la GUI d’administration ne doit être coché que sur l’interface du VLAN d’administration.
• System > Configuration > Options : ☑ HTTPS only ; timeout de session admin 10 min ; bannière de connexion légale si requise.
• SNMP (si utilisé) — System > Configuration > SNMP > User : SNMPv3 avec authentification SHA-256 ou supérieure et chiffrement AES-256.
• 8.0 — SAML : le SP du webmail peut être séparé de celui de la GUI d’administration côté IdP. À utiliser si vos populations d’accès diffèrent.
• Maintenance > Configuration > Backup : [Backup] de la configuration complète, stockée hors de l’appliance. À refaire avant et après chaque changement majeur, et tester au moins une restauration par an — une sauvegarde jamais restaurée n’est pas une sauvegarde.

MO-16 — Tests de validation de bout en bout (30 min)

Pour chaque test, noter le Policy ID dans le log History. Si ce n’est pas la politique attendue qui a traité le message, retourner au MO-10 et corriger l’ordre.

MO-17 — Traiter un spam qui passe encore (10 min par cas)

• Récupérer le message au format .eml avec en-têtes complets.
• Monitor > Log > History → filtrer : période, puis expéditeur, destinataire ou sujet.
• Sur la ligne du message → icône Cross Search : lire les trois volets (session / antispam / delivery).
• Arbre de décision :
• Policy ID inattendu, ou profils vides → corriger au MO-10 ;
• Mention d’un bypass → identifier la cause exacte : safe list, règle ACL SAFE, Bypass scan on SMTP authentication, Apply default action without scan, domaine exempté → corriger (MO-02) ;
• Aucun verdict FortiGuard sur l’ensemble des logs récents → connectivité rating (MO-01) ;
• Une seule IP source sur tout le trafic → l’IP client est masquée (MO-01bis) ;
• Scanné mais jugé propre → soumettre le .eml sur le portail FortiGuard, puis renforcer la technique concernée : ajouter le domaine en URL rating override (MO-18bis), ajuster les poids du weighted analysis (MO-13bis), enrichir le dictionnaire, ou compléter le profil d’impersonation.
• Consigner le cas — date, cause, action — dans le registre. C’est ce registre qui pilote le tuning hebdomadaire.

MO-18bis — Threat feeds et notation locale d’URL (45 min une fois)

Objectif : disposer d’un canal de blocage rapide et d’un mécanisme propre pour neutraliser un domaine précis.

A. Threat feeds

FortiMail consomme des listes externes de plusieurs types. Deux nous intéressent : - IP — s’associe dans la section FortiGuard > Threat feed du profil AntiSpam ; - URL filter (catégorie FortiGuard) — un URI par ligne, encodage IDN et UTF-8 supportés, wildcards * acceptés en début ou fin de chaîne. Le flux est rattaché à une catégorie d’URL, elle-même sélectionnée dans la section FortiGuard du profil.

• Héberger sur un serveur web interne deux fichiers texte maintenus par votre équipe sécurité : iocs-ip.txt et iocs-url.txt.
• Security > Threat Feed → [New] : nom, type, URI du flux, refresh 5 à 10 minutes → [Create].
• Associer dans AS_ENTRANT_DURCI (MO-08 étape 3).

Bénéfice : bloquer un indicateur revient ensuite à ajouter une ligne dans un fichier versionné. Plus de modification de configuration sous pression, plus de règle orpheline oubliée, et un historique exploitable.

B. Notation locale d’URL

• Security > URL Filter > Custom URL rating categories : créer vos propres catégories thématiques.
• Security > URL Filter > URL rating overrides → [New] : y verser les domaines identifiés lors de l’analyse de vos faux négatifs (MO-17), en les assignant à une catégorie bloquée.
• Vérifier que la catégorie est bien sélectionnée dans la section FortiGuard > URL Category du profil AntiSpam.

Pourquoi préférer cela à un dictionnaire. Un motif *domaine-suspect.fr* matcherait aussi une discussion légitime à propos de ce domaine — typiquement vos propres alertes internes de sécurité, qui finiraient en quarantaine. L’override d’URL ne porte que sur les liens réellement présents.

Pour la procédure de crise — vague de spam en cours ou émission sortante — voir le document MO-18 — Réponse à un spam actif. Pour les checklists de conformité, voir les sections 9.x de la fiche de durcissement.