FortiMail : guide complet de durcissement antispam

FortiMail est la passerelle de sécurité e-mail de Fortinet, déployée dans les environnements les plus exigeants pour filtrer le spam, bloquer le phishing et prévenir les fuites de données par messagerie. Sa richesse fonctionnelle est un atout, mais elle exige une configuration rigoureuse : laisser les réglages d'usine actifs expose l'organisation à des taux de faux négatifs élevés et à des campagnes de phishing ciblées. Ce guide présente une procédure de durcissement en 9 phases, applicable aux versions FortiMail 7.4, 7.6 et 8.0, dans les trois modes de déploiement Gateway, Transparent et Server. Chaque phase est documentée avec les paramètres CLI et GUI recommandés, les seuils de scoring à adapter à votre contexte, et les métriques de supervision à mettre en place. L'objectif est d'atteindre un taux de détection supérieur à 99 % tout en maintenant les faux positifs sous 0,1 %, conformément aux exigences des référentiels ISO 27001 et ANSSI.

FICHE DE DURCISSEMENT — FortiMail : améliorer le filtrage antispam

Contexte : « les spams passent un peu trop » — Procédure complète de remédiation et de durcissement

Applicable : FortiMail (appliance, VM, Cloud) — versions 7.4 / 7.6 / 8.0. Modes concernés : Gateway, Transparent, Server. Les spécificités sont signalées le cas échéant.

⚠️ FortiMail 8.0 a refondu le framework de la GUI d’administration. Les chemins de menu indiqués ici sont établis sur 7.6 ; sur 8.0 les libellés sont conservés mais l’agencement diffère. Vérifiez sur votre version avant d’appliquer.

0. Principe directeur

FortiMail est très efficace à condition que toutes ses couches soient activées et correctement ordonnées. Dans la grande majorité des cas de « passoire à spam », l’audit révèle une ou plusieurs des causes suivantes :

• Licence / connectivité FortiGuard AntiSpam défaillante (le moteur principal ne répond pas → tout passe).
• Profil AntiSpam incomplet : seules 2-3 techniques activées sur la vingtaine disponible.
• Filtrage de session désactivé ou contourné (pas de sender reputation, pas de contrôle SMTP, exemptions trop larges).
• Safe lists / exemptions trop permissives (domaine entier en liste blanche, * quelque part, propre domaine whitelisté → spoofing direct).
• Politiques mal ordonnées : une IP policy ou recipient policy « catch-all » sans profil antispam matche avant la bonne politique.
• Vérification des destinataires absente → backscatter + dictionnaire → réputation dégradée.
• Flux qui ne passe pas réellement par le FortiMail (MX secondaire direct vers Exchange/M365, connecteur ouvert, port 25 ouvert sur le serveur interne).
• Actions trop laxistes : spam détecté mais action = « tag subject » et l’utilisateur voit quand même le mail.
• L’IP réelle du client SMTP est masquée par un load-balancer ou un proxy non transparent placé devant le FortiMail → la sender reputation et la FortiGuard IP reputation notent le load-balancer. Deux couches entières neutralisées, sans aucun message d’erreur.
• Bypass scan on SMTP authentication laissé à sa valeur par défaut, qui est activée : tout client authentifié échappe au filtrage.

La procédure ci-dessous traite ces causes dans l’ordre logique : diagnostic → fondations → couche connexion (session) → couche contenu (antispam) → authentification → politiques → boucle d’amélioration continue.

1. PHASE 1 — Diagnostic initial (avant de toucher quoi que ce soit)

1.1 Vérifier que le flux passe bien par le FortiMail

• Vérifier les enregistrements MX publics du/des domaines protégés :

dig MX votredomaine.fr +short

• → Tous les MX doivent pointer vers le FortiMail (ou l’IP publique NATée vers lui). Supprimer tout MX de secours pointant directement sur le serveur de messagerie interne (technique classique des spammeurs : viser le MX de plus faible priorité).
• Sur le firewall : vérifier qu’aucune règle n’autorise le TCP/25 entrant directement vers Exchange ou le serveur interne en contournant le FortiMail.
• Pour M365 / Google Workspace, deux approches :
• Verrouillage du tenant (mode SMTP) : connecteurs et règles de flux forçant le passage par FortiMail, plus une règle de transport rejetant tout mail entrant ne provenant pas des IP du FortiMail.
• Mode API / Microsoft 365 Inline Scan (7.6+ / 8.0) : FortiMail se branche via l’API Microsoft ou Google, ou via des connecteurs Exchange Online routant les flux interne, entrant et sortant. C’est la seule approche qui voit le trafic interne → interne, invisible en mode gateway. Le mode API permet en outre d’agir sur des messages déjà délivrés (recherche et remédiation a posteriori) et de scanner les boîtes partagées dont la connexion est bloquée.
• Prendre 5 spams reçus récemment, ouvrir les en-têtes complets, et chercher la ligne Received: portant le hostname du FortiMail. C’est le seul marqueur fiable : un mail passé par FortiMail et jugé propre peut ne porter aucun en-tête X-FEAS-*, ceux-ci n’étant insérés que si une action le prévoit. Corréler ensuite avec Monitor > Log > History (recherche par Message-ID). Si le mail n’apparaît pas dans les logs, il n’est pas passé par le FortiMail → problème de flux, pas de filtrage.

