Protéger son infrastructure du spam

Magazine
Marque
MISC
Numéro
48
|
Mois de parution
mars 2010
|
Domaines


Résumé

En matière de lutte contre le spam, il faut distinguer différents niveaux d'action : de la mise hors service de réseaux entiers de spammeurs (affaire McColo [colo]) aux mécanismes de sécurité en frontal de l'infrastructure de messagerie. Dans cet article, nous allons présenter différents outils libres pour vous aider à mettre en place (ou à optimiser) de tels filtres.


Body

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.

 

f1

 

Figure 1 : Acheminement du courrier électronique

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).

 

f2

 

Figure 2 : Architecture de Postfix

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é) :

1265059581.978307 00:14:22:1b:c2:05 > 00:16:3e:53:ed:23, ethertype IPv4 (0x0800), length 87: @IP_BLACK.60325 > @IP_DNS.53: 61620+ A? 22.84.62.187.bl.spamcop.net. (45)

1265059581.999310 00:16:3e:53:ed:23 > 00:14:22:1b:c2:05, ethertype IPv4 (0x0800), length 140: @IP_DNS.53 > @IP_BLACK.60325: 61620 NXDomain 0/1/0 (98)

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é :

1265057993.348805 00:14:22:1b:c2:05 > 00:16:3e:53:ed:23, ethertype IPv4 (0x0800), length 92: @IP_BLACK.57808 > @IP_DNS.53: 12881+ A? 143.227.253.222.pbl.spamhaus.org. (50)

1265057993.349298 00:14:22:1b:c2:05 > 00:16:3e:53:ed:23, ethertype IPv4 (0x0800), length 92: @IP_BLACK.57808 > @IP_DNS.53: 12882+ TXT? 143.227.253.222.pbl.spamhaus.org. (50)

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) :

smtpd_recipient_restrictions = ….. , reject_rbl_client liste-rbl1,reject_rbl_client liste-rbl2,reject_rhsbl_client liste-dnsbl

Exemple :

smtpd_recipient_restrictions = ….,reject_rbl_client cbl.abuseat.org,reject_rbl_client bl.spamcop.net,...,reject_rhsbl_client rhsbl.ahbl.org

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 :

smtpd_recipient_restrictions = ….. , check_policy_service inet:127.0.0.1:60000

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 :

 

formule1

 

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)).

 

f3

 

Figure 3 : Représentation dans l'espace des différents ensembles

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 :

 

formule2

 

Occupons-nous du numérateur :

 

formule3

 

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).

 

formule4

 

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 :

 

formule5

 

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

 

formule6

 

On obtient donc :

 

formule7

 

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 :

header __RCVD_IN_ZEN eval:check_rbl('zen', 'zen.spamhaus.org.')

describe __RCVD_IN_ZEN Received via a relay in Spamhaus Zen

tflags __RCVD_IN_ZEN net

reuse __RCVD_IN_ZEN

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 :

score RCVD_IN_ZEN 0

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 :

header __LOCAL_FROM_NEWS From ~= /news@example\.com/i

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].

 

f4

 

Figure 4 : Amavisd-new en content filter

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.

Postfix after-queue vs before-queue

L'inspection des messages transitant dans Postfix peut s'effectuer à deux endroits : avant la file d'attente (before-queue) ou après acceptation dans la file (after-queue). L'avantage de l'inspection before-queue est que la connexion est rejetée avant la fin de la session SMTP. La responsabilité de l'acheminement reste donc à la charge du client. L'inconvénient est que le client attend une réponse du serveur dans un certain laps de temps. Or, plus le système est occupé à filtrer les e-mails, plus il augmente sa latence de réponse aux clients. On a donc une limitation du nombre de messages que le serveur peut traiter. De plus, il faut bien dimensionner le nombre de connexions qu'acceptera le MTA en fonction de la consommation des ressources par le filtre.

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).

 

f5

 

Figure 5 : Support de TLS dans Postfix

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

smtpd_tls_security_server = encrypt

smtpd_tls_req_ccert = yes

