Protéger son infrastructure du spam

1. Introduction

En guise d'introduction, nous allons faire un rappel sur le fonctionnement de la messagerie électronique. Les MTA (Mail Transfer Agent) sont les serveurs responsables de l'acheminement du courrier électronique. Cet acheminement se fait conformément au protocole SMTP (Simple Mail Transfer Protocol), qui définit la manière de communiquer entre deux MTA en utilisant le protocole TCP. Une adresse e-mail est composée de deux champs séparés par le caractère @ : une partie locale (identifiant de l'utilisateur) et une partie domaine. Lorsqu'un MTA cherche à livrer un e-mail à un utilisateur d'un domaine distant, il commence par effectuer une requête DNS de type MX (Mail eXchanger) sur un des serveurs DNS responsables du domaine cible. Si la requête DNS échoue, le MTA doit réessayer plus tard. Si elle ne renvoie aucun enregistrement MX, alors le MTA doit prendre comme MX l'hôte lui-même. Enfin, si la requête est un succès, le MTA prend la liste d'hôtes renvoyée et tente une connexion TCP sur le port 25 de ceux-ci par ordre de priorité. En cas d'erreur permanente, le client renvoie un message d'erreur permanente à l'expéditeur. En cas d'échec temporaire, le client réessaye d'envoyer le message en utilisant les serveurs ayant une priorité inférieure. S'il ne reste plus de serveurs dans la liste, le message est alors mis en attente.

Une fois arrivé au MTA de destination, l'e-mail est passé au MDA (Mail Delivery Agent). Le MDA est généralement directement exécuté par le MTA afin d'ajouter le message à la boîte aux lettres de l'utilisateur de destination. C'est en fait le MDA qui prend alors en charge la partie finale du traitement.

Le MUA (Mail User Agent) est un programme permettant à l'utilisateur de lire et d'envoyer des messages. Celui-ci dialogue avec le MTA en utilisant le protocole SMTP (client uniquement) et avec le serveur de boîtes aux lettres par les protocoles POP ou IMAP.

 

 

Les exemples de cet article vont s'appuyer sur le MTA libre Postfix. Il implémente les principes de la séparation de privilèges (un programme dédié à chaque tâche) et du moindre privilège (chaque programme tourne sous l'identité d'un utilisateur possédant uniquement les droits nécessaires).

 

 

Le programme « master » est le seul composant tournant sous l'identité « root ». Il est chargé d'exécuter les différents démons composant Postfix. On trouve notamment :

- Smtpd : il traite la transaction SMTP du MTA distant ou du MUA. Une fois l'intégralité du message reçue, il le passe au programme gérant la file d'attente ;

- Pickup/cleanup : traite l'insertion du message dans la file d'attente ;

- Postdrop : il traite la transaction SMTP d'un client connecté localement au système (par exemple, des e-mails générés par des scripts d'administration locaux). Une fois l'intégralité du message reçue, il le passe au programme gérant la file d'attente ;

- Qmgr : il sort les messages de la file d'attente pour les passer soit à un programme chargé de les livrer à un MTA distant, soit à un autre gérant les livraisons locales ;

- Smtp : il effectue une connexion SMTP avec un autre MTA ;

- Local : effectue une livraison de courrier local.

Nous allons commencer par un état de l'art des méthodes ([Black|Grey]List] et Bayes) et implémentations (Postgrey et Spamassassin) disponibles dans le monde du libre. Ensuite, nous allons voir comment durcir son architecture mail contre la prolifération (extrusion) de spams résultant de compromissions internes. Dans la section suivante, quelques outils libres originaux seront introduits. Nous conclurons sur quelques perspectives autour des distributions de politiques d'acheminement de mails (SPF et SenderID) et de la signature de mails (DKIM).

2. État de l'art

2.1 DNS BlackList (DNSBL)

Ces listes d'adresses IP de MTA de spammeurs connus ou supposés sont utilisées par les outils de lutte contre le spam. Le principal souci pour ces listes est de proposer un moyen de consultation simple ayant une faible latence et pouvant s’adapter à une sollicitation importante. En 1997, Paul Vixie a donc eu l'idée de créer la première blacklist en s'appuyant sur DNS. Ce protocole satisfait tous les prérequis mentionnés. En créant une zone DNS sur un nom de domaine donné (par exemple, bl.spamcop.net) et en la peuplant avec les adresses IP des MTA de spammeurs, on obtient le premier mécanisme DNSBL (DNS BlackList). Paul décida de nommer sa DNSBL « RBL » (Realtime Blackhole List).

