MS Pro

Rspamd devant ta boîte mail, le phishing s'arrête au paillasson

Installer Rspamd devant ton serveur mail, régler le scoring anti-spam et anti-hameçonnage, et faire remonter chaque verdict dans ton SIEM Wazuh.

À l’épisode précédent, tu as posé CrowdSec en première ligne. Ton pare-feu refoule désormais les IP malveillantes avant qu’elles ne touchent tes services, et chaque décision remonte dans Wazuh. Ton SIEM voit et il mord.

Sauf que l’attaque qui va te coûter cher n’arrivera pas par le port SSH.

Elle arrivera par un mail. Une fausse facture qui imite ton fournisseur habituel, un lien qui ressemble à ton portail bancaire, une pièce jointe que ta comptable ouvrira parce que c’est son travail d’ouvrir des PJ factures.

Ce mail-là traverse ton pare-feu sans un bruit, parce qu’il entre par une porte que tu as toi-même laissée ouverte, le port 25. CrowdSec ne bloquera rien, l’expéditeur a une IP propre. Wazuh ne verra rien, personne ne lui a dit de regarder de ce côté.

C’est l’angle mort du dispositif. Trois briques posées, et le vecteur d’intrusion numéro un des PME passe encore en clair.

Aujourd’hui, on le bouche. On installe Rspamd, un moteur de filtrage qui s’intercale devant ton serveur mail, note chaque message entrant et décide de son sort. Puis on branche sa journalisation sur Wazuh, pour que chaque verdict, spam bloqué, hameçonnage détecté, message livré, s’affiche dans ton tableau de bord unique.

Avant de commencer

Trois choses en tête avant la première commande.

Ce qu’il te faut. Un serveur mail que tu administres, Postfix ou Exim, sur un serveur durci comme celui de l’épisode 1. Le manager Wazuh de l’épisode 2 en place sur ton VPS, et l’agent Wazuh de l’épisode 3 déjà installé sur ce serveur mail, pour la partie intégration en fin de tuto. Un accès administrateur, et Redis, qu’on installera en même temps que le moteur.

Ce que ça change. À la fin, chaque message entrant est noté avant d’atteindre la boîte de ton salarié. Les évidences sont refusées à la porte, les douteux arrivent marqués, les tentatives d’hameçonnage lèvent une alerte dans ton SIEM. Tu passes d’une boîte mail aveugle à une boîte mail instrumentée.

Ce que ça ne change pas. Rspamd filtre le mail entrant. Ce n’est pas un antivirus de poste, ce n’est pas un remplaçant du bon sens de tes salariés, et ça ne protège pas contre un compte dont le mot de passe a fuité, l’attaquant est alors dedans, pas dehors. Et Rspamd n’est pas infaillible, il te trompera parfois. La question n’est pas s’il se trompe, c’est de quel côté tu règles le curseur quand il se trompe.

Rspamd ne dit pas oui ou non, il note

Le point qui change tout, et qui sépare Rspamd des filtres anti-spam classiques.

Un filtre binaire regarde un message et tranche, spam ou pas spam. Le résultat est une porte, ouverte ou fermée, et le monde réel se venge vite de cette simplification. Une facture légitime avec un lien raccourci et une pièce jointe se fait jeter, une arnaque bien écrite passe.

Rspamd, lui, accumule. Il fait tourner des dizaines de vérifications sur le même message, chacune rapportant un petit poids, positif ou négatif. L’authentification de l’expéditeur échoue, plus deux points. Le domaine est sur une liste noire réputée, plus quatre. L’URL affichée ne correspond pas à l’URL réelle du lien, plus sept. Le message ressemble à cent autres déjà signalés comme spam, plus cinq. À l’inverse, l’expéditeur est correctement signé et connu, moins un.

À la fin, il obtient un score, et ce score déclenche une action selon des seuils que tu fixes toi-même. La configuration recommandée est celle-ci.

Score 4, greylist. Le serveur expéditeur est prié de repasser plus tard. Un vrai serveur mail le fait, un robot de spam rarement.