1.2 Vérifier la licence et la connectivité FortiGuard AntiSpam (CRITIQUE)

C’est la cause n°1 des passoires. Sans FortiGuard AntiSpam fonctionnel, FortiMail perd ses moteurs de réputation IP, de catégorisation d’URL, de signatures spam et d’outbreak protection.

GUI : 1. Dashboard > Status → vérifier l’état des licences AntiSpam et AntiVirus (vertes, non expirées). 2. Maintenance > FortiGuard > Update : vérifier la date de dernière mise à jour des définitions ; activer Scheduled update (toutes les heures) et Push update si disponible. 3. Maintenance > FortiGuard > AntiSpam : vérifier que le service de requête (rating queries) est joignable.

CLI :

diagnose debug rating                     # état des serveurs de rating FortiGuard
diagnose debug application updated -1     # debug du processus de mise à jour
execute ping service.fortiguard.net
execute nslookup fortiguard.net

• Les requêtes antispam FortiGuard utilisent, selon la configuration, UDP/53, UDP/8888 ou HTTPS/443. Vérifier sur le firewall de sortie que ces flux sont autorisés depuis l’IP du FortiMail. Le détail exact des ports figure dans l’annexe Port numbers du guide d’administration de votre version.
• En cas de doute, basculer le protocole de requête :

config system fortiguard antispam
    set port 443                    # tester 443, puis 8888, puis 53
end

• Symptôme typique de FortiGuard cassé : dans les logs AntiSpam (Monitor > Log > AntiSpam), aucune détection de type « FortiGuard » ; uniquement des verdicts heuristiques, ou rien.

1.3 Vérifier que l’IP du client SMTP est bien visible

Contrôle rapide, effet massif. Si un load-balancer, un reverse-proxy ou un dispositif de protection DDoS est placé devant le FortiMail sans être transparent, toutes les décisions basées sur l’IP source portent sur cet équipement.

• Monitor > Reputation > Sender Reputation : si une seule IP — la vôtre, ou celle du LB — concentre l’essentiel du trafic, le diagnostic est fait.
• Correction (8.0) : System > Configuration > Web Service → activer l’identification de l’IP client d’origine via en-tête HTTP X-Forwarded-For.
• Sinon : reconfigurer le LB en mode transparent (préservation de l’IP source), ou déplacer le FortiMail en frontal.

1.4 Établir une base de mesure

• Monitor > Log > History : exporter les statistiques sur 7 jours (mails reçus, détectés spam, techniques ayant détecté).
• Log & Report > Report : générer un rapport « Spam by hour / by technique / top senders ».
• Collecter 10-20 spams passés (en-têtes complets, format .eml) — ils serviront à l’analyse §7 et à la soumission FortiGuard.
• Noter le taux actuel de faux négatifs pour comparaison à J+7 et J+30.
• Constituer en parallèle un échantillon de 50 messages quarantainés pris au hasard, relus manuellement : c’est votre mesure de faux positifs de référence. Le nombre de demandes de libération sous-estime structurellement le taux réel, les utilisateurs ne réclamant pas ce qu’ils ignorent avoir reçu.

1.5 Auditer les exemptions existantes (chasse aux trous)

• System > Mail Setting > Domains : pour chaque domaine protégé, vérifier qu’aucune option de bypass antispam n’est activée.
• Listes globales : Security > Block/Safe List > System — passer en revue chaque entrée Safe List :
• Supprimer toute entrée en wildcard large (*@*.com, *.fr, *.edu, TLD entiers).
• Supprimer toute entrée correspondant à vos propres domaines protégés. Une safe list court-circuite le scan : n’importe quel spoofing de votre domaine passe alors sans analyse. C’est aussi ce qui exempte les messages de la protection outbreak.
• Supprimer les grands fournisseurs génériques (*@gmail.com, *@outlook.com…) : les spammeurs les utilisent massivement.
• Idem au niveau domaine (Security > Block/Safe List > Domain) et vérifier les safe lists personnelles utilisateurs (Security > Block/Safe List > Personal). En 8.0, plutôt que de les supprimer, on peut les encadrer : une limite de taille des listes personnelles est configurable, avec affichage de l’usage (licence advanced management).
• Policy > Access Control > Receiving : repérer toute règle Action = RELAY / SAFE / SAFE & RELAY trop large (source 0.0.0.0/0, domaines expéditeurs génériques). Une règle SAFE équivaut à un bypass antispam, et exempte également de l’outbreak protection.
• Policy > IP Policies et Policy > Recipient Policies : repérer toute politique sans profil AntiSpam associé, ou renvoyant aux réglages du domaine alors que le domaine n’a rien de configuré.
• Dans chaque profil AntiSpam, section Scan Option : vérifier deux cases.
• ☐ Apply default action without scan upon policy match doit être décochée. Si elle est cochée, le message subit l’action par défaut sans aucun scan — bypass total et silencieux.
• ☐ Bypass scan on SMTP authentication doit être décochée sur les profils entrants. Elle est activée par défaut en sortie d’usine. Un compte interne compromis qui s’authentifie échappe sinon à tout filtrage.
• En 8.0, vérifier config antispam setting → safelist-check-reply-to. Cette option permet d’utiliser le Reply-To: avec les safe lists : elle élargit la surface d’évasion et doit rester désactivée en configuration durcie.