smtpd_tls_cert_file = /etc/postfix/cert.pem

smtpd_tls_key_file = /etc/postfix/key.pem

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 :

smtp_tls_cert_file = /etc/postfix/cert.pem

smtp_tls_key_file = /etc/postfix/cert.pem

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 :

% telnet mailtest.mondomaine 25

220 mailtest.mondomaine ESMTP Postfix (Debian/GNU)

ehlo mailtest.mondomaine

250-mailtest.mondomaine

...

250-AUTH GSSAPI DIGEST-MD5 NTLM CRAM-MD5 PLAIN LOGIN

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 :

smtpd_sasl_auth_enable=yes

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

smtpd_enforce_tls=yes

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 :

pwcheck_method: saslauthd

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.

Note sur les clients Outlook

Le STARTTLS ne fonctionne pas avec tous les clients Outlook. Pour contenter tout le monde, il est possible d'activer un smtpd dedié sur le port 465, qui contient l'option smtpd_tls_wrappermode=yes désactivant le support du STARTTLS sur cette instance de smtpd.

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.

 

f6

 

Figure 6 : Spamd

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.

Les tables de PF

Une table PF est une liste d'adresses IP. La spécificité est que le temps de résolution dans une table de 50 éléments est très proche de celui pour 50 000. On utilise souvent des tables pour bloquer les nuisibles (ici, des spammeurs, mais aussi des bruteforceurs SSH [sshbrute]). On notera que ces tables son manipulables (ajouts/suppressions d'enregistrements) à chaud et sans relancer PF.

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.

# spamdb | grep nico@garnett.fr

GREY|62.209.218.70|usgs.gov|<jraber@valkyrie.net>|<nico@garnett.fr>|1194181594|1194195994|1194195994|3|0

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 :

spamdb -T -a 'marketing@garnett.fr'

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 :

univ-orleans.fr. IN TXT "v=spf1 mx ip4:194.167.30.1/24 -all"

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 :

"spf2.0/pra", "spf2.0/mfrom", or "spf2.0/mfrom,pra"

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 :

DKIM-Signature: v=1 ; a=rsa-sha256 ; c=relaxed/relaxed; d=gmail.com ; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=3oWIZBGzUitYn/n2oMTvmRjjEkmxlu2Og36BfNxtM2s= ; b=hu5Bds8I/SATjHd2hhfm7hpkIWElRB2AEUdepWVy849DURCspamzyq8RU+MAsLe54d0eAmpROxYT5Fp4zT0+SsAoIUmgYzgKKYJxllt5gY9yzF+xapx25/lJGsRkzd8h9jL5ZgTQRJD3SeSNf8iMX+3/2KWGxs5NwN2oAEW3Tic=

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.

 

f7

 

Figure 7 : Lutte contre le spam à l'Université d'Orléans

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.

 

Sur le même sujet

Un œil technique sur les sanctions de la CNIL

Magazine
Marque
MISC
Numéro
108
|
Mois de parution
mars 2020
|
Domaines
Résumé

Près de trois quarts des sanctions prononcées par la Commission Nationale de l’Informatique et des Libertés (CNIL) ont parmi leurs causes des vulnérabilités techniques de sécurité. À partir de ce constat, et au prisme de notre expérience à la fois en cybersécurité technique et en protection des données à caractère personnel, nous avons analysé les sanctions de la CNIL publiées sur le site https://www.legifrance.gouv.fr/. Nous avons notamment établi une correspondance avec les catégories de vulnérabilités techniques identifiées dans la nomenclature du top 10 de l'OWASP 2017 (Open Web Application Security Project). Nous avons également étudié les fuites de données majeures survenues en Europe et dans le monde. Il en ressort que les vulnérabilités les plus communes sont liées à l’authentification, au contrôle d’accès et à la protection des données au repos et en transit.

De l’audit de code pendant un Red Team ?

Magazine
Marque
MISC
Numéro
108
|
Mois de parution
mars 2020
|
Domaines
Résumé