Score 6, add header. Le message est livré, mais marqué. Ton client mail peut le ranger en indésirables.

Score 15, reject. Le message est refusé à la porte, il n’entre jamais.

Trois niveaux de fermeté, pas une porte. C’est la même philosophie que le SIEM de l’épisode 2, on ne cherche pas la certitude, on cherche à graduer sa réponse à un signal incertain.

Côté architecture, Rspamd tourne en plusieurs processus spécialisés. Le worker proxy est celui qui parle à ton serveur mail, en protocole milter, sur le port 11332. Le worker normal fait le calcul du score. Le worker controller sert l’interface web et l’apprentissage. Tu n’auras à connaître que le premier, c’est lui qu’on branche.

Étape 1, installer le moteur

Sur la machine qui héberge ton serveur mail. Le dépôt officiel Rspamd, puis le paquet, puis Redis, dont Rspamd a besoin pour ses statistiques, son filtre bayésien et son greylisting.

curl -fsSL https://rspamd.com/apt-stable/gpg.key | sudo gpg --dearmor -o /usr/share/keyrings/rspamd.gpg
echo "deb [signed-by=/usr/share/keyrings/rspamd.gpg] https://rspamd.com/apt-stable/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/rspamd.list
sudo apt update
sudo apt install rspamd redis-server

Le dépôt apt-stable est la branche de production, celle que tu veux sur un serveur mail. Rspamd est en version 4.x depuis mars 2026.

Dis-lui où trouver Redis, dans /etc/rspamd/local.d/redis.conf.

servers = "127.0.0.1:6379";

Une règle de survie avec Rspamd, et elle vaut pour tout le tuto. Tu ne touches jamais aux fichiers de /etc/rspamd/ directement. Tu écris tes réglages dans /etc/rspamd/local.d/, qui vient s’ajouter par-dessus la configuration par défaut. Une mise à jour du paquet écrase la première, jamais la seconde.

Fixe ensuite un mot de passe pour l’interface web.

rspamadm pw

Il te sort une empreinte que tu recopies dans /etc/rspamd/local.d/worker-controller.inc.

password = "$2$ton_empreinte_ici";

L’interface écoute sur le port 11334, en local uniquement. Laisse-la comme ça. Doctrine de la série depuis l’épisode 1, rien d’inutile sur l’internet ouvert, tu y accèdes par ton Tailnet ou un tunnel SSH.

Étape 2, le brancher devant ton serveur mail

Rspamd tourne, mais aucun message ne lui est présenté. Il faut que ton serveur mail lui soumette chaque courrier entrant avant de l’accepter.

Le mécanisme s’appelle milter, pour mail filter. Ton serveur mail met le message en pause pendant la transaction SMTP, le tend à Rspamd, attend le verdict, et agit en conséquence. Le message est jugé avant d’être accepté, c’est toute la différence avec un filtre qui trie après coup dans la boîte.

Sur Postfix, trois lignes dans /etc/postfix/main.cf.

smtpd_milters = inet:localhost:11332
milter_protocol = 6
milter_default_action = accept

La ligne qui mérite ton attention, c’est la troisième. accept veut dire que si Rspamd est en panne, le courrier passe sans filtrage. Tu privilégies la continuité du service. L’autre valeur couramment retenue est tempfail, qui demande à l’expéditeur de repasser plus tard, ton mail est protégé même Rspamd à terre, mais une panne prolongée devient un incident de messagerie. Choisis en connaissance de cause. Pour une PME, accept est le défaut raisonnable, à condition de surveiller le service Rspamd dans ton SIEM.

Sur Exim, le branchement passe par le worker normal en HTTP, pas par le milter.

spamd_address = 127.0.0.1 11333 variant=rspamd

Recharge ton serveur mail, et envoie-toi un message depuis une adresse extérieure. Rspamd commence à noter.

Étape 3, régler les seuils et armer l’anti-hameçonnage