Règle d’or : une safe list ne doit contenir que des adresses complètes, documentées, revues trimestriellement. Pour les exceptions ciblées, préférer en 8.0 le sender exclusion des recipient policies, qui n’exempte que la politique concernée.

2. PHASE 2 — Fondations réseau et DNS

2.1 DNS et identité SMTP du FortiMail

Un FortiMail mal identifié se fait lui-même blacklister et évalue mal les autres.

• PTR (reverse DNS) : l’IP publique d’émission doit résoudre vers le FQDN du FortiMail, et ce FQDN doit résoudre vers l’IP (FCrDNS). À faire auprès de l’opérateur ou de l’hébergeur.
• Host name / Local domain : System > Mail Setting > Settings → le FQDN annoncé en HELO/EHLO doit correspondre au PTR.
• Serveurs DNS du FortiMail : System > Network > DNS → utiliser des résolveurs fiables, rapides et dédiés. Un DNS lent casse les vérifications DNSBL/SURBL/SPF/DKIM : les timeouts rendent les contrôles silencieusement inopérants.
• Test DNSBL : execute nslookup 2.0.0.127.zen.spamhaus.org doit répondre.
• Spamhaus refuse les requêtes provenant des grands résolveurs publics (8.8.8.8, 1.1.1.1). Si vous utilisez zen.spamhaus.org, un résolveur dédié ou interne est obligatoire, sinon la vérification ne matche jamais.
• SURBL applique la même politique : les serveurs publics bloquent les résolveurs à fort volume, et une réponse 127.0.0.1 signifie « accès bloqué », et non « domaine listé ». Le SURBL FortiGuard intégré, couvert par votre licence, n’a pas cette contrainte — commencez par lui.
• NTP : System > Configuration > Time → horloge synchronisée, sur deux sources (indispensable pour DKIM/DMARC, greylisting, corrélation de logs).

2.2 Publier votre propre SPF / DKIM / DMARC (sortant)

Ce n’est pas du filtrage entrant, mais cela conditionne la crédibilité de vos contrôles entrants et vous protège du spoofing de votre domaine vu par des tiers.

⚠️ Avant toute chose : inventoriez les émetteurs SaaS qui envoient « en votre nom » — paie, marketing, ticketing, signature électronique, CRM, monitoring. Publier un SPF en -all sans cet inventaire coupe ces services du jour au lendemain. C’est l’erreur la plus fréquente et la plus visible.

• SPF : commencer par v=spf1 ip4:<IP_publique_FortiMail> include:<saas1> include:<saas2> ~all. Rester en ~all pendant toute la phase d’inventaire, puis basculer en -all une fois la liste stabilisée.
• DKIM : générer la clé sur FortiMail — System > Mail Setting > Domains > [domaine] > Advanced Settings > DKIM Setting → créer un sélecteur, publier l’enregistrement TXT généré, puis activer la signature sortante.
• DMARC : publier d’abord en observation.

_dmarc.votredomaine.fr TXT "v=DMARC1; p=none; rua=mailto:[email protected]; fo=1"

• Exploiter les rapports pendant 4 à 6 semaines via Monitor > DMARC (statistiques de rapports DMARC et SPF intégrées à la GUI), identifier les émetteurs légitimes non alignés, les corriger, puis seulement passer à p=quarantine, et enfin p=reject.

3. PHASE 3 — Durcissement de la couche CONNEXION (Session Profiles)

C’est la couche la plus rentable : elle rejette la majorité du spam avant même l’analyse de contenu, à coût CPU quasi nul. Beaucoup d’installations « passoires » n’ont tout simplement aucun session profile appliqué aux IP policies entrantes.

Emplacement : Profile > Session > Session → créer un profil SESSION_ENTRANT_DURCI, puis l’associer aux IP Policies entrantes (§6).

3.1 Sender Reputation

Le FortiMail note chaque IP cliente selon son comportement : spams envoyés, virus, destinataires invalides, échecs d’authentification. Au-delà des seuils, les sessions sont ralenties, temporairement refusées, puis rejetées au niveau connexion.

Méthode de réglage. Ne reprenez pas des seuils de catalogue. Activez d’abord la fonction en observation pendant une semaine, puis consultez Monitor > Reputation > Sender Reputation pour lire la distribution réelle des scores sur votre trafic, et placez les seuils en conséquence.

Valeurs de départ raisonnables, à ajuster après mesure : - ☑ Enable sender reputation checking - Throttle client at : 50 - Temporarily fail (4xx) at : 70 - Reject (5xx) at : 80 - Aucune exemption globale ; exempter uniquement les relais internes connus, via une IP policy dédiée et non dans ce profil.

Bénéfice direct : bloque les attaques par dictionnaire (DHA) et empêche les spammeurs de déduire vos adresses valides à partir des réponses « User Unknown ». Sender reputation et vérification des destinataires (§3.7) se complètent — l’une sans l’autre laisse le trou ouvert.

3.2 Contrôles de connexion et HELO/EHLO