Pendant un Red Team, l’exhaustivité des découvertes est mise de côté pour privilégier l’efficacité en se concentrant sur l’identification des vulnérabilités à fort impact permettant de mettre rapidement un pied dans le système d’information ciblé.

Tomoyo, le contrôle d’accès facile

Magazine
Marque
GNU/Linux Magazine
Numéro
235
|
Mois de parution
mars 2020
|
Domaines
Résumé

Par un contrôle fin des accès aux fichiers, les logiciels de type Mandatory Access Control (MAC) permettent de lutter efficacement contre le piratage et le vol de données. Tomoyo-linux propose une alternative simple d’utilisation à SELinux.

KeeRest : mettez du DevOps dans votre KeePass

Magazine
Marque
MISC
Numéro
108
|
Mois de parution
mars 2020
|
Domaines
Résumé

Nous avions vu dans MISC n°103 comment déployer une base KeePass en mode SaaS ciblant les particuliers ou de petits périmètres professionnels. Dans un autre monde, les pratiques DevOps se démocratisent et demandent d’augmenter l’agilité des développements tout en réduisant les délais de mise en production. Cet article est le fruit d’une collaboration entre un DevOps et un ingénieur SSI pour voir de quelle manière il est possible de tirer profit de KeePass dans ces environnements.

JsItBad : détecter du JavaScript malveillant sans l’exécuter

Magazine
Marque
MISC
Numéro
108
|
Mois de parution
mars 2020
|
Domaines
Résumé

C’est théoriquement impossible, et pourtant c’est faisable en pratique. En s’inspirant d’une technique d’apprentissage statistique (Machine Learning) habituellement réservée au traitement du langage naturel, il est possible de déterminer avec une très grande précision si un bout de code en JavaScript est malveillant. Ces résultats s’étendent naturellement à tout langage interprété, mais sont mis en défaut par l’arrivée du WebAssembly.

Générez vos badges avec Badgen

Magazine
Marque
Linux Pratique
Numéro
118
|
Mois de parution
mars 2020
|
Domaines
Résumé

Si vous êtes un habitué de GitHub, vous avez sûrement vu ces petits badges d'information sur les licences, le nombre de téléchargements ou encore la version. Vous aimeriez générer ce style de badges facilement et rapidement pour vos projets ? Alors Badgen est fait pour vous ! Découvrons ses différentes versions ensemble.

Par le même auteur

Surveillez votre système pour prévenir et détecter toute action malveillante

Magazine
Marque
Linux Pratique
HS n°
Numéro
46
|
Mois de parution
octobre 2019
|
Domaines
Résumé
Wazuh est un fork libre du projet OSSEC qui appartient à la famille des HIDS (Host Intrusion Detection System). Ces systèmes de détection d’intrusions vont surveiller les logs applicatifs, les appels système ainsi que le noyau pour tenter de détecter des compromissions de l’OS.

Installation et configuration d’un annuaire OpenLDAP

Magazine
Marque
Linux Pratique
Numéro
115
|
Mois de parution
septembre 2019
|
Domaines
Résumé
OpenLDAP est une implémentation libre du standard d’interrogation et de modification d’annuaire LDAP. Cet article ambitionne de vous donner les clés pour centraliser vos utilisateurs Linux dans un annuaire LDAP. Cependant, les connaissances acquises pourront également vous servir dans le monde Microsoft, car Active Directory s’appuie également sur le protocole LDAP.

Authentification de l’accès à votre réseau : mise en place d’un portail captif et d’un service 802.1X

Magazine
Marque
Linux Pratique
Numéro
114
|
Mois de parution
juillet 2019
|
Domaines
Résumé
Un portail captif est un élément de contrôle mandataire régulant l’accès au réseau pour les clients équipés d’un navigateur web. Dans cet article, nous allons voir comment intégrer cet élément dans une infrastructure pour authentifier les clients connectés en Wi-Fi avant leur accès effectif au réseau extérieur. Nous allons également présenter le 802.1X qui vise à authentifier les utilisateurs avant tout accès au réseau.