Les seuils d’abord, dans /etc/rspamd/local.d/actions.conf.

greylist = 4;
add_header = 6;
reject = 15;

Ce sont les valeurs recommandées, et elles sont volontairement clémentes. Un reject à 15 signifie qu’il faut une accumulation massive de signaux négatifs pour qu’un message soit refusé. C’est ce que tu veux au démarrage, on durcit plus tard, une fois qu’on a lu ses propres journaux.

L’authentification de l’expéditeur ensuite. Trois modules actifs par défaut, SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) et DMARC (Domain-based Message Authentication, Reporting and Conformance). Ils vérifient trois choses, que le serveur émetteur a le droit d’envoyer pour ce domaine, que la signature cryptographique du message est valide, et que le domaine affiché dans le champ « De » est bien celui qui est authentifié. Un mail qui prétend venir de ta banque et qui échoue aux trois est démasqué sans avoir besoin de lire une seule ligne de son contenu.

Par défaut, Rspamd note ces échecs mais n’applique pas la politique publiée par le domaine expéditeur. Pour qu’il l’applique, dans /etc/rspamd/local.d/dmarc.conf.

actions {
  quarantine = "add header";
  reject = "reject";
}

Tu obéis désormais à ce que le vrai propriétaire du domaine a demandé au monde de faire des messages qui usurpent son identité. C’est gratuit, c’est immédiat, et ça élimine une famille entière de faux expéditeurs.

Le module phishing enfin, le cœur du sujet. Sa vérification de base est déjà active, il compare l’URL affichée dans le texte du lien à l’URL réelle de destination, et lève le symbole PHISHED_URL quand les deux domaines divergent. C’est exactement le mécanisme du faux lien bancaire.

Tu peux l’adosser à deux bases publiques d’URL de hameçonnage connues, dans /etc/rspamd/local.d/phishing.conf.

openphish_enabled = true;
openphish_map = "https://raw.githubusercontent.com/openphish/public_feed/refs/heads/main/feed.txt";
phishtank_enabled = true;

Pas de bloc phishing { } autour, et c’est la règle local.d de l’étape 1 qui joue. Rspamd inclut déjà ce fichier à l’intérieur de la section du module, tu n’écris que le contenu. Ajoute le bloc, et tu obtiens une section dans une section, silencieusement ignorée, aucune erreur au démarrage et aucun flux activé.

Le message qui contient une URL déjà signalée ailleurs dans le monde lève PHISHED_OPENPHISH ou PHISHED_PHISHTANK, avec un poids lourd. La logique communautaire de CrowdSec, transposée aux liens malveillants.

Trois autres modules travaillent pour toi sans que tu les configures. rbl interroge les listes noires publiques de serveurs d’envoi. fuzzy_check compare l’empreinte du message à celle de spams déjà signalés par le réseau Rspamd, un spam reformulé garde une empreinte proche. bayes apprend de tes propres messages, à condition de l’entraîner.

autolearn = true;

dans /etc/rspamd/local.d/classifier-bayes.conf, et Rspamd apprend seul des messages qu’il a classés avec certitude. Tu peux aussi le corriger à la main quand il se trompe, avec rspamc learn_spam sur un message passé au travers, ou rspamc learn_ham sur un légitime qu’il a marqué à tort.

Étape 4, le mettre à l’épreuve

Plutôt qu’attendre un vrai spam, tu en fabriques un.

Il existe pour ça une chaîne de caractères standard, le GTUBE, reconnue par tous les moteurs anti-spam sérieux et conçue pour déclencher un rejet certain sans être un vrai spam. Tu l’écris dans un message de test, et tu le soumets au moteur avec rspamc, le client en ligne de commande.

printf 'Subject: test\n\nXJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X\n' > /tmp/gtube.eml
rspamc symbols /tmp/gtube.eml

Tu dois voir le symbole GTUBE et l’action reject. Le GTUBE court-circuite le calcul du score et force le rejet directement, c’est tout l’intérêt du test. Si tu l’obtiens, le moteur tourne, il note et il tranche. Tu obtiens quelque chose comme ceci.