Connection Settings / SMTP Limits : - ☑ Prevent open relay (voir aussi §5.1) - Connexions par client / 30 min : ~60 (à ajuster selon volumétrie) - Messages par session : 10-20 - Destinataires par message : 50 (entrant) - Idle timeout : 30-60 s ; ☑ rejeter les commandes émises avant HELO - ☑ Reject if client does not issue HELO/EHLO - ☑ Reject if HELO/EHLO argument is not a FQDN — Level 2 : peut générer des FP avec des émetteurs mal configurés ; commencer en observation.

Sender Validation : - ☑ Reject if reverse DNS lookup fails (no PTR) — Level 2 : très efficace contre les botnets, mais quelques PME légitimes n’ont pas de PTR. Commencer en temporary fail (4xx) : un émetteur légitime réessaiera, un botnet non. - ☑ Vérifier que le domaine du MAIL FROM possède un enregistrement A ou MX valide.

3.3 STARTTLS et restrictions d’authentification

• ☑ Autoriser STARTTLS entrant en opportuniste ; ne pas l’exiger en entrant (perte de mails).
• Interdire l’authentification SMTP sur le flux entrant public. La SMTP AUTH ne doit être permise que sur le flux de soumission (587 / SMTPS) des utilisateurs internes. Un compte compromis plus une AUTH ouverte sur le 25 public équivalent à un relais de spam sortant.
• Profil ENTRANT : ne pas autoriser la SMTP AUTH.
• Profil SORTANT / SOUMISSION distinct, avec AUTH sur TLS et limites d’envoi par utilisateur (§3.5).

3.4 DNSBL et SURBL

• SURBL FortiGuard (section FortiGuard du profil AntiSpam) : à activer en premier, il est couvert par la licence et n’a pas de contrainte de résolveur.
• DNSBL tiers : zen.spamhaus.org — sous réserve du résolveur dédié (§2.1). Éventuellement bl.spamcop.net.
• SURBL tiers : multi.surbl.org — même réserve de résolveur.
• Au niveau session, un hit DNSBL peut rejeter la connexion directement, ce qui économise massivement les ressources. Dans le profil AntiSpam, il produit un verdict spam. Les deux sont complémentaires ; au minimum l’un des deux doit être actif.

3.5 Greylisting

Security > Other > Greylist, plus activation dans le session profile.

• TTL initial ~20-30 min, rétention ~30 jours.
• Exempter : les émetteurs de codes OTP / MFA par mail, les partenaires critiques sensibles au délai. M365 et Google réessaient correctement et n’ont généralement pas besoin d’exemption.
• Effet de bord assumé : retard de quelques minutes sur le premier mail de tout nouvel expéditeur.

À classer en Level 2, pas en quick win. Sur un flux déjà couvert par sender reputation et FortiGuard IP reputation, le greylisting apporte peu : les botnets modernes réessaient. Il reste utile contre les émetteurs les plus rustiques, mais son coût en latence perçue est réel et immédiat, alors que son gain est marginal et invisible.

3.6 Protection contre le backscatter : Bounce Verification (BATV)

Security > Other > Bounce Verification : 1. Créer une clé (chaîne aléatoire d’au moins 16 caractères) et l’activer. 2. Sélectionner Use antispam profile settings pour l’action de vérification. 3. Désactiver « Bypass bounce verification » sur chaque domaine (Mail Settings > Domains) et « Bypass bounce verification check » dans chaque session profile. 4. Condition impérative : tout le flux sortant ET entrant passe par le FortiMail, sinon les DSN légitimes de vos propres envois seront rejetés.

3.7 Vérification des destinataires

Sans elle, le FortiMail accepte tout puis génère des NDR : il spamme lui-même (backscatter) et se fait blacklister.

System > Mail Setting > Domains > [domaine] > Recipient Address Verification - Option 1 (recommandée) : vérification LDAP. Créer un profil LDAP (Profile > LDAP) pointant vers l’AD — compte de service en lecture seule, base DN, filtre (|(mail=$m)(proxyAddresses=smtp:$m)) —, tester la requête, puis sélectionner « Use LDAP server to verify ». - Option 2 : vérification SMTP (callout vers le serveur interne). Nécessite que le serveur interne rejette les inconnus au RCPT : désactiver le catch-all côté Exchange. - Action pour destinataire invalide : rejet en session (550 au RCPT TO) — jamais accepter puis renvoyer un bounce.

3.8 Sender Rewriting Scheme (SRS)

Security > Other > Sender Rewriting Scheme.

Indispensable dès lors que vous faites suivre du courrier vers un domaine externe (redirections, alias sortants, listes). Sans SRS, le MAIL FROM d’origine est conservé lors du réacheminement : le SPF échoue chez le destinataire final, qui classe vos redirections en spam. Le SRS réécrit l’enveloppe avec votre domaine, ce qui rétablit l’alignement.

4. PHASE 4 — Durcissement de la couche CONTENU (Profil AntiSpam)

Emplacement : Profile > AntiSpam > AntiSpam → cloner le profil actuellement utilisé sous le nom AS_ENTRANT_DURCI, durcir le clone, puis basculer les politiques dessus. On ne modifie jamais un profil de production à l’aveugle.

Sections du profil (ordre 8.0) : FortiGuard · Greylist · SPF · DKIM · DMARC · ARC · Behavior analysis · Header analysis · Business email compromise · Heuristic · SURBL · DNSBL · Banned word · Safelist word · Dictionary · Image spam · Bayesian · Newsletter / Suspicious newsletter · Scan Option.