Lorsqu'un client se connecte à un service implémentant des DNSBL, celui-ci effectue une résolution DNS sur un hostname construit à partir de l'adresse IP du client, de la même manière que pour une résolution inverse (voir l’exemple ci-dessous). Le serveur DNSBL répond par un NXDomain si l'adresse IP n'est pas présente dans la zone (c'est-à-dire que le client n'est pas blacklisté) :

Il répond par un enregistrement A si le client est présent dans la DNSBL. Dans ce cas, le serveur renvoie un code d'erreur SMTP permanente au client (554 le plus souvent). Éventuellement, si la requête sur un type d'enregistrement A ne donne rien, un TXT peut être tenté :

Certaines DNSBL maintiennent dans le champ TXT la raison du blocage du client. Mettre en place les DNSBL n'est pas une affaire compliquée. Ça se résume souvent à spécifier un domaine DNS associé à une zone contenant une base de données de spammeurs connus. Sous Postfix (ficher main.cf) :

Exemple :

Efficacité : épure autour de 90% des spams (c'est-à-dire qu'environ 90% des messages à destination de notre MTA viennent de serveurs blacklistés). Seulement à l'Université, nous avons eu des soucis avec des domaines connus comme orange.fr, qui étaient répertoriés dans les blacklists de Spamcop (Spamcop fonctionne sur dénonciation et inscrit régulièrement les MTA utilisés par les hotspots orange.fr ou ceux de laposte.net). Ceci pose le problème de la qualité des blacklists. Certaines fonctionnent, sont limites fascistes, d'autres ne bloquent pratiquement rien. D'après des retours d'expériences sur la mailing list des RSSI de l'enseignement supérieur, il semble que la blacklist offrant la meilleure balance efficacité/pertinence soit Spamhaus. Cependant, au-delà d'un certain volume de résolutions DNS, Spamhaus devient payant. On notera qu'en cas de faux positif, l'expéditeur est notifié proprement : pas de bounce (en tout cas, si les DNSBL sont implémentées sur le premier MTA responsable du domaine) car rejeté au moment de la négociation SMTP.

2.2 Greylist

2.2.2 Théorie

Basé sur le fait que les serveurs de spams ou machines ayant un virus ne gèrent pas les files d'attente de messages en ne réessayant pas un renvoi lors d'un échec temporaire (erreur SMTP 4XX), le greylisting consiste à rejeter temporairement (quelques minutes) tout message. Une telle technique implique évidemment que beaucoup de messages arrivent en retard (c'est un problème potentiel pour des sites envoyant un mail de confirmation d'inscription ayant une faible durée de vie). Ce problème peut être mitigé par l'utilisation de listes blanches (listes de domaines où d'IP bypassant le greylisting).

Pour cela, on forme un triplet (adresse IP de l'expéditeur, adresse e-mail de l'expéditeur, adresse e-mail du destinataire) à partir de tout mail qui arrive.

- Si le triplet est inconnu, on le met dans une base (il devient gris) et on refuse temporairement le mail.

- Si le triplet revient dans un intervalle de temps défini et paramétrable, on l'accepte et on le « blanchit ».