Results for file: /tmp/gtube.eml (0.014 seconds)
[Metric: default]
Action: reject
Spam: true
Symbol: GTUBE (0.00)
Message-ID: undef

Pas besoin d’un score qui crève le seuil, le symbole GTUBE déclenche un passthrough qui impose l’action reject quel que soit le total. C’est le comportement attendu, ton moteur applique bien le verdict.

Deux commandes de contrôle pour la suite.

rspamc stat

Elle te donne l’état du moteur, les messages scannés, la répartition par action, l’état du filtre bayésien.

rspamc symbols /chemin/vers/un/vrai/message.eml

Elle rejoue un vrai message et t’affiche le détail des symboles avec leur poids. C’est ton outil de diagnostic quand un message est passé alors qu’il n’aurait pas dû, ou l’inverse. Tu ne devines pas, tu lis la ligne de compte.

Étape 5, faire remonter Rspamd dans Wazuh

Rspamd filtre, très bien. Ton SIEM ne le sait toujours pas. On les branche, et la boucle de la série se referme sur le mail.

Rien à activer côté Rspamd. Il écrit déjà, par défaut, une ligne par message traité dans /var/log/rspamd/rspamd.log. Un fichier persistant, sur disque, exactement ce dont Wazuh a besoin. Une ligne ressemble à ceci.

2026-07-14 09:41:07 #3421(rspamd_proxy) <7f2c1a>; task; rspamd_task_write_log: id: <[email protected]>, qid: <4XjK2r1Yz>, ip: 203.0.113.42, from: <[email protected]>, (default: T (reject): [16.40/15.00] [PHISHED_URL,DMARC_POLICY_REJECT,R_SPF_FAIL,BAYES_SPAM]), len: 4021, time: 128.4ms real, dns req: 22

Tout y est. L’IP de l’expéditeur, son adresse, l’action retenue, le score obtenu face au seuil, et la liste complète des symboles qui l’ont fait tomber. C’est un rapport d’enquête par message.

Le branchement se fait sur deux machines, et c’est le point où on se plante si on va vite. L’agent Wazuh, sur ton serveur mail, ne comprend rien à ce qu’il lit, il expédie les lignes brutes. C’est le manager, sur le VPS de l’épisode 2, qui décode et applique les règles. Une machine ramasse, l’autre comprend.

Sur le serveur mail, tu dis à l’agent de lire le fichier. Le bloc va dans son ossec.conf.

<localfile>
  <location>/var/log/rspamd/rspamd.log</location>
  <log_format>syslog</log_format>
</localfile>

Tu reconnais le <localfile> de l’épisode 3, le mécanisme par lequel Wazuh avale n’importe quelle source de journaux.

Sur le manager, maintenant, et sur lui seul. Un décodeur extrait les champs utiles de la ligne, dans /var/ossec/etc/decoders/local_decoder.xml.

<decoder name="rspamd">
  <prematch>rspamd_task_write_log: </prematch>
</decoder>