En 8.0, le batch editing (Profile > AntiSpam > AntiSpam, édition par lot) permet d’appliquer le même durcissement à plusieurs profils en une opération — utile en multi-domaines.

4.1 Section FortiGuard

Trois comportements de l’outbreak protection à connaître : 1. Elle ne se déclenche que si le contrôle FortiGuard (IP reputation et/ou URL) n’a rien retourné. Ce n’est pas un filet universel. 2. Si un message retenu est ensuite qualifié spam et que l’action configurée est reject, l’action réellement appliquée bascule en quarantaine système. 3. Les messages provenant d’IP en safe list et des règles ACL RELAY en sont exemptés — argument supplémentaire pour la purge du §1.5.

Le mode monitor only n’attend pas : il journalise et insère X-FEAS-Spam-outbreak: monitor-only. Utile pour mesurer avant d’activer.

File à superviser : Monitor > Mail Queue > Spam Outbreak. Pendant une vague, elle doit se remplir puis se vider ; une file qui gonfle sans se résorber signale un problème de connectivité FortiGuard.

Réglage de la durée :

config system fortiguard antispam
    set outbreak-protection-period 60
end

Si aucune détection « FortiGuard » n’apparaît dans les logs après activation, retourner au §1.2 : la connectivité rating est cassée.

4.2 Analyses locales

4.3 Authentification de l’expéditeur : SPF / DKIM / DMARC / ARC

SPF : - ☑ Enable SPF checking. - Fail (-all) → Reject (Level 2) ou Quarantine (Level 1, les deux premières semaines). - SoftFail (~all) → Tag et contribution au score, sans rejet. - None / Neutral / PermError → aucun blocage. Ne jamais rejeter sur « None » : trop de domaines légitimes n’ont pas de SPF.

DKIM : - ☑ Enable DKIM checking. - Signature invalide → Tag ou poids. Un échec DKIM seul ne justifie pas un rejet : les listes de diffusion cassent régulièrement les signatures. C’est DMARC qui arbitre.

DMARC : - ☑ Enable DMARC checking. - Respecter la politique publiée par l’expéditeur : p=reject → Reject ; p=quarantine → quarantaine système ; p=none → tag et journalisation. - Suivre les résultats dans Monitor > DMARC.

ARC : - ☑ Activer la vérification ARC, pour ne pas casser les messages ayant transité par des listes de diffusion ou des relais légitimes qui altèrent le contenu.

Anti-spoofing de vos propres domaines. Tout message entrant depuis Internet dont le From: d’en-tête appartient à vos domaines protégés doit soit passer SPF/DKIM/DMARC alignés, soit être rejeté ou quarantainé.

Implémentation par ordre de préférence : 1. Politique DMARC stricte sur vos domaines, une fois la phase d’observation terminée. 2. En 8.0 (licence advanced management) : règle d’Access Control matchant sur le From: d’en-tête, ce qui traite directement l’usurpation affichée : config policy access-control receive edit <id> set sender-option header-from # ou envelope-or-header-from set action reject next end 3. À défaut : règle d’Access Control sur l’enveloppe (Sender = *@votredomaine.fr, source ≠ vos IP) → Reject, précédée d’une règle autorisant vos IP internes.

Dans tous les cas, vérifier au préalable les émetteurs SaaS légitimes qui envoient en votre nom, et les intégrer à votre SPF/DKIM plutôt que de les whitelister.

4.4 Business email compromise (usurpation, fraude au président)

Section Business email compromise du profil AntiSpam. Elle regroupe trois mécanismes complémentaires.

Sender alignment. Compare le From: d’en-tête au domaine d’autorisation, et le From: au Reply-To:. C’est le contrôle le plus rentable contre la fraude au président et le phishing de marque, où le Reply-To pointe presque toujours ailleurs que l’expéditeur affiché. Disponible sur toutes les versions concernées par cette fiche — à activer sans réserve.

Impersonation analysis. Profil (Profile > AntiSpam > Impersonation) mappant les display names des VIP — direction, DAF, RH, comptabilité, IT — vers leurs adresses légitimes. Tout message entrant portant ce display name avec une autre adresse part en quarantaine. Couvrir les variantes de graphie : Prénom Nom, NOM Prénom, P. Nom.

Le mode dynamique existe en complément du mapping manuel, mais 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. Une fois active, le bouton Impersonation Lookup permet d’interroger la base dynamique.

Cousin domain. Profil (Profile > AntiSpam > Cousin domain) déclarant vos domaines et ceux de vos partenaires critiques, pour détecter les graphies voisines obtenues par suppression, substitution ou transposition de caractères. Option de scan : header + body.

Weighted analysis — Profile > AntiSpam > Weighted analysis. C’est le mécanisme de scoring pondéré du BEC : il 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.

C’est le seul endroit du produit où des signaux faibles s’additionnent, ce qui en fait le levier décisif contre le phishing bien rédigé : un message qui ne déclenche aucun signal fort isolé en cumule presque toujours plusieurs. Régler le seuil de façon à exiger au moins deux signaux distincts, ne jamais déclencher sur un seul. Deux semaines en action tag, relevé des déclenchements par signal, ajustement des poids, puis quarantaine.

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

4.5 Actions et quarantaine

Profile > AntiSpam > Action — créer AS_ACTION_DURCI.