- Si le triplet est blanc (fait partie d'une liste blanche) ou blanchi, on l'accepte.

- Tout triplet gris est détruit au bout d'un certain délai.

- Tout triplet blanchi et non réutilisé est détruit au bout d'un certain délai.

2.2.2 Application

Nous allons arbitrairement utiliser Postgrey pour implémenter le greylist sous Postfix (il existe pléthores d'autres solutions de greylist pour ce MTA). Le fichier de configuration /etc/postfix/main.cf est modifié ainsi :

Paramètres par défaut de Postgrey :

- rejet temporaire : 300 secondes ( = 5 minutes ) ;

- un triplet devient blanc au bout de 5 messages ;

- un triplet blanchi reste blanc 35 jours.

Ces paramètres par défaut convenaient bien en 2005 à l'Université d'Orléans, avec l'élimination de 99% du spam. Mais au fil des années, il a fallu modifier la valeur du rejet temporaire car certains spams revenaient au bout de 301 secondes, sûrement la prise en compte des valeurs par défaut par les spammeurs. Après une longue période à 700 secondes, l'optimum a été trouvé avec un rejet temporaire de 1300 secondes de 7h à 20 h du lundi au vendredi et à 3599 secondes le reste du temps (nuit + week-end). Il est judicieux de mettre le greylisting derrière les autres méthodes antispam type blacklisting.

Efficacité : épure 5 à 10% de spams s'il est utilisé conjointement avec le blacklisting. Jusqu'en 2008, cette méthode était en fait suffisante pour se protéger du spam.

2.3 Filtres bayésiens

Les filtres bayésiens se basent sur les probabilités conditionnelles. Par exemple, sachant que le résultat du lancer d'un dé équilibré est pair, c'est-à-dire que l'on a obtenu deux ou quatre ou six, quelle est la probabilité que le résultat de ce lancer soit deux ? Intuitivement, on trouve 1/3 (1 chance sur 3). La formule générale des probabilités conditionnelles est la suivante :

Formule 1 :

 

 

La probabilité de l'événement A sachant que B est égal à la probabilité de l'intersection des événements A et B sur la probabilité de B. Définissons les trois événements suivants :

- S : le message est un spam ;

- M : le message contient le mot viagra ;

- H : le message n'est pas un spam (événement complémentaire de S, c'est-à-dire que P(S)=1-P(H)).

 

 

Les événements sont de probabilité non nulle. Calculons la probabilité que le message soit un spam (événement S) sachant qu'il contient le mot viagra (événement M). Soit l'équation suivante, d'après la formule 1 :

 

 

Occupons-nous du numérateur :

 

 

P(S) est une donnée connue (généralement fixée par l'antispam aux environs de 80 %). P(M|S) est déterminé par apprentissage une fois qu'il a été nourri avec un certain nombre de messages triés par l'utilisateur (ham et spam).

 

 

soit le nombre de spams divisé par le nombre de mails.

Comme S et H sont disjoints (ils n'ont pas d'éléments en commun), on obtient facilement :

 

 

En utilisant un raisonnement similaire à celui fait pour la quantité P(S inter M) :

 

 

On obtient donc :

 

 

On retombe sur la probabilité qu'un message contenant le mot viagra soit un spam [bayes]. Tous les paramètres de cette équation sont fixés en usine dans l'antispam. La phase d'apprentissage ajuste ces différentes valeurs en fonction de l'environnement. Il existe un certain nombre d'implémentations de Bayes : Bogofilter de Paul Graham [plan4spam] et CRM114. Un système de ce type seul pose de gros problèmes, notamment avec du spam/ham dans une langue autre que le français et rare sur le domaine concerné. Par exemple, si un seul message en portugais est reçu lors de la phase d'apprentissage et qu'il s'avère que c'est un spam, alors tous les messages suivants en portugais risquent d'être catégorisés spams. En revanche, couplé à un système d'apprentissage automatique type Spamassassin, ça fonctionne très bien.

2.4 Spamassassin

2.4.1 Principes généraux

A l'inverse des mécanismes déjà présentés, Spamassassin (que nous nommerons SA par la suite) ne détruit pas forcément les messages (c'est juste une question de réglages). Il tente de séparer le bon grain de l'ivraie en appliquant un mécanisme de notation pour chaque e-mail. Cette notation est basée sur les règles situées dans le répertoire pointé par la variable DEF_RULES_DIR du script SA. Chacune des règles possède un score. Si la somme des scores du message dépasse un certain seuil, le message est considéré comme spam. On y trouve des règles de différents types :

- Blacklists ;

- Pattern matching ;

- Bayes ;

- Modules externes (Razor, Pyzor etc.).

Les blacklists sont built-in dans SA. Elles sont déclarées dans le fichier 20_dnsbl_tests.cf. Par exemple, pour Spamhaus, on retrouve les lignes suivantes :

Ainsi, une requête DNS est faite vers le serveur zen.spamhaus.org pour chaque message transitant par SA. A ce stade, une excellente idée qui ne coûte pas cher est d'installer un cache DNS sur la machine. Nous utilisons dnscache (issu de la suite des outils DNS de DJ Bernstein), qui est un excellent compromis entre performances, facilité d'installation et robustesse [dnscache]. Nous avons intérêt à laisser les DNSRBL activées car SA travaille sur les en-têtes « Received » du message. De cette manière, les MTA intermédiaires sont aussi testés. Pour désactiver une DNSBL particulière, ajoutez les lignes suivantes dans le fichier .spamassassin/user_prefs de l'utilisateur exécutant le script SA :

Le pattern matching travaille à la fois sur les en-têtes et sur le corps du message. Le langage de définition des règles est assez simple. Il définit un triplet constitué d'un domaine d'application de la règle (body, header, uri, rawbody), d'un identifiant et d'une expression régulière. Le domaine d'application header concerne les en-têtes, par exemple :

Cette expression va matcher avec tous les messages dont l'en-tête From vaut news@example.com. Body fait la même chose sur le corps du message. Rawbody travaille sur le message avec son prétraitement par Spamassassin. Principalement, les balises HTML ainsi que les sauts de ligne sont conservés. Enfin, uri matche spécifiquement les URI localisées dans les parties HTML des messages.

Le filtre bayésien de SA repose sur l'apprentissage. La commande sa-learn construit les bases de connaissance de spam (ensemble S) et de ham (ensemble H). SA va décomposer les messages pour analyser la fréquence des mots. Ainsi, par apprentissage statistique, on obtient la probabilité qu'un message soit un spam sachant qu'il contient tel mot. SA dispose aussi d'un mode auto-apprentissage très efficace.

Enfin, les modules externes sont les plugins ajoutés au fil de l'eau pour traiter des choses comme SPF ou DKIM, ou des programmes externes type Razor et Pyzor, que nous allons détailler par la suite.

2.4.2 Intégration

SA est un outil très souple. Il est disponible sous deux formes : un script Perl ou un programme qui charge les règles en mémoire de manière résidente, nommé Spamd (à ne pas confondre avec OpenBSD Spamd). Cette implémentation optimisée comprend donc deux parties : Spamd et Spamc. Spamc est un client écrit en C qui attend les messages à traiter sur l'entrée standard pour les soumettre au démon Spamd. On peut choisir de l'intégrer à de multiples niveaux : MTA, MDA et MUA.

Dans le premier cas, on travaille au niveau global. Tout le trafic mail sera analysé par la même instance de SA : c'est-à-dire par le même jeu de règles et la même base d'apprentissage du filtre bayésien. Lorsque l'on intègre SA au niveau du MTA, deux choix se posent : utiliser un content filter type Amavisd-new ou s'appuyer sur Spamd. L'utilisation d'un content filter est judicieuse si l'objectif premier de la passerelle antispam n'est pas la performance, mais la polyvalence (par exemple, si l'on souhaite embarquer un antivirus en plus de l'antispam sur la même machine). En effet, Amavisd-new ne travaille qu'avec le script Perl SA. Dans ce cas, l'instance d'Amavisd-new est en écoute sur 127.0.0.1:10026. On doit le déclarer dans le main.cf de Postfix via la variable content_filter. Ensuite, on redéfinit une instance locale de smtpd (par exemple, 127.0.0.1:10025) pour réinjecter le trafic une fois analysé par Amavisd-new [amavis].

 

 

Si la passerelle antispam est dédiée à l'exécution de SA, alors on se tournera plutôt vers le couple Spamc/Spamd. Dans ce cas, on se place sur une inspection after-queue (cf note). Un démon Spamd doit tourner sur la machine. Spamc est ensuite invoqué par le processus master de Postfix pour dialoguer avec le démon via un socket UNIX. Cette solution est intéressante pour des machines dédiées à l'exécution de SA.

Dans les second et dernier cas, SA est exécuté respectivement au moment de la livraison du message dans la BAL de l'utilisateur (via, par exemple, le MDA procmail [procmail]) et au téléchargement du message dans le MUA. Nous avons fait le choix d'utiliser SA au niveau du MTA via Amavisd-new sans utiliser l'apprentissage bayésien, faute de mécanismes de collecte du spam/ham efficaces pour l'entraîner. Dans cette configuration, nous détections comme spams 3 % des messages résiduels (derrière les blacklist et greylist).

3. Protection contre l'extrusion de spams

L'extrusion de spams résulte de la compromission des machines du réseau interne. Ces machines tentent soit de se connecter directement sur le port TCP/25 de serveurs distants, soit d'utiliser vos MTA émetteurs pour envoyer du spam. Le premier cas est simple à bloquer : interdiction de sortir sur le port TCP/25 au niveau du pare-feu. Pour le deuxième, c'est un peu plus compliqué, il faut authentifier la source avant de relayer. On a deux types de populations amenées à utiliser un service de relais de messagerie authentifié : les non interactifs (le serveur qui envoie son logwatch journalier) et les interactifs (l'utilisateur et son MUA).