<decoder name="rspamd-verdict">
  <parent>rspamd</parent>
  <regex type="pcre2">ip: (\S+?), .*?\(default: \S+ \(([\w ]+)\): \[(-?\d+\.\d+)/</regex>
  <order>srcip, rspamd_action, rspamd_score</order>
</decoder>

Puis des règles qui transforment ces champs en alertes graduées, dans /var/ossec/etc/rules/local_rules.xml, toujours sur le manager.

<group name="rspamd,">
  <rule id="100400" level="0">
    <decoded_as>rspamd</decoded_as>
    <description>Rspamd, verdict de scan.</description>
  </rule>

  <rule id="100401" level="12">
    <if_sid>100400</if_sid>
    <match>PHISHED_</match>
    <description>Rspamd, hameçonnage détecté, expéditeur $(srcip).</description>
  </rule>

  <rule id="100402" level="10">
    <if_sid>100400</if_sid>
    <field name="rspamd_action" type="pcre2">^reject$</field>
    <description>Rspamd, message rejeté, expéditeur $(srcip).</description>
  </rule>

  <rule id="100403" level="5">
    <if_sid>100400</if_sid>
    <field name="rspamd_action" type="pcre2">^add header$</field>
    <description>Rspamd, message marqué spam et livré, expéditeur $(srcip).</description>
  </rule>
</group>

L’ordre de déclaration n’est pas cosmétique, il est le cœur du réglage. La règle mère est en niveau 0, elle décode sans alerter, sinon ton tableau de bord se noie sous les messages légitimes. L’hameçonnage passe en premier, en niveau 12, parce que Wazuh ne déclenche qu’une seule règle par message, la première de la liste qui correspond. Une fausse facture d’hameçonnage est aussi un message rejeté, et si tu déclares le rejet avant elle, elle sort en niveau 10 et l’alerte que tu attendais ne vient jamais. Puis le rejet en 10, et le spam marqué mais livré en 5.

Même logique sur l’ancrage. ^reject$ et non reject, parce que Rspamd possède aussi une action soft reject, un simple report temporaire, qui contient le mot et déclencherait une alerte de rejet pour un message qui n’a rien de rejeté.

Ne crois pas ce décodeur sur parole, teste-le. Wazuh a l’outil qu’il faut, et il vit sur le manager, pas sur l’agent.

sudo /var/ossec/bin/wazuh-logtest

Tu colles une vraie ligne de ton rspamd.log, et il te montre ce qu’il en a compris, phase par phase, décodeur reconnu, champs extraits, règle déclenchée. Si srcip et rspamd_action ne sortent pas, c’est le motif d’extraction qu’il faut ajuster, et tu le sauras en trente secondes au lieu d’attendre en vain une alerte qui ne viendra jamais. Prends une ligne d’hameçonnage rejeté pour ton test, c’est le cas qui met à l’épreuve l’ordre de tes règles. Sur la ligne d’exemple plus haut, tu vises un résultat de cette forme.

**Phase 1: Completed pre-decoding.
	full event: '2026-07-14 09:41:07 #3421(rspamd_proxy) <7f2c1a>; task; rspamd_task_write_log: id: <[email protected]>, qid: <4XjK2r1Yz>, ip: 203.0.113.42, from: <[email protected]>, (default: T (reject): [16.40/15.00] [PHISHED_URL,DMARC_POLICY_REJECT,R_SPF_FAIL,BAYES_SPAM]), len: 4021, time: 128.4ms real, dns req: 22'

**Phase 2: Completed decoding.
	name: 'rspamd'
	srcip: '203.0.113.42'
	rspamd_action: 'reject'
	rspamd_score: '16.40'

**Phase 3: Completed filtering (rules).
	id: '100401'
	level: '12'
	description: 'Rspamd, hameçonnage détecté, expéditeur 203.0.113.42.'
	groups: '['rspamd']'
	firedtimes: 1
	mail: false
**Alert to be generated.

La phase 2 sort tes trois champs, la phase 3 déclenche la règle 100401 en niveau 12, c’est l’alerte d’hameçonnage que tu attendais. Ne prends pas ce bloc pour une capture arrachée à une machine de production, c’est le résultat visé, pas un relevé de prod. Le pré-décodage syslog posé sur une ligne Rspamd qui n’a pas la forme d’un log syslog, et le motif d’extraction du décodeur, peuvent varier selon ta version de Wazuh et le format exact de tes lignes rspamd.log. C’est précisément ce que wazuh-logtest te confirme chez toi, phase par phase, avant que tu comptes sur l’alerte.

Une fois le test concluant, redémarre les deux services, chacun sur sa machine. Le manager, pour qu’il charge ton décodeur et tes règles.

sudo systemctl restart wazuh-manager

Et l’agent du serveur mail, pour qu’il prenne en compte son <localfile>.

sudo systemctl restart wazuh-agent

Une IP envoie une fausse facture, Rspamd la note, la rejette, l’écrit dans son journal, l’agent Wazuh la lit et l’expédie, le manager la décode et lève une alerte de niveau 12, elle s’affiche dans ton tableau de bord à côté de tes blocages CrowdSec et de tes échecs d’authentification SSH. Dans Discover, tu la filtres sur les champs srcip, rspamd_action et rspamd_score, exactement comme le reste de tes événements.

L’angle mort est bouché.

Si ça ne marche pas

Problème, Rspamd tourne mais aucun message n’est noté

Cause probable, le milter n’est pas branché. Rspamd attend sur son port, ton serveur mail ne lui présente rien.

Solution, vérifie que le worker proxy écoute bien sur 11332, et que smtpd_milters pointe dessus dans ta configuration Postfix. Recharge le serveur mail, pas seulement Rspamd.

Problème, des messages légitimes sont rejetés

Cause probable, ton seuil de rejet est trop bas, ou un expéditeur que tu connais échoue à son propre SPF, ce qui arrive plus souvent qu’on ne le croit.

Solution, rejoue le message avec rspamc symbols, lis les symboles qui l’ont fait monter. Si le coupable est un symbole unique et légitime, remonte ton seuil de reject plutôt que de désactiver le module.

Problème, le score n’apprend rien, le filtre bayésien reste muet

Cause probable, Redis n’est pas joignable. Sans lui, ni bayes, ni greylisting, ni statistiques.

Solution, vérifie le service Redis et le contenu de /etc/rspamd/local.d/redis.conf. rspamc stat te dira si le classifieur a des données.

Problème, rien ne remonte dans Wazuh

Cause probable, trois suspects, et il faut les départager avant de toucher à quoi que ce soit. Soit le fichier ne grossit pas, soit l’agent ne le lit pas, soit le manager ne sait pas le décoder. Le grand classique, ce sont le décodeur et les règles édités sur le serveur mail au lieu du manager. Ils n’y servent à rien.

Solution, le fichier grossit-il ? S’il grossit, va sur le manager, passe une ligne dans wazuh-logtest et regarde à quelle phase ça casse. Vérifie au passage que local_decoder.xml et local_rules.xml sont bien sur cette machine-là, et que tu as redémarré wazuh-manager après les avoir écrits. Ne réinstalle pas Rspamd pour un souci de motif d’extraction.

Ce que ça t’a coûté

La licence, rien. Rspamd est open source, sans version payante, sans palier entreprise, sans quota de messages.

La machine, peu. Le moteur est écrit en C et tourne sur ton serveur mail existant, aux côtés de Redis. Sur le volume d’une PME, tu ne changeras pas de gabarit de serveur pour ça. Surveille quand même ta RAM après avoir activé le filtre bayésien et fuzzy_check, ce sont eux qui consomment.

Ton temps, un peu. Compte une petite heure pour l’installation, le milter et l’intégration Wazuh.

Et le vrai prix, la calibration. Il ne se paye pas le jour de l’installation, il se paye les deux semaines suivantes, à lire tes propres journaux et à remonter tes seuils quand un message légitime s’est fait jeter. Un anti-spam mal réglé ne te coûte pas de la RAM, il te coûte une commande client perdue dans un rejet silencieux. C’est la raison pour laquelle ce tuto te fait démarrer clément, à 15 de seuil de rejet, et durcir ensuite. Dans l’autre sens, tu apprends la valeur d’un faux positif à tes dépens.

C’est le seul poste de dépense sérieux, et aucun SaaS ne te l’épargne. Lui aussi se trompera, simplement tu ne verras pas pourquoi.

Pour les pressés

Ce que fait cet article. On installe Rspamd sur le serveur mail, on le branche en milter devant Postfix, on règle les seuils de scoring, on active l’anti-hameçonnage et l’application des politiques DMARC, puis on fait remonter chaque verdict dans Wazuh via un décodeur et des règles maison. La couche mail cesse d’être l’angle mort du SIEM.

Concrètement, les commandes.

Installer le dépôt stable, rspamd et redis-server via apt.
Pointer Redis : servers = "127.0.0.1:6379"; dans /etc/rspamd/local.d/redis.conf.
Mot de passe de l’interface : rspamadm pw, empreinte dans /etc/rspamd/local.d/worker-controller.inc. Interface en local uniquement.
Brancher le milter Postfix : smtpd_milters = inet:localhost:11332, milter_protocol = 6, milter_default_action = accept dans main.cf.
Seuils : greylist = 4; add_header = 6; reject = 15; dans /etc/rspamd/local.d/actions.conf.
Appliquer DMARC : bloc actions { quarantine = "add header"; reject = "reject"; } dans /etc/rspamd/local.d/dmarc.conf.
Anti-hameçonnage : openphish_enabled et phishtank_enabled dans /etc/rspamd/local.d/phishing.conf.
Apprentissage : autolearn = true; dans /etc/rspamd/local.d/classifier-bayes.conf.
Tester : message GTUBE puis rspamc symbols /tmp/gtube.eml, action attendue reject.
Intégrer à Wazuh, sur deux machines : <localfile> sur /var/log/rspamd/rspamd.log côté agent, décodeur et règles côté manager (local_decoder.xml et local_rules.xml, règle hameçonnage déclarée en premier), validation avec /var/ossec/bin/wazuh-logtest sur le manager, puis redémarrage de wazuh-manager et de wazuh-agent.

En résumé

Tu es parti d’un dispositif qui voyait tes serveurs et bloquait ton réseau, mais laissait entrer la fausse facture par la grande porte.

Tu as installé Rspamd devant ton serveur mail, en milter, pour que chaque message soit jugé avant d’être accepté. Tu as réglé le scoring plutôt qu’un verdict binaire, trois niveaux de fermeté, greylist, marquage, rejet, avec des seuils que tu maîtrises.

Tu as armé l’anti-hameçonnage, comparaison des URL affichées et réelles, bases publiques de liens malveillants, application des politiques DMARC des domaines usurpés. Et tu as branché tout ça sur Wazuh, décodeur et règles graduées, pour qu’une tentative de hameçonnage lève une alerte de niveau 12 dans le même tableau de bord que le reste.

Le tout reste chez toi. Aucun message ne quitte ton serveur pour être analysé ailleurs, aucun prestataire ne lit ton courrier pour te dire s’il est propre. C’est la différence entre un filtre que tu héberges et une passerelle mail dans le cloud de quelqu’un d’autre, à qui tu confies l’intégralité de ta correspondance d’entreprise pour qu’il la protège.

Il reste une porte d’entrée, et c’est celle qui tient dans les mains de tes salariés. Le fichier qu’on a téléchargé sans réfléchir, la macro qu’on a autorisée, le binaire qui n’aurait jamais dû démarrer. À l’épisode 6 on descend sur les Mac, et on règle le problème en décidant quelles applications ont le droit de s’exécuter.

Rappel de la série

Sept épisodes pour monter ta plomberie de sécurité souveraine, brique par brique.

Épisode 0, le fondement de la série. Pourquoi une PME a besoin d’un SIEM souverain, NIS2, RGPD, et le coût du statu quo.
Épisode 1, le socle. Le VPS durci hors CLOUD Act.
Épisode 2, Wazuh en tout-en-un. Manager, indexeur et tableau de bord sur un seul nœud.
Épisode 3, les agents partout. Déploiement sur tes serveurs, Mac et Windows.
Épisode 4, la défense réseau communautaire. Bloquer les attaquants connus avant qu’ils n’arrivent.
Épisode 5, le filtre mail. Anti-spam et anti-hameçonnage devant ton serveur de messagerie. Tu viens de le lire.
Épisode 6, le contrôle d’exécution sur les Mac. Décider quelles applications ont le droit de démarrer.
Épisode 7, alerting et coût total. Notifications calibrées et bilan financier honnête face au SaaS.

Des termes techniques ? Consulte le glossaire.