• Verdict spam standard : quarantaine personnelle (recommandé), ou quarantaine système si une équipe sécurité la traite. Bannir « tag subject » comme action principale : c’est elle qui donne l’impression de passoire, le message arrivant malgré tout en boîte.
• Verdicts haute confiance (checksum FortiGuard, DNSBL, phishing, DMARC reject) : Reject ou Discard. Deux réserves :
• un rejet 5xx confirme au spammeur la validité de l’adresse — sur les verdicts de type signature, discard est souvent préférable ;
• sur les messages retenus par l’outbreak protection, un reject bascule de toute façon en quarantaine système (§4.1).
• ☑ Insérer un en-tête de traçabilité, avec un préfixe propre à votre organisation, par exemple X-ORG-Spam-Verdict: quarantine. Ne pas utiliser le préfixe X-FEAS-*, réservé à FortiMail, sous peine de collision et d’analyse post-incident ambiguë.
• Ne pas notifier l’expéditeur : cela génère du backscatter.

Quarantine report (Security > Quarantine > Quarantine Report) : digest utilisateurs une à deux fois par jour, avec liens de libération. Décocher « safelist sender » dans le digest pendant toute la phase de durcissement, pour garder la maîtrise des listes.

Rétention quarantaine : 14 à 30 jours. Surveiller le quota disque et l’action en cas de saturation.

Quarantine Release Rescan (8.0) — Security > Quarantine > Quarantine Control : activer le re-scan contenu et DLP à la libération. Sans cela, un utilisateur qui libère un message libère aussi sa pièce jointe sans nouvelle analyse.

4.6 Antivirus, contenu et sandbox

Profile > AntiVirus : - ☑ AV FortiGuard, ☑ heuristics, ☑ Virus Outbreak Protection, ☑ Grayware. - Si licencié : FortiSandbox ou FortiNDR pour l’inspection des pièces jointes inconnues.

Profile > Content : - Bloquer les extensions dangereuses : exe, js, vbs, vbe, scr, bat, cmd, ps1, hta, lnk, iso, img, jar, cab, msi, reg, chm, wsf. - ☑ Analyse des archives, profondeur ≥ 2 ; archives chiffrées ou non analysables → quarantaine système. En 8.0, les pièces jointes protégées par mot de passe peuvent déclencher une demande de mot de passe à l’utilisateur avant scan. - CDR / Content Disarm : désarmement des documents actifs. En 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. - URL protection : ☑ Click Protection / réécriture d’URL, pour réévaluer les liens au clic. Indispensable contre les URL « armées » après livraison, propres au moment du scan. Prévenir les utilisateurs du changement d’apparence des liens. - Image classification : profils de classification d’images, pour les contenus visuels indésirables.

4.7 Scan des QR codes (quishing)

Le QR code contourne toute analyse d’URL textuelle : il n’y a pas d’URL dans le corps, seulement une image. C’est aujourd’hui l’un des vecteurs de phishing les plus actifs.

Couverture : 7.6 et 8.0 scannent les URL encodées en QR code ; 8.0 les scanne jusque dans les PDF et les archives contenant des PDF.

• Préférences antispam → activer Attachment image (prérequis).
• Profil AntiSpam → Scan Option → ☑ Scan PDF attachment.
• Réglages du scan QR dans les PDF, en CLI, sous config antispam settings : activation du scan QR dans les PDF et nombre maximal de pages analysées.
• L’URL extraite du QR est ensuite soumise aux catégories d’URL et aux threat feeds : la chaîne §4.1 s’applique.

Coût : le scan d’images est le traitement le plus gourmand du produit. Mesurer la charge et plafonner le nombre de pages PDF analysées.

4.8 Threat feeds et notation locale d’URL

Threat feeds — Security > Threat Feed. FortiMail consomme des listes externes de plusieurs types, dont : - 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 * en début ou fin de chaîne. Le feed est rattaché à une catégorie d’URL, elle-même sélectionnée dans la section FortiGuard du profil.

Usage recommandé : hébergez en interne deux fichiers texte (iocs-ip.txt, iocs-url.txt) alimentés par votre équipe sécurité, avec un rafraîchissement court. Bloquer un indicateur revient alors à ajouter une ligne dans un fichier versionné, sans modification de configuration.

Notation locale d’URL — Security > URL Filter : - Custom URL rating categories : créer vos propres catégories thématiques ; - URL rating overrides : y verser les domaines issus de l’analyse de vos faux négatifs.

C’est plus propre, plus rapide et sans faux positif comparé à un motif de dictionnaire du type *domaine-suspect.fr*, qui matcherait aussi une discussion légitime à propos de ce domaine — typiquement vos propres alertes internes de sécurité, qui finissent alors en quarantaine.

5. PHASE 5 — Access Control (règles de réception)

Policy > Access Control > Receiving — l’ACL est évaluée avant les politiques. Ordre recommandé :

• Relais sortant interne : source = IP de vos serveurs mail internes → action RELAY, et eux seuls.
• Partenaires critiques éventuels, documentés : règles fines, jamais SAFE sauf cas assumé et tracé.
• Blocages explicites : IP, plages ou domaines abusifs récurrents → REJECT.
• Règle finale : sender * / recipient = vos domaines → RECEIVE. Ne jamais mettre RELAY ici, ce serait un relais ouvert.