3.1 Authentifier les sessions entre MTA locaux au site

Imaginons une organisation découpée en sites locaux. Chaque site dispose de son propre MTA chargé de relayer les messages des usagers. Ce MTA local doit passer par un MTA frontal qui embarque, par exemple, un antivirus. On doit donc authentifier le MTA local sur le MTA frontal de manière transparente. La première chose qui vient à l'esprit est de filtrer en fonction des adresses IP source. Un raffinement immédiat est d'utiliser les certificats pour authentifier les MTA de manière bilatérale. Dans le cas de Postfix, le support de TLS est natif. Si toutefois votre MTA n'en est pas capable, vous pouvez utiliser des systèmes de tunnel léger comme stunnel [stunnel]. La partie TLS de Postfix est gérée par un programme interagissant avec les composants smtpd et smtp, nommé tlsmgr. Son rôle est double : il répond aux requêtes de récupération des données de sessions TLS formulées par smtpd et smtp, et il interagit avec le PRNG (Pseudo Random Number Generator).

 

 

Pour l'activer, il faut ajouter quelques options dans le main.cf. Côté serveur :

Cette configuration force l'utilisation de TLS (smtpd_tls_security_server), demande un certificat au client (smtpd_tls_req_ccert) et précise la localisation de la clé privée et du certificat du serveur (smtpd_tls_key_file et smtpd_tls_cert_file). Côté client :