En 8.0 (licence advanced management), l’ACL peut matcher l’expéditeur sur l’enveloppe, sur le From: d’en-tête, ou sur les deux (set sender-option). C’est ce qui permet de traiter l’usurpation de marque affichée directement en ACL, avant tout scan.

Contrôles : - Aucune règle RELAY à source large. Test externe : depuis Internet, telnet <IP> 25, puis MAIL FROM:<[email protected]> et RCPT TO:<[email protected]> → réponse attendue 554 5.7.1 Relaying denied. - Tester votre IP publique sur les principales blacklists. Un listing est presque toujours le signe d’un relais ouvert ou de backscatter (§3.6, §3.7).

6. PHASE 6 — Politiques : l’assemblage

Les meilleurs profils ne servent à rien s’ils ne sont pas appliqués par la politique qui matche réellement le trafic.

6.1 Ordre d’évaluation

• IP Policy (Policy > IP Policies) : matche sur l’IP du client SMTP. Porte le Session profile.
• Recipient Policy (Policy > Recipient Policies, Inbound/Outbound) : matche sur expéditeur et destinataire. Porte les profils AntiSpam, AntiVirus, Content, Resource, l’action, et les réglages par domaine ou utilisateur.
• Évaluation de haut en bas, premier match gagnant, dans chaque catégorie.
• Une IP policy peut, selon l’option « Take precedence over recipient based policies », écraser les profils de la recipient policy. Auditer cette case sur chaque IP policy : c’est un trou classique.

6.2 Structure cible (entrant)

IP Policies :

Recipient Policies (Inbound) :

En 8.0, le sender exclusion configurable dans les recipient policies permet de gérer les exceptions ciblées sans recourir à une safe list globale : c’est le mécanisme à privilégier pour traiter un faux positif récurrent.

Vérifications anti-trou : - ☐ Aucune recipient policy sans profil AntiSpam. - ☐ Aucune politique catch-all au-dessus, matchant avant avec des profils vides. - ☐ Les flux internes → internes (mode server ou mode API) et sortants portent aussi un profil AS : c’est ainsi qu’on détecte un compte interne compromis. - ☐ Aucun profil AS avec Apply default action without scan upon policy match coché. - Test de bout en bout : envoyer le GTUBE depuis une boîte externe — XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X → le message doit être détecté et suivre l’action configurée. Sinon, la politique qui matche n’a pas le bon profil : Monitor > Log > History, colonne Policy ID, pour identifier laquelle a traité le message. - Test antivirus équivalent : fichier EICAR en pièce jointe.

7. PHASE 7 — Boucle d’amélioration continue

7.1 Analyser chaque spam qui passe encore

Pour chaque faux négatif remonté : 1. Récupérer le message avec en-têtes complets (.eml). 2. Monitor > Log > History → Cross Search sur la ligne : affiche tous les logs corrélés (session, antispam, delivery). 3. Identifier : - Quelle politique a traité le message ? (Policy ID) Est-ce la bonne ? Porte-t-elle un profil AS ? - A-t-il bypassé le scan ? Safe list, règle ACL SAFE, domaine exempté, Apply default action without scan, ou authentification SMTP avec bypass activé. - A-t-il été scanné puis jugé propre ? Quelles techniques ont tourné ? FortiGuard a-t-il répondu ? 4. Selon la cause : corriger l’exemption (§1.5), rétablir la connectivité (§1.2), ou renforcer la technique concernée — heuristique, behavior analysis, weighted analysis, dictionnaire, impersonation.

7.2 Soumettre les échantillons à FortiGuard

• Faux négatifs et faux positifs : soumission via le portail FortiGuard (Anti-Spam sample submission), en joignant le .eml complet.
• En interne : boîte spam-signalement@ relevée par l’équipe, et/ou bouton de signalement (plugin Outlook FortiMail, ou fonction « Report as spam » du webmail et de la quarantaine).
• Les messages libérés de quarantaine et marqués « not spam » alimentent aussi l’apprentissage local.

7.3 Gérer les faux positifs proprement

Ordre de préférence : 1. Corriger la cause — SPF cassé chez l’émetteur, PTR manquant : le signaler, ou assouplir uniquement le contrôle concerné. 2. Sender exclusion dans la recipient policy concernée (8.0), ou safe list sur adresse exacte au niveau domaine. Jamais un domaine entier par réflexe. 3. En dernier recours : exemption ciblée par politique dédiée.

Documenter chaque exception : qui, pourquoi, date de revue.

7.4 Supervision et alerting

• Log & Report > Log Settings : logs AntiSpam / History / Event activés, export syslog vers SIEM ou FortiAnalyzer. En 8.0, le statut de délivrance des messages est également stocké et mis à jour sur FortiAnalyzer.
• Log & Report > Alert Email : alertes sur licence expirée, échec de mise à jour FortiGuard, disque plein, file d’attente anormale, événements HA, détections critiques.
• Rapport hebdomadaire automatique : volume, taux de détection par technique, top expéditeurs bloqués, à comparer à la base de mesure du §1.4.
• KPI cible : taux de spam en boîte < 0,5 % du flux entrant ; faux positifs < 0,05 %.
• Méthode de mesure des FP : échantillonnage manuel hebdomadaire de 50 messages quarantainés, relus. Les demandes de libération seules sous-estiment le taux réel.

7.5 Maintenance récurrente

8. Durcissement système du FortiMail

Un FortiMail compromis ou instable ne filtre plus rien.

• Administration : accès GUI et SSH restreints par Trusted Hosts ; HTTPS et SSH uniquement, HTTP et Telnet désactivés ; comptes nominatifs avec profils de droits minimaux ; MFA sur tous les comptes admin — FortiToken, RADIUS (le RADIUS sécurisé sur TLS est supporté en 8.0), SAML vers votre IdP, ou FortiIdentity Cloud ; politique de mot de passe robuste ; bannière légale.
• Ports d’administration sur interface ou VLAN dédié, jamais exposés sur l’interface publique.
• Firmware : suivre les avis PSIRT Fortinet, rester sur une version supportée et patchée. Les vulnérabilités FortiMail existent et sont exploitées.
• Certificat TLS valide sur webmail, quarantaine et interface d’administration. En 8.0, le SP SAML du webmail peut être séparé de celui de la GUI d’administration.
• SNMPv3 : si utilisé, authentification SHA-256 ou supérieure et chiffrement AES-256.
• Sauvegardes de configuration régulières et avant tout changement, stockées hors de l’appliance, restauration testée.
• HA : vérifier la synchronisation ; les modifications se font sur le maître ; tester la bascule.
• Services inutiles désactivés (POP3/IMAP hors mode server, webmail si non utilisé).

9. CHECKLISTS

Convention : N1 = applicable partout, faible risque d’effet de bord. N2 = durcissement fort, à tester (risque de faux positifs ou d’impact fonctionnel). Statut : ☐ Conforme / ☐ Non conforme / ☐ N/A.

9.1 Fondations et flux

9.2 Session / connexion

9.3 Profil AntiSpam

9.4 Actions, quarantaine, contenu

9.5 Access control et politiques

9.6 Plateforme, journalisation, MCO

10. Mode opératoire express « Sprint 1 jour »

Si vous ne disposez que d’une demi-journée, dans cet ordre :

• ☐ Vérifier licence et rating FortiGuard (diagnose debug rating) — 15 min, impact maximal.
• ☐ Vérifier que l’IP client réelle est visible (§1.3) — 5 min, deux couches en jeu.
• ☐ Décocher Bypass scan on SMTP authentication et Apply default action without scan — 5 min, deux bypass silencieux.
• ☐ Purger les safe lists : vos domaines, wildcards, gmail/outlook — 30 min.
• ☐ Activer toutes les techniques FortiGuard + Outbreak Protection dans le profil AS — 20 min.
• ☐ Activer le sender alignment — 5 min, gratuit, immédiatement rentable.
• ☐ Passer l’action spam de « tag » à « quarantaine » + digest utilisateurs — 20 min.
• ☐ Appliquer un session profile durci (sender reputation + limites + DNSBL) sur l’IP policy Internet — 30 min.
• ☐ Activer SPF / DKIM / DMARC / ARC en entrant — 20 min.
• ☐ Vérifier la vérification des destinataires LDAP et le rejet en session — 30 min.
• ☐ Tests GTUBE, spoof de votre propre domaine, open relay — 30 min.
• ☐ Noter la base de mesure et re-mesurer à J+7.

Puis dérouler les Level 2 — weighted analysis, greylisting, PTR strict, impersonation, sandbox, CDR, click protection — sur les semaines suivantes, un contrôle à la fois, avec mesure des FP entre chaque.

Annexe A — Commandes CLI utiles

Contrôler chaque commande par ? dans son contexte avant exécution ; les libellés d’options varient selon la branche.

get system status                          # version, licences
diagnose debug rating                      # serveurs FortiGuard antispam
diagnose debug application updated -1      # debug des mises à jour
execute update                             # forcer une mise à jour
execute nslookup 2.0.0.127.zen.spamhaus.org   # test DNSBL
diagnose system top                        # charge
get system performance                     # performances
diagnose system disk-usage                 # disque
diagnose system mailqueue                  # files d'attente
diagnose debug application smtp -1         # debug SMTP — à couper après
diagnose debug enable / disable
diagnose sniffer packet port1 "tcp port 25 and host 203.0.113.10" 4 100
execute backup config scp ...              # sauvegarde

Annexe B — Chaînes de test

• GTUBE (antispam) : XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X, dans le corps d’un message envoyé depuis l’extérieur.
• EICAR (antivirus) : fichier texte contenant la chaîne standard EICAR, en pièce jointe.

Annexe C — Références

• Fortinet Docs — FortiMail Administration Guide, chapitre Best practices and fine tuning (sections Antispam tuning et Policy tuning) : https://docs.fortinet.com — sélectionner votre version.
• Fortinet Community KB — Best Practices for Antispam profile of FortiMail, article 202697.
• Fortinet Community KB — FortiMail antispam best practices, article 99499.
• FortiGuard — soumission d’échantillons : https://www.fortiguard.com
• PSIRT Fortinet : https://www.fortiguard.com/psirt

Document de travail — à adapter à votre version exacte de FortiMail et à votre contexte (volumétrie, secteur, sensibilité aux faux positifs). Tester chaque contrôle Level 2 en mode observation avant durcissement définitif.