On localise la clé privée et le certificat sur le client. A ce stade, nous avons authentifié les machines bilatéralement, passons aux clients interactifs.

3.2 SMTP émetteur authentifié

Nous allons évoquer deux méthodes pour authentifier les utilisateurs sur le MTA. La première est la plus simple à mettre en place pour l'administrateur, vu qu'elle s'appuie sur LDAP. La seconde est la plus vendable aux utilisateurs finaux, car elle s'appuie sur du SSO via Kerberos. En préambule, voyons les méthodes d'authentification que notre Postfix sait utiliser :

Pas de trace de LDAP, il va donc falloir passer par la SASL (Simple Authentication and Security Layer). Cette couche implémente un certain nombre de méthodes d'authentification (CRAM-MD5, GSSAPI, etc.). Tout programme compilé avec le support de la SASL acquiert la capacité d'utiliser ces méthodes. Côté main.cf :

Active la SASL. Ensuite, il faut s'assurer que l'on force bien l'utilisation de TLS avant de faire une quelconque authentification :

Il faut aussi préciser à Postfix qu'il va utiliser saslauthd (démon réalisant les authentifications via la SASL) pour vérifier les authentifiants (credentials) soumis par les clients :

Enfin, on vérifie que le mécanisme d'authentification utilisé par saslauthd est bien LDAP (fichier /etc/default/saslauthd sous Debian) et que le fichier saslauthd.conf contient bien toutes les informations pour interroger notre serveur LDAP.

Cette solution d'authentification est très souple, mais demande à l'utilisateur de saisir un mot de passe pour envoyer ses e-mails. C'est parfois acceptable pour l'utilisateur lorsqu'il se connecte au MTA émetteur depuis l'extérieur du réseau, mais beaucoup moins lorsqu'il se connecte depuis le réseau interne. Cet état de fait explique le recours encore massif à l'acceptation du relais de messagerie par le MTA sur l'IP source. Une solution est de déployer Kerberos pour authentifier les clients de manière transparente [kerb]. En résumé, nous avons une authentification et un chiffrement bilatéral TLS pour les interactions MTA ↔ MTA et une authentification LDAP ou Kerberos sur un tunnel TLS pour les interactions MUA ↔ MTA.

4. Les systèmes originaux antispam

4.1 OpenBSD Spamd

Comme son nom l'indique, OpenBSD Spamd [obsdspamd] est un système antispam disponible dans le système de base d'OpenBSD. Spamd est un démon qui va s'intercaler entre le monde extérieur et votre MTA en simulant un faux MTA. La passerelle reçoit le mail (1), le trafic est redirigé vers Spamd (2). Spamd le traite et met éventuellement à jour les règles de filtrage de PF (3). Si le mail est licite, alors le vrai MTA reçoit le message.

 

 

Les mécanismes implémentés par Spamd sont assez réduits. Ils sont au nombre de trois : blacklists, greylisting et spamtrap.

4.1.1 Blacklists

Les blacklists résultent de la composition de plusieurs listes d'IP de MTA spammeurs. Ces listes sont récupérées soit sur des systèmes distants via HTTP ou FTP, soit dans un fichier plat local. Une fois constituées, ces blacklists sont chargées dans la table <spamd> de PF via l'utilitaire spamd-setup. On notera que Spamd ne propose pas de travailler avec DNSRBL. Il est possible que le fait de s'appuyer sur une résolution DNS pour faire prendre une décision au pare-feu soit rédhibitoire pour les développeurs d'OpenBSD.

4.1.2 Greylisting

Pour le greylisting, rien de spécial sur le fonctionnement. Spamd maintient une base de données des triplets de connexion nommée spamdb. Si un serveur ne réémet pas le message dans un temps acceptable, il est passé dans la blacklist. Si il réussit, il est mis en whitelist. Il n'aura pas à repasser par le processus d'élimination lors de la prochaine connexion, mais sera directement redirigé vers le MTA. La récupération des logs de greylisting se fait via l'outil spamdb.

Cet enregistrement est composé de 10 champs :

- le type d'enregistrement (WHITE ou GREY) ;

- l'IP de l'émetteur du message ;

- le message HELO envoyé par l'émetteur ;

- adresse mail source ;

- adresse mail destination ;

- date de la première entrée dans la spamdb (première tentative de connexion) ;

- date à laquelle l'enregistrement sera promu sur liste blanche ;

- date d'expiration de l'enregistrement dans la spamdb ;

- nombre de fois où une telle connexion a reçu une « temporary failure » de Spamd ;

- nombre de fois où une telle connexion est passée sur liste blanche.

Enfin, la spamdb est synchronisable entre plusieurs machines dans une optique de redondance.

4.1.3 Spamtrap + greylisting = greytrapping

Le spamtrap est l'action de dédier des adresses e-mail à la réception du spam (des adresses non utilisées ou présentes sur des listes de spammeurs font l'affaire). Ces adresses sacrifiées sont insérées dans la spamdb via une commande spamdb :

Ensuite, si une machine présente en greylist tente d'envoyer un mail à l'adresse de spamtrap marketing@garnett.fr, alors elle est ajoutée dans la table PF <spamd-greytrap>, qui blacklist pendant 24h. Cette combinaison du spamtrap et du greylisting est appelée greytrapping.

4.2 Les systèmes collaboratifs

Nous allons étudier quatre systèmes collaboratifs : DCC, Razor, Pyzor et Dspam. Les trois premiers systèmes sont dits collaboratifs car l'antispam s'appuyant sur ces filtres peut remonter les spams reçus (le plus souvent sous forme d'empreintes) à un système central. La base ainsi constituée est ensuite interrogée par le client, par exemple, un SA disposant des trois modules sus-nommés, pour déterminer si le message en cours d'examen est un spam. Le principe est de compter combien de fois le système a vu passer le message en cours d'examen. Si la fréquence du message dépasse un certain seuil, le message est identifié comme « bulk mail », ou encore envoi massif, donc spam. Les différences entre les trois produits reposent sur :

- la licence ;

- le processus de collecte ;

- l'algorithme utilisé pour confronter le message examiné à la base de connaissance.

Pour Dspam, l'objectif est un peu différent. C'est un filtre bayésien dont la phase d'apprentissage est collaborative.

4.2.1 DCC

DCC (Distributed Checksum Clearinghouse) est distribué sous deux formes : libre (pour les particuliers et les sociétés dont l'activité n'a rien à voir avec l'analyse de flux de messagerie) et commerciale. Le client DCC remonte chaque message entrant au serveur, il ne cherche pas à déterminer si c'est un spam ou un ham. Il ne soumet pas une simple empreinte du message. Un traitement aussi simpliste ne résisterait pas aux altérations mineures (ajouts d'espaces, modification des liens publicitaires, etc.). Il fait d'abord une empreinte classique des sections suivantes du message : IP du MTA source, Env_From, From, Message-ID, le dernier champ Received et du corps.

Ensuite, il applique un algorithme de fuzzy checksums. La façon dont fonctionne cet algorithme n'est pas claire et peu (ou pas) documentée. De plus, il évolue pour s'adapter aux nouvelles formes de spams. L'idée principale est de ne prendre l'empreinte que des parties fixes du message. Par exemple, s’il commence par « cher nico@garnett.fr » et qu'il fait moins de 5 Ko, alors on prend l'empreinte de la seconde ligne et le checksum « Fuz1 » est ajouté dans la demande du client. Si le message pesait plus que 5 Ko, on ajouterait également à la demande un checksum « Fuz2 », qui serait l'empreinte de la 12e ligne.

La partie commerciale de DCC fournit aux clients une base de réputation. La réputation concerne un MTA, elle est calculée en faisant le rapport entre la quantité totale de messages envoyés et le nombre d'envois massifs détectés. Une réputation de 30% signifie que 30% du trafic du MTA concerne de l'envoi massif de messages.

4.2.2 Razor

Razor diffère de DCC au niveau de la collecte. L'utilisateur doit soumettre manuellement une empreinte du corps de ses spams via razor-report. En général on scripte plutôt derrière une adresse de spamtrap. La base de données distribuée Razor ne contient donc que des empreintes de spams (contrairement à DCC, qui lui, contient des e-mails sans assertions sur le fait que ce soient des spams ou des hams). Razor opère avec deux moteurs. Le premier, e4, opère sur des sous-sections de chaque composant MIME du message en calculant leur empreinte SHA1. Le second, e8, travaille sur les URL.

Le problème qui se pose immédiatement est la confiance que l'on doit accorder à chaque rapport. Ainsi, depuis la version 2, la soumission nécessite que l'utilisateur dispose d'une clé GPG pour signer ses rapports. En comparant les soumissions effectuées via chaque clé, Razor maintient une base de confiance de ses signatures (notées de 0 à 100). C'est à l'utilisateur de définir le seuil de confiance à partir duquel il veut travailler.

Razor est un projet libre. Cependant, la société Cloudmark fondée par Vipul Ved Prakash, inventeur de Razor, propose des produits et services basés sur celui-ci.

4.2.3 Pyzor

Pyzor est un projet totalement libre implémentant les principes de Razor et développé en Python. La principale différence par rapport à Razor est dans le processus de soumission. Pyzor n'utilise pas GNUPG (c'est-à-dire que les soumissions ne sont pas signées). Il n'implémente pas non plus de mécanismes de whitelist (liste d'adresses e-mail pour lesquelles le test n'est pas réalisé).

4.2.4 Dspam

Dspam est un logiciel libre constitué d'une bibliothèque (libdspam), de commandes et interfaces web afin d'offrir des filtres antispam adaptés à chaque utilisateur. Par ses filtres bayésiens, il est capable d'apprendre grâce aux forwards des utilisateurs à une adresse dédiée. Il stocke dans une base de données les signatures des spams. Il fonctionne avec plusieurs types de bases de données (SQLite, Berkeley DB, MySQL, PostgreSQL, Oracle) et plusieurs MTA (Sendmail, Postfix, Exim4, etc.).

Il peut être installé comme passerelle MTA servant à filtrer les spams. Dans ce cas, il n'est plus nécessaire d'activer le filtrage bayésien côté SA.

4.3 Qsmtpd

Qsmtpd est un programme en Perl traitant la partie transaction SMTP (il ne s'occupe pas du tout des aspects livraison/relais). Dans Qsmtpd [qsmtpd], il est dit qu'il est le mod_perl du mail. Les buts de ce projet sont multiples :

- s'intégrer facilement dans une infrastructure existante ;

- un système de plugins évolutifs pour filtrer les mails ;

- performance/disponibilité (il fonctionne nativement avec les daemontools de DJB, un fichier run est même fourni dans l'archive).

Le plus simple pour intégrer Qsmtpd est de l'installer en coupure du MTA réel. Dès lors, les mails vont devoir passer par ses plugins avant d'atteindre le MTA pour être livrés ou relayés. Les principaux plugins sont les suivants :

- check_earlytalker : identification des machines zombies qui parlent plus tôt qu'elles ne devraient lors de la session SMTP. Le nombre de faux positifs est zéro ;

- check_spamhelo : des contrôles sont faits sur l'argument de la commande HELO, tels que la propre IP du serveur, le propre nom de domaine DNS, etc. ;

- dnsbl : contient une liste de DNSBL à consulter ;

- virus/* : branche un antivirus sur Qsmtpd, on peut en chaîner plusieurs ;

- ident/p0f : prise d'empreinte passive de l'OS initiant la connexion vers Qsmtpd.

Qsmtpd est un outil très pratique pour mettre en place un filtrage antispam sur des systèmes de messagerie qui en étaient dépourvus. Il est assez cutting-edge sur l'implémentation des mécanismes antispam. Il a été le premier à intégrer SPF, URIBL (contrôle dans le corps du message des URL présentes pour confrontation avec une blacklist) ainsi que la méthode early_talker.

5. Les perspectives

5.1 SPF et SenderID

5.1.1 SPF

Comme le serveur expéditeur peut facilement se faire passer pour un nom de domaine usurpé, SPF (Sender Policy Framework) est une norme (RFC 4408) qui définit par un enregistrement DNS les adresses IP des serveurs autorisés à envoyer au nom du domaine par la commande MAIL FROM ou HELO. Lors d'une session SMTP, le serveur de réception vérifie par une requête DNS l'enregistrement TXT du domaine concerné.

Voici, par exemple, l'enregistrement SPF (type TXT) sur le DNS de l'Université d'Orléans :

Signification de la syntaxe [SPF] :

- v = version de SPF. Ce paramètre doit être à spf1 ;

- ip4 = autorisation de la classe IPv4 à émettre ;

- mx = tous les serveurs mx du domaine sont autorisés ;

- all = toute autre machine est interdite.

5.1.2 SenderID

SenderID ressemble un peu à SPF du fait qu'il est aussi normalisé (RFC 4406) et définit par un enregistrement DNS les adresses IP des serveurs autorisés à envoyer au nom du domaine, mais diffère par les champs testés. Cette fois-ci, ce sont les champs From, Sender, Resent-From et Resent-Sender qui sont vérifiés lors d'une session SMTP, après une requête DNS de l'enregistrement TXT du domaine concerné. Ces 4 champs sont testés avec un algorithme PRA (Purported Responsible Address, dans la RFC 4407) conservant le premier en-tête non vide.

La syntaxe SenderID est pratiquement identique, seule diffère la version v=spf2.

On peut préciser le type de version suivant le champ que l'on veut tester :

Microsoft pousse à son utilisation avec ses serveurs Exchange (Microsoft est à l'origine de ce protocole dérivé de SPF).

Les systèmes se basant sur une politique qualifiant tel ou tel émetteur en fonction de l'IP pose quand même un soucis en cas de redirection (forward) de messagerie. Si A envoie un message à B et que B a configuré une redirection vers C, C va interroger l'enregistrement SPF de A alors que c'est un MTA de B qui lui a envoyé le message. Ainsi, si on utilise un système antispam avec des scores, il est préférable de considérer ce genre de système comme du bonus (si c'est OK, on réduit le score de spam, sinon c'est 0).

5.2 DKIM

DKIM (Domain Key Identified Mail) est un mécanisme de signature d'e-mail utilisant la cryptographie asymétrique. Un couple clé privée/clé publique est généré pour chaque serveur habilité à envoyer des e-mails à d'autres domaines. Un milter doit être installé sur le(s) MTA(s) émetteurs [ref nécessaire] pour traiter les messages expédiés. Le milter crée une empreinte (SHA1 ou SHA256) composée du message et de quelques en-têtes. Il signe ensuite cette empreinte avec la clé privée. Les informations DKIM sont ajoutées au message :

Le champ DKIM-Signature est décomposé en tags (en rouge dans l'exemple). Signification des tags :

- v= version de DKIM. Ce paramètre doit être à 1 ;

- a= algorithme de hachage utilisé pour la génération de la signature ;

- c= algorithmes de canonisation (séparés par un slash) appliquées respectivement aux en-têtes et au corps du message. On a deux algorithmes, simple et relaxed. Sans entrer dans les détails, « simple » prépare les données pour la signature en pratiquant des altérations (suppression de lignes blanches, passage de la casse en minuscule, etc.) plus légères que « relaxed » ;

- d= domaine DNS cible des demandes d'obtention de clé publique ;

- s= subdivision de l'espace de nommage défini par d= ;

- h= liste des en-têtes à signer ;

- bh= empreinte du message canonisé ;

- b= signature des en-têtes canonisés.

Une signature DKIM indique au destinataire qu'il va pouvoir vérifier plusieurs choses :

- l'e-mail est signé par un MTA habilité pour le domaine DNS de l'émetteur (ou du moins la clé publique associée est bien distribuée par le DNS) ;

- les en-têtes spécifiés par le tag h= du champ DKIM-Signature n'ont pas été modifiés entre le MTA signataire et le destinataire.

Conclusion

La lutte contre le spam doit suivre l'évolution des techniques utilisées par les spammeurs.

Ainsi, à l'Université d'Orléans, en 2005-2006, le greylisting suffisait pour éradiquer le spam.

Puis il a fallu ajouter du blacklisting et certaines règles Postfix pour améliorer le système antispam. Le marquage avec SA est venu compléter la panoplie.

 

 

En complément du filtrage local, on voit apparaître des filtres nationaux. Aux dernières JRES (Journées Réseaux de l'Enseignement Supérieur), le GIP (Groupement d'Intérêts Publiques), RENATER a présenté un antispam national [renspam]. Pour s'y attacher, les organismes devront le déclarer comme MX. Il devrait disposer de fonctions de délégation d'administration (mise à disposition des logs, administration décentralisée pour laisser aux établissements la maîtrise de règles spécifiques de filtrage, etc.).

Remerciements

Nous remercions Pierre Debs et Jean-Baptiste Gouéré, maîtres de conférence au MAPMO, pour leurs explications sur Bayes. Nous remercions également Cédric Foll pour sa relecture extrêmement pédagogique et efficace.

Références

[amavis] : http://wiki.apache.org/spamassassin/IntegratedInPostfixWithAmavis

[bayes] : http://en.wikipedia.org/wiki/Bayesian_spam_filtering

[colo] : http://www.securityfocus.com/brief/855

[kerb] : http://blog.garnett.fr/?p=327

[obsdspamd] : http://www.unixgarden.com/index.php/administration-systeme/anti-spam-adaptable-et-performant-avec-openbsd-et-spamd

[plan4spam] : http://www.paulgraham.com/spam.html

[procmail] : http://wiki.apache.org/spamassassin/UsedViaProcmail

[smtpd] : http://www.oreillynet.com/pub/a/sysadmin/2005/09/15/qpsmtpd.html

[renspam] : https://2009.jres.org/planning_files/summary/html/37.htm

[spamd] : http://wiki.apache.org/spamassassin/IntegratedSpamdInPostfix

[SPF] : http://www.openspf.org

[sshbrute] : http://blog.garnett.fr/?p=4

[stunnel] : Tunnel et VPN légers. MISC n°10.