La prochaine étape dans la lutte contre le spam : les listes grises
par Evan Harris
traduction de Sébastien Namèche

Copyright © 2003-2004.
Permission to reprint and translate is granted provided this copyright notice is kept intact.
Autorisation de reproduction et traduction accordée sous réserve que cette notice de copyright demeure intacte.

Version du document original : 2003-08-21
Version de la traduction : 2004-06-11

Note du traducteur :
Ce texte est une traduction du document de référence qui décrit la technique des listes grises et écrit par Evan Harris. L'URL de la version anglaise originale est : http://projects.puremagic.com/greylisting/whitepaper.html

Introduction

Ce document expose une nouvelle méthode particulièrement efficace permettant d'augmenter significativement la capacité des systèmes de messagerie à réduire la quantité de spam qu'ils reçoivent et délivrent aux utilisateurs. Le nom de cette technique a été choisi pour une raison qui deviendra évidente au fil de ce document.

L'élaboration des listes grises a été étudiée de manière à répondre, dès l'origine, aux critères suivants :

  1. rendre leur mise en œuvre transparente pour les utilisateurs ;
  2. faire en sorte qu'il soit difficile pour les spammeurs de contourner le mécanisme ;
  3. limiter la maintenance qu'il exige de la part des utilisateurs et des administrateurs.

Bien que cela soit généralement efficace, filtrer les messages sur le poste de l'utilisateur présente plusieurs inconvénients majeurs qui rendent cette option indésirable dans la lutte perpétuelle contre le spam. Voici quelques-uns de ces inconvénients :

  1. aucune notification n'est envoyée aux expéditeurs de messages légitimes si ceux-ci ont été malencontreusement identifiés comme du spam ;
  2. le coût en ressources de traitement est quasiment entièrement imputé au système du destinataire plutôt qu'à celui du spammeur ;
  3. aucune mesure réellement dissuasive n'est mise en œuvre pour empêcher les spammeurs de dépenser notre temps et nos ressources.

De tout cela, il découle que les listes grises ont été pensées de manière à être implémentées au niveau des MTA, là où il nous est possible de causer le plus de tort aux spammeurs.

Dans le dessein de tester et valider les listes grises, un exemple d'implémentation a été écrit pour un filtre intervenant un niveau du MTA (Mail Transfer Agent). Le source en est disponible sur une page pointée par un lien plus bas dans ce document. Au fur et à mesure que d'autres implémentations ou outils additionnels deviendront disponibles, ils seront également référencés.

Le concept des listes grises a été initialement testé sur quelques serveurs de messagerie de taille modeste (moins de 100 utilisateurs mais avec un ensemble très diversifié d'expéditeurs du monde entier générant un volume supérieur à 10 0000 tentatives de transmission de message par jour). Les listes grises ont été conçues pour s'adapter à la montée en charge et avoir un impact minimal sur les utilisateurs et les administrateurs. Elles devraient donc pouvoir être tolérées dans un grand nombre d'environnements. Les performances générales dépendront évidemment des détails de l'implémentation.

À ce jour, les listes grises ont été mises en œuvre sur un grand nombre de serveurs de messagerie, y compris sur des sytèmes qui gèrent plusieurs millions de messages par jour. Et, chaque jour, des nouvelles implémentations sont recensées.

La technique des listes grises décrite dans ce document est complémentaire aux systèmes de filtrage du spam déjà implémentés ou qui viendront à exister, il ne s'agit de remplacer les mécanismes existants. En fait, on s'attend à ce que les spammeurs tentent de réduire l'efficacité de ces mécanismes de filtrage, les listes grises ont été créées pour restreindre les possibilités qui leur sont offertes pour y parvenir.

Un intérêt tout particulier des listes grises est que les seules méthodes qui permettraient de les contourner permettent d'augmenter l'efficacité des autres techniques de filtrage de manière significative (essentiellement celles basées sur le DNS et autres méthodes fondées sur les listes noires d'adresses IP) même après que les spammeurs se soient adaptés.

La technique des listes grises

Principes généraux

Les listes grises ont été nommées ainsi car il s'agit d'une technique hybride entre les listes blanches et les listes noires et dont la maintenance est automatique. Un élément fondamental de cette technique est justement cette capacité de maintenance automatique.

La technique des listes grises et très simple. Seules trois informations sont considérées (auxquelles non donnerons le nom de « triplet » dans la suite de ce document) lors de la tentative de remise d'un message :

  1. l'adresse IP de la machine qui tente d'envoyer le message ;
  2. l'adresse d'enveloppe de l'expéditeur ;
  3. l'adresse d'enveloppe du destinataire.

Un triplet unique décrit donc une « relation » pour une correspondance. Ces données vous être utilisées pour suivre la règle de base suivante :

Si ce triplet n'est pas encore connu, alors nous refusons la tentative de remise du message avec une erreur temporaire ainsi que toutes celles qui pourraient survenir durant une période de temps donnée.

SMTP étant considéré comme un protocole non fiable, les indisponibilités temporaires sont des éventualités prévues dans ses spécifications de base (voir la RFC 821). Ainsi, tout relais de messagerie (MTA) se comportant de manière conforme devrait tenter de transmettre à nouveau tout message dont la tentative de transmission s'est soldée par un code d'erreur temporaire (voir plus bas pour un examen des MTA non conformes).

Lors des premiers tests de listes grises, courant 2003, il a été observé que la grande majorité des spams été envoyés par des applications écrites spécifiquement pour cette tâche. Ces applications adoptent la philosophie « envoyer et oublier ». C'est-à-dire qu'elles tentent d'envoyer un message à une ou plusieurs machines qui sont référencées par le MX d'un domaine mais n'essayent jamais de faire une nouvelle tentative comme le ferait un MTA standard. D'après les résultats de nos tests, nous avons atteint un taux d'efficacité de plus de 95% et cela sans qu'aucun message légitime ne soit bloqué de manière définitive.

De plus, les listes grises se sont avérées extrêmement efficaces pour bloquer les virus se propageant par message électronique et qui prolifèrent depuis quelques temps. En effet, ceux-ci n'ont pas pour habitude de tenter une nouvelle transmission. Leur taille étant souvent conséquente, les ressources réseau et système sont largement économisées en comparaison de la méthode traditionnelle qui consiste à accepter le message et en vérifier le contenu localement.

Le coût en ressources de ce blocage est minime. Si une base de données locale est utilisée pour stocker les triplets et autres données accessoires, aucun trafic réseau supplémentaire n'est engendré par les listes grises excepté celui nécessaire à la connexion elle-même. Et, comme nous ne vérifions pas le contenu du message lui-même, il n'y a quasiment aucun surcoût en temps de traitement en comparaison des autres techniques de filtrage de spam.

Il existe un effet de bord qui est à la fois positif et négatif. Les listes grises introduisant un délai pour accepter un message dont le triplet est inconnu, cela génère un petit plus de travail du coté des MTA qui envoient des messages légitimes. D'un autre coté, cela engendre beaucoup plus de travail et occupe la machine des spammeurs, à un tel point que cela peut réduire à néant le profit généré par l'activité d'envoi de spams pour certains d'entre eux.

Le point le plus intéressant vient du fait que nous ne rejetons jamais un message de manière définitive. Par conséquent, tant que le MTA qui nous envoie un message se comporte correctement, un message légitime ne devrait jamais être retourné en erreur (bounce) à son expéditeur. Il ne devrait jamais y avoir de faux positif !

Implémentation

Pour mettre en œuvre le mécanisme des listes grises, nous utiliserons une base de données quelconque qui servira à stocker certaines informations associées au triplet correspondant à un message :

(Note : D'autres informations sont stockées et utilisées dans l'exemple d'implémentation, elle seront discutées plus tard. Nous n'en tiendrons pas compte à ce stade. De plus, le nombre de tentatives bloquées et le nombre de messages acceptés ne sont pas strictement nécessaires mais se montreront utiles afin d'optimiser le fonctionnement du procédé.)

Avec ces données, nous avons tout ce qui nous est nécessaire afin de mettre en œuvre une implémentation opérationnelle de la techniques des listes grises.

Le moment de la conversation SMTP le plus approprié pour réaliser nos tests est dès que cela est possible, lorsque toutes les informations nécessaires sont disponibles. Pour mémoire et à l'intention du lecteur peu familiarisé avec les détails d'une conversation SMTP, une séquence classique de commandes SMTP ressemble à ceci :

-> HELO undomaine.com
<- 250 Hello undomaine.com
-> MAIL FROM: <expediteur@undomaine.com>
<- 250 2.1.0 Sender ok
-> RCPT TO: <destinataire@unautredomaine.com>
<- 250 2.1.5 Recipient ok
-> DATA
<- 354 Enter mail
   ...
<- 250 2.0.0 Message accepted for delivery

Une fonction supplémentaire qui n'a pas encore été mentionnée est la création par une méthode quelconque de listes blanches de relais, destinataires voire expéditeurs.

La possibilité d'avoir des listes blanches manuelles n'est pas strictement indispensable mais, pour plusieurs raisons, une implémentation minimale devrait inclure de manière quasi-obligatoire une liste blanche manuelle d'adresses IP entrant dans les catégories des adresses locales (localhost) ou des machines MX primaires ou secondaires pour les domaines gérés. Mais, ces relais seront présumés être assez « intelligents » pour gérer des tentatives de retransmission et ne seront pas bloqués. Par ailleurs, il y a peu de conséquence à différer l'acceptation des messages qu'ils transmettent.

De même, des listes blanches de destinataires (ou de domaines de destination) peuvent s'avérer utiles dans un environnement de type ISP lorsque certains clients souhaitent que leurs domaines ne soient pas impactés par le délai introduit dans la réception des messages par la technique des listes grises.

Bien qu'elles soient aisées à implémenter, les listes blanches basées sur l'adresse de l'expéditeur (ou le domaine de son adresse) sont déconseillées. La raison à cela est que, dans la plupart des cas, mettre en liste blanche l'adresse IP de la machine de messagerie qui envoie les messages pour un domaine particulier est une bien meilleure solution car il est beaucoup plus difficile d'usurper une adresse IP que l'adresse d'expédition d'un message. De plus, il est généralement assez aisé de deviner les adresses et les domaines qui ont toutes les chances d'être dans ce type de liste blanche ce qui permet ensuite aux spammeurs de contourner le mécanisme des listes grises.

Que ces listes blanches soient stockées dans une base de données ou codées en dur dans l'application importe peu du point de vue strict des listes grises. Il est bien entendu qu'une implémentation qui permet de les modifier aisément est préférable.

L'algorithme d'une implémentation basique mais correcte pourrait être :

  1. vérifier si l'adresse (ou le réseau) IP du relais qui envoie le message est présent dans une liste blanche, dans l'affirmative passer le message ;
  2. vérifier si l'adresse (ou le domaine) du destinateur est présent dans une liste blanche, dans l'affirmative passer le message ;
  3. regarder si le triplet associé à ce message nous est connu :
    1. si nous ne l'avons jamais vu, créer un enregistrement le décrivant et renvoyer un code d'erreur temporaire au MTA d'origine ;
    2. s'il nous est connu mais que la période de blocage n'est pas révolue, renvoyer un code d'erreur temporaire au MTA d'origine ;
    3. s'il nous est connu et que la période de blocage a expiré, passer le message.
  4. si le message est autorisé à passer est qu'il est remis avec succès :
    1. incrémenter le compteur de remise de la ligne correspondante ;
    2. mettre à jour la date d'expiration de l'enregistrement à une valeur qui est la somme de la durée de vie des enregistrements et de la date actuelle.
  5. si la tentative de transmission doit être rejetée avec une erreur temporaire :
    1. incrémenter le compteur de rejet de la ligne correspondante ;
    2. si l'adresse de l'expéditeur est le cas spécial de l'adresse nulle (« <> »), ne pas rejeter le message après la commande SMTP RCPT mais attendre la fin de la phase DATA.

(Note : Tous les enregistrements dont la durée de vie a expiré sont ignorés par l'ensemble des tests.)

Contraintes influençant l'implémentation proposée

Il existe quelques petits points qui réclament une attention particulière afin qu'ils ne représentent pas une gêne. Nous allons devoir légèrement modifier notre approche de base.

Un de ces désagrément est dû au fait que certains MTA (Exim par exemple) tentent de limiter le problème lié aux adresses forgées en essayant de vérifier l'adresse d'expédition via une connexion SMTP symétrique avant d'accepter un message. Comme il est préférable de minimiser le trafic réseau lorsqu'un message est rejeté temporairement, la meilleure manière de faire est de retourner un code d'erreur temporaire juste après la commande SMTP RCPT. Cependant, dans le cas de la vérification SMTP symétrique, procéder ainsi introduira un délai non nécessaire lors de l'envoi de nos messages sortants.

Heureusement, la plupart des MTA qui utilisent cette pratique se servent de l'adresse d'expédition nulle (« <> ») pour réaliser ce test. Cela nous permet de contourner aisément ce problème en modifiant notre procédure de manière à retourner, dans ce cas, le code d'erreur temporaire après la phase DATA de la conversation SMTP. Étant donné que les connexions SMTP symétriques utilisées pour vérifier les adresses émails se terminent avant de parvenir à la phase DATA, la vérification sera réussie et nos messages sortants pourront être remis sans délai.

Il existe un logiciel qui pose un problème lié à ce comportement, il s'agit de Postfix. Celui-ci ne suit pas la convention et utilise une autre adresse (configurable) que l'adresse d'expédition nulle. Lorsque j'ai tenté de savoir pourquoi Postfix n'utilisait pas l'adresse d'expédition nulle comme le font tous les autres MTA, il m'a été répondu que c'était à cause de certains MTA mal fichus qui n'acceptent pas cette adresse bien que cela soit requis dans les RFCs relatives à SMTP.

Malheureusement, cela pose un problème pour essayer de contourner le comportement douteux de Postfix. Une chance que la configuration par défaut de cette adresse semble être « postmaster » ! Cela nous permet de contourner la difficulté d'une manière acceptable.

Une autre préoccupation potentielle apparaît lorsque certaines organisations importantes utilisent un ensemble de machines groupées pour la gestion des messages sortants et que certains sont envoyés à un MTA qui met en oeuvre la technique des listes grises. Si la configuration de ces machines fait en sorte que le même serveur (avec la même adresse IP) sera toujours celui qui réalisera les tentatives de retransmission d'un message en particulier, alors il n'y a pas de problème.

Mais si la manière dont sont configurés ces machines permet que les tentatives successives d'émission d'un même message soient réalisées par différents MTA, alors il existe une possibilité que l'envoi de messages légitimes prenne beaucoup plus de temps que prévu. Le délai maximal dépend du nombre de machines groupées et du caractère aléatoire ou déterministe de la répartition des tentatives de retransmission des messages. Dans le pire des cas, il est même possible qu'un message puisse être retarder si longtemps qu'il finit par être retourner en erreur à son expéditeur.

Au lieu d'ajouter ces réseaux dans une liste blanche, une suggestion pour traiter ce point est d'effectuer les tests de l'adresse IP des relais d'expédition sur la base du réseau auquel ils appartiennent plutôt que sur leur adresse IP complète. Comme les machines de la plupart des sites qui utilisent des groupes de relais SMTP en envoi sont situées sur un même réseau IP /24, cette méthode fonctionne bien pour contourner ce problème tout en évitant une intervention manuelle. Sa seule contrepartie est de rendre un tout petit plus facile la tâche aux spammeurs pour contourner le système.

Un autre souci potentiel concerne les gestionnaires de listes de diffusion qui utilisent une adresse d'enveloppe d'expédition unique pour l'envoi des messages à chaque utilisateur. Cela permet de mieux identifier les retours des messages en erreur car il n'existe aucune convention pour présenter ces derniers. Il est très courant que les messages retournés en erreur soient présentés d'une manière qui rende très difficile, voire impossible, leur interprétation dans le but de déterminer l'adresse de destination qui a généré l'erreur.

Cette technique de gestion des retours d'erreur est appelée VERP pour Variable Envelope Return Paths (« adresses variables de retour dans l'enveloppe ») et une des manières de faire cela est expliquée ici. Heureusement, la plupart des gestionnaires de listes de diffusion font cela d'une manière similaire à celle qui est décrite dans ce texte et qui consiste à utiliser une adresse d'enveloppe unique pour chaque destinataire d'un message de la liste de diffusion.

Cependant certains gestionnaires de listes de diffusion (comme Ezmlm) essayent également de suivre les erreurs pour chaque message plutôt que simplement pour chaque destinataire. Cela est une variation de la méthode VERP pour laquelle chaque message a sa propre et unique adresse d'expédition dans l'enveloppe. Étant donné que le système des listes blanches automatiques construites par l'intermédiaire des listes grises repose sur l'adresse d'enveloppe de l'expéditeur pour suivre les messages successifs, chaque message va donc être temporisé alors que seul le premier devrait l'être.

Alors que suivre les retours d'erreur de chaque message peut paraître être une bonne idée, dans l'ère de l'Internet qui est celle que nous connaissons aujourd'hui et qui exige la vérification des adresses d'expédition, il s'agit probablement d'une mauvaise idée. Heureusement, les auteurs de Ezmlm vont corriger ce problème.

Il y a une solution de contournement très simple qui consiste à insérer dans une liste blanche toutes les machines qui expédient ce genre de messages. Mais, heureusement, même sans cette action manuelle, les conséquences sont limitées car les gestionnaires de listes de diffusion ne sont en général pas particulièrement diligent lors de la distribution des messages et le délai induit ne sera pas gênant pour la plupart des utilisateurs.

Paramètre fondamentaux de configuration

Afin de donner le plus de maîtrise possible à l'administrateur de messagerie qui choisi de mettre en oeuvre la technique des listes grises, il y a plusieurs options qui devraient pouvoir être modifiées facilement afin d'ajuster au mieux le comportement des listes grises au cas par cas. Nous détaillons ci-dessous ces options et certains éléments qu'il est sage de garder à l'esprit s'il s'avère nécessaire de changer les valeurs par défaut suggérées.

En fait, il pourrait être judicieux d'utiliser des valeurs différentes pour chaque déploiement car cela les rendrait plus difficile à deviner aux spammeurs.

Délai initial introduit pour un triplet auparavant inconnu : 1 heure.
Durée de vie des triplets pour lesquels un message n'a pas encore été autorisé à passer : 4 heures.
Durée de vie des triplets en liste blanche automatique qui ont permis à un message de passer : 36 jours.

Le délai initial d'une heure a été déterminé pour plusieurs raisons :

  1. Une heure est une durée suffisamment courte, dans la plupart des cas les utilisateurs ne s'en rendront pas compte.
  2. C'est un délai assez long pour donner une chance aux administrateurs d'un relais qui pourrait être compromis ou abusé de découvrir le pot aux roses et corriger le problème avant qu'une tentative de retransmission ne réussisse.
  3. C'est un délai suffisamment long pour augmenter les chances qu'une machine qui est en fait celle d'un spammeur soit ajoutée à une liste noire d'adresses IP qui serait utilisée en conjonction avec les listes grises. Ainsi, même si le relais qui envoie des spams effectue des tentatives de retransmissions qui ne sont plus bloquées par les listes grises, elles pourraient l'être par d'autres méthodes.
  4. C'est un délai également suffisant pour permettre la mise en oeuvre d'autres types d'analyseurs de trafic qui permettraient d'identifier facilement les adresses IP des spammeurs par d'autres méthodes tout en évitant que les premiers destinataires (frappés avant qu'une signature commence à se former) ne reçoivent le spam.

Les données collectées durant les tests ont montré que plus de 99% des messages qui ont été bloqués avec un délai d'une heure l'auraient été avec un délai d'une minute seulement. Cependant, il y a fort à parier que lorsque cette nouvelle technique viendra à leurs oreilles, les spammeurs modifieront leurs logiciels de manière à gérer les tentatives de retransmission des messages rejetés. À ce moment là, un délai initial plus long sera définitivement avantageux car il permettra de donner plus de temps aux autres méthodes de filtrage pour réagir. Pour cette raison il est préconisé de garder un délai initial d'une heure au minimum car les spammeurs s'adapteront dès qu'ils auront eu vent de cette technique et qu'elle sera répandue.

Il est important de garder ce paramètre inférieur à une valeur qu'un nombre significatifs de MTA utilisent pour déterminer le délai après lequel le message est retourné en erreur à l'expéditeur. Fort heureusement, la plupart des MTA ont des délai de dépassement de plusieurs jours. Il existe cependant certaines organisations financières qui souhaitent savoir très rapidement qu'un message n'a pas été délivré. Même dans ces cas spéciaux, le délai de dépassement devrait être au moins de quelques heures.

Des techniques seront sans doute développées pour analyser les informations issues d'une base de données de listes grises afin de déterminer automatiquement les adresses IP des machines qui essayent d'envoyer du spam.

Bien que ce genre de fonction ne soit pas intégrée dans l'exemple d'implémentation, il serait intéressant de voir arriver cela. Certains schémas révélant l'identité de spammeurs ont pu être observés en quelques minutes, principalement identifiés par un ensemble de tentatives d'envoi de messages très rapprochées à un nombre important de destinataires en provenance de la même adresse IP ou d'un groupe d'adresses IP depuis lesquels aucun (ou peu) de trafic n'avait été observé jusqu'alors. (Dans l'éventualité où les créateurs ou mainteneurs de listes noires de DNS seraient intéressés pour créer un outil permettant d'utiliser automatiquement ces données pour les aider à mettre à jour leur liste, merci de me contacter.)

Cependant, l'analyse de signatures requiert un trafic très important pour être utile et valide. Les petits systèmes ne pourront donc probablement pas bénéficier de ces technologies à moins que cette analyse de signatures ne soit distribuée auquel cas la difficulté reviendra à trouver des partenaires de confiance.

La durée de vie initiale de 4 heures a été choisie car :

  1. Quasiment tous les relais de messagerie légitimes ont un délais de retransmission inférieur à cette valeur.
  2. Une durée de vie limitée aide à contenir le nombre d'enregistrements à considérer et à maintenir pour les sites très chargés qui peuvent avoir à gérer des quantités phénoménales de messages et des centaines ou des milliers de requêtes par seconde. Des valeurs faibles pour ce paramètre deviendront plus nécessaires au fur et à mesure de l'augmentation du volume de spams car un enregistrement sera créé pour chaque triplet unique.
  3. Il est apparu qu'il valait mieux maintenir ce paramètre à une faible valeur afin de ne pas permettre aux spams de passer à travers le système lorsqu'un spammeur tente d'émettre de nouveau un message à l'ensemble de sa liste de destinataires.

(À noter que dans l'exemple d'implémentation cette durée de vie de 4 heures inclue le délai initial d'une heure ce qui fournit une fenêtre effective de 3 heures pendant laquelle un message peut être accepté.)

Il existe une autre raison pour laquelle cette durée de vie devrait être aussi courte que possible. Si un spammeur découvre et utilise un relais SMTP mal configuré, il le chargera tellement qu'il en deviendra particulièrement lent. Cela augmente les chances que le relais incriminé devienne si occupé qu'il ne sera plus capable de traiter les tentatives de retransmission suffisamment rapidement pour passer à travers la fenêtre de temps disponible.

La durée de vie des enregistrements passés automatiquement en liste blanche est mis-à-jour chaque fois qu'un message est transmis avec succès et la valeur qui a été retenue est de 36 jours pour :

  1. aider à garder la taille de la base de données raisonnable en permettant que les enregistrements représentant des associations d'expéditeurs, de destinataires et de relais obsolètes expirent à propos ;
  2. être certain que les enregistrements vivront assez longtemps afin d'éviter d'introduire un délai pour les messages des listes de diffusion qui pourraient être envoyés à un rythme mensuel (par exemple, les rappels d'abonnement) y compris ceux qui sont envoyés tous les mois mais un jour donné de la semaine (par exemple, le premier lundi des mois de juin et juillet de l'année 2003 sont séparés par 35 jours).

Analyse de l'efficacité

Un test basé sur l'exemple d'implémentation et sur une période d'environ 6 semaines a produit les résultats bruts suivants :

Nous avons donc un taux d'efficacité supérieur à 97% en postulant que tous les messages sont du spam. C'est en fait bien mieux que cela puisque la plupart des messages qui sont passés n'en étaient pas. Mais il n'a pas été possible d'être plus précis car cela aurait demandé à ce que nous examinions le contenu de chaque message, ce que, bien évidemment, nous n'avons pas fait.

Jetons maintenant un oeil sur notre inefficacité :

Malheureusement, il s'agit d'un piteux résultat. Mais essayons de l'expliquer un peu. Quasiment tous ces messages temporisés étaient ceux de listes de diffusion qui utilisaient une adresse d'expédition unique comme identifiant (voir la note concernant la technique VERP ci-dessus). Donc, si nous excluons tous les triplets qui n'ont laissé passer qu'un seul message, nous ne tiendrons plus compte de ce type de trafic et nous obtenons de nouveaux chiffres :

Cela montre les choses sous une lumière bien plus favorable en ne tenant pas compte des délais seulement pour les messages qui n'ont généralement pas de caractère d'urgence.

Maintenant regardons les conséquences qu'auraient les listes grises en terme d'occupation des ressources réseau en nous basant sur des moyennes générales :

Ces chiffres sont basés sur des spams collectés via différentes méthodes avant la période de test. Nous avons retenu ceux-ci qui sont des arrondis bien pratiques mais pourtant proches des analyses issues du spam collecté antérieurement. En ce qui concerne le trafic induit par une tentative de remise SMTP, il est inférieur à 500 octets dans la plupart des cas mais nous avons décidé de garder une approche conservatrice.

D'après ces chiffres, il en résulte que pour chaque spam bloqué par les listes grises, nous sauvegardons suffisamment de bande passante pour « payer » 10 tentatives de remises temporisées. Si nous rapportons cela à des chiffres réels (en utilisant les chiffres non ajustés afin de dépeindre le pire des cas) :

Cela donne un gain net de plus de 1,67 Go de bande passante qui a été économisée en implémentant les listes grises lors de nos tests. Et il s'agissait d'un site de taille modeste.

Suggestions pour une protection plus efficace des domaines de messagerie

La méthode des listes grises ne sera pas aussi efficace contre le spam à moins que toutes les machines qui sont MX pour un domaine donné utilisent un logiciel l'incluant.

Un nombre non négligeable de logiciels d'envoi de spam sont assez perfectionnés pour tenter de délivrer les messages vers les autres machines MX du domaine si le MX principal échoue. Étant donné qu'il est probable que tous les MX d'un domaine soient inclus dans les listes blanches les uns des autres (quel est l'intérêt de temporiser les tentatives d'envoi des messages provenant de machines dont vous savez qu'elles tenteront un nouvel envoi ?), si un spammeur peut envoyer des messages à l'un d'entre eux sans aucun délai, alors vous ne serez pas mieux protégé qu'auparavant.

De plus, bien qu'elles n'induisent qu'une moindre incidence pour les utilisateurs, il est possible de rendre les listes grises encore moins pénalisantes si toutes les machines MX d'un domaine partagent la même base de données pour suivre les tentatives de transmissions. Afin d'illustrer cela, prenons un exemple dans lequel notre domaine de messagerie contient plusieurs machines MX qui utilisent chacune leur propre base de données.

Un relais légitime avec un délai de tentative de retransmission d'une heure essaye d'envoyer un message à l'une de nos machine MX. Celle-ci ne connaît pas encore le triplet associé à ce message et le refuse. Une heure passe, le MTA d'origine sait que le message a été refusé, il décide donc de ne pas essayer de retransmettre le message à la même machine et choisi donc une autre machine MX de notre domaine pour tenter une nouvelle transmission. Cette dernière n'utilisant pas la même base de données que la première machine ne sait rien de la tentative initiale et, comme elle ne connaît pas ce triplet, elle crée un enregistrement pour celui-ci dans sa base de données puis rejette le message.

Cet exemple montre clairement qu'il est possible qu'un message légitime soit temporisé inutilement s'il y a plusieurs machines MX dans la boucle, à un point tel que le MTA qui envoi le message finisse par le retourner en erreur à l'expéditeur.

Afin d'éviter cela, il est fortement recommandé que dans le cas où un domaine est géré par plusieurs MX ceux-ci utilisent la même base de données pour suivre les triplets associés aux messages. Il peut y avoir des situations dans lesquelles les machines sont trop éloignées (d'un point de vue du réseau) pour que cela ce fasse de manière efficace et fiable. Mais même alors il est possible que la technique des listes grises soit suffisamment utile pour justifier cet aléa ou la mise en place d'une technique de contournement pour en réduire les effets.

Techniques couramment utilisées par les spammeurs

Cette partie détaille quelques techniques utilisées par les spammeurs parmi celles les plus observées pendant la période de test et comment la technique des listes grises gère ces attaques.

Première technique : L'envoi vers les machines de MX secondaire

Un nombre important de spams ont été spécifiquement envoyés vers les machines qui n'étaient pas le MX principal du domaine pour la simple raison que les MX secondaires acceptent en général tous les spams et les relaient vers le MX principal sans les contrôler. Cela réduit la charge de la machine du spammeur, ne lui demande que peu ou pas du tout de gestion supplémentaire pour les messages rejetés et a généralement pour effet l'obtention de temps de remise bien plus rapides car le système de destination a moins de travail (dans le cours terme, durant l'attaque).

Les listes grises gèrent très bien ce type d'attaque puisque son objectif principal est de réduire les retour en erreur et les temps de remise.

Deuxième technique : L'attaque par dictionnaire

Beaucoup de spammeurs ont recours aux attaques par dictionnaire (également appelée trolling) qui consiste à envoyer les spams à des noms d'utilisateurs courants (« jean@ », « michel@ », etc.) ou bien à des adresses générées à partir de noms réels obtenus par d'autres méthodes. Apparement ils semblent péférer les listes de noms courants mais la tactique des adresses générées devrait se répandre.

Les spammeurs utilisent probablement cette méthode dans le but d'atteindre des personnes qui ont pris les mesures nécessaires pour éviter que leur adresse émail ne soit récupérées depuis le Web ou qui sont trop novices pour avoir les ressources ou l'envie de créer leurs propres pages Web. Sans doute le second cas puisque les utilisateurs novices sont les plus à même d'acquérir quelque chose dont ils ont eu la connaissance par l'intermédiaire d'un spam.

Ce type d'attaque est très souvent combinée avec un envoi vers les machines de MX secondaire car la plupart des messages se solderont par des retours en erreur pour les domaines n'ayant qu'une petite population d'utilisateurs. C'est pourquoi les spammeurs visent les MX secondaires. Ainsi ils n'ont pas à gérer tous les retours d'erreur que ces messages génèrent.

Les listes grises gèrent cela très bien car ces attaques proviennent généralement d'adresses IP dynamiques. Et aussi parce que ces émails générants tellement de retours d'erreur qu'il est coûteux pour les spammeurs d'essayer de gérer les tentatives de retransmission pour ce type d'attaque. Ces attaques sont également tellement repérables (un grand nombre de retours en erreur générés sur une courte période par une adresse ou un groupe d'adresses IP), qu'elles sont faciles à reconnaître et à ajouter à d'autres types de listes noires pourvu que suffisamment de temps soit disponible, ce que fournit les listes grises.

Troisième technique : L'attaque distribuée organisée

Beaucoup d'attaques de spammeurs revêtent la forme d'une attaque par dénis de service (DoS) limitée, appelons cela une « attaque distribuée organisée de spam ».

Sur les systèmes qui ont servi à évaluer les méthodes des spammeurs, il a été observé régulièrement des situations dans lesquelles les tentatives d'envoi de spams qui avaient lieu dans une fenêtre de temps réduite provenaient de beaucoup d'adresses IP différentes sans aucun liens entre elles. Alors que l'adresse d'expédition de l'enveloppe était la même (ou similaire) et que les adresses de destination de l'enveloppe présentaient un caractère séquentiel.

Évidemment, les listes grises (telles qu'elles sont décrites ici) gèrent très bien ce genre d'attaque. Cependant, si (lorsque) les spammeurs s'adaptent et apprennent à réaliser des tentatives de retransmission, elles pourront devenir moins efficaces.

Ceci dit, il est tout à fait possible d'adapter la technique des listes grises afin de contrecarrer le processus décris ici. Par exemple, pour un coût de temps de traitement additionnel très faible, il devrait être assez simple de regarder toutes les tentatives d'envoi de messages dans une fenêtre de temps récente et, après que les premières tentatives suspicieuses aient été constatées, soumettre tous les relais révèlant ce comportement à plusieurs listes noires comme sites de spammeurs probables.

Quatrième technique : L'attaque par mandataire Web

Une partie significative de spams semblait provenir de relais qui se sont révélés être des serveurs CacheFlow ou d'autres types de serveur mandataire (proxy). Ils peuvent être généralement identifiés car ils retournent la valeur « CacheFlowServer » à une requête ident.

Les listes grises bloqueront complètement ce type d'attaques car ces serveurs n'étant pas de réels MTA, ils ne feront jamais de tentatives de retransmission.

Techniques potentiels d'adaptation pour les spammeurs

Les listes grises présentent une protection relativement bonne aux techniques potentielles d'adaptation que les spammeurs pourraient inventer pour passer à travers le filtrage. Ces techniques pourraient rendre l'efficacité propre des listes grises moins importante mais les moyens de passer à travers rendront les autres techniques de filtrage plus efficaces.

Le comportement standard des spammeurs est de changer d'adresse IP lorsque celle-ci a été ajoutée aux listes noires. Malheureusement pour eux, changer d'adresse IP ne les avance en rien pour contrer notre technique de temporisation car chaque message (et le délai associé) est lié à l'adresse IP du relais émetteur. Si l'adresse IP change, cela remet à zéro le compteur même si les adresses de l'expéditeur et de destination sont inchangées.

Un autre genre d'adaptation qui devrait arriver de la part des spammeurs rendra les logiciels d'envoi de spams en masse obsolètes car la plupart de ces applications ne sont pas suffisamment élaborées pour tenter une nouvelle transmission si un message n'a pu être délivré, quelque soit le type d'erreur rencontrée. Les spammeurs devront donc utiliser des programmes plus intelligents gérants les retransmissions ou devront utiliser des relais permissifs.

Nous pourrions assister à une attirance des spammeurs à utiliser des relais ouverts mais la plupart d'entre eux ont été fermés ou sont rapidement en train de l'être. Ou bien ils pourront être incités à déployer leurs propres relais. Dans tous les cas, tous ces relais devraient rapidement être ajoutés aux listes noires réduisant d'autant leur efficacité à propager du spam.

Si les spammeurs déploient leurs propres relais SMTP, le fait que les messages soient temporisés et que plusieurs tentatives d'envoi soient nécessaires demandent des ressources de stockage et de la bande passante additionnels de leur coté, ce qui augmente le coût d'envoi du spam. Et si nous pouvons rendre le phénomène moins générateur de profit, alors nous sommes en bon chemin pour résoudre le problème du spam.

Précautions lors de l'implémentation

La tactique de temporisation qui est le fondement de la technique des listes grises peut introduire des délais intempestifs si la machine qui la met en oeuvre accepte les connexions de clients qui utiliseront régulièrement des adresses IP différentes pour soumettre des messages à relayer. Par exemple, si les clients distants sont autorisés à utiliser le relais après avoir réaliser une authentification POP ou IMAP, cette implémentation ne permet pas de gérer ces clients de manière à ne pas introduire un délais indésirable pour les messages qu'ils soumettent.

Un contournement de ce problème existe mais il n'est pas implémenté dans le code d'exemple. Grosso modo pour autoriser le relais de la part de ces clients sans introduire un délais, il suffirait de créer un enregistrement dont la durée de vie serait limitée dans la base de données des listes grises au même moment où l'autorisation de relais serait acceptée. Ce qui permettrait à l'adresse IP d'origine d'envoyer des messages pendant une période courte mais suffisante.

La réception de messages en provenance de machines légitimes qui, soit ne tiennent pas compte de la nature temporaire des codes d'erreur des rejets, soit n'essayent jamais de retransmettre les messages sera définitivement affectée par le système. Heureusement, tous les MTA qui présentent ces lacunes devraient être rapidement corrigés une fois que les listes grises seront utilisées par un nombre conséquent de sites.

Seulement voilà, plusieurs sites présentants ces symptômes ont été découverts pendant la période de test. Les systèmes incriminés l'étaient soit parcequ'ils suivaient maladroitement les spécifications des RFC, soit parcequ'ils les violaient à dessein. Étant donné que SMTP est un protocole non fiable par nature, les MTA qui ne tentent pas de retransmission sont bien malavisés et devront être corrigés.

Un exemple de transcription d'une conversation SMTP générée par un de ces MTA non conforme est :

-> HELO undomaine.com
<- 250 Hello 
-> MAIL FROM: <expediteur@undomaine.com>
<- 250 2.1.0 Sender ok
-> RCPT TO: <destinataire@unautredomaine.com>
<- 451 4.7.1 Please try again later
-> DATA
<- 551 No valid recipients

Cela montre clairement que le MTA d'origine ne vérifie pas le résultat de la commande RCPT et continue en envoyant la commande DATA, ce qui provoque l'émission d'un code d'erreur permanent car ce n'est pas une étape valide si aucun destinataire n'a été accepté. Dans le cas particulier de ce MTA, il ne tient compte que du second code d'erreur 551 qui est un code d'erreur permanent. La conséquence de cela est le retour en erreur du message à son expéditeur. Mais ce comportement est incorrect car le premier code d'erreur temporaire est ignoré et la transaction n'est pas abandonnée à ce moment là.

Un exemple d'implémentation

L'exemple d'implémentation proposé (disponible ici) est un milter pour Sendmail basé sur Perl et utilisant la version 0.18 de l'interface Sendmail::Milter (également disponible depuis CPAN). Il a été testé avec Sendmail 8.12.9 bien qu'il devrait fonctionner avec toutes les version de Sendmail postérieures à 8.12.5. Sendmail::Milter requiert une version multi-thread de Perl et a été testé avec Perl 5.8.0 (disponible depuis perl.org ou sur CPAN).

Sont également disponibles la définition de la base de données utilisée par cette implémentation et un fichier de configuration d'exemple. Étant donné que cette implémentation est en Perl, elle est aisément modifiable. Elle n'est pas (encore) disponible sur CPAN.

La base de données utilisée est MySQL 3.23.54 bien que toute version ultérieure devrait convenir et il y a de fortes probabilités que des versions plus anciennes fassent également l'affaire. De plus, les systèmes de test utilisaient également amavisd-new, avec l'interface amavisd-new-milter, qui était configuré de manière à filtrer le spam avec l'aide de Spamassassin 2.53.

Dans le but de garder l'exemple d'implémentation simple et compréhensible, des fonctionnalités qui auraient pu être optimisées ont été laissées en l'état. Par ailleurs, même lors de tests de charge sévère, le temps additionnel requis pour les tests était, dans la plupart des cas, indécelable et, dans les autres cas, était causé par des délais d'accès à la base de données (qui était hébergée sur une autre machine).

Un détail de l'implémentation proposée causera sans doute une réaction d'horreur dans le coeur des inconditionnels de la programmation structurée. À plusieurs endroits l'instruction « goto » est utilisée. À cause de la manière dont l'interface milter fonctionne, cela semblait la méthode la plus directe.

Autres détails concernant l'exemple d'implémentation

Les messages acceptés et dont l'adresse d'enveloppe de l'expéditeur est l'expéditeur nul sont considérés comme des cas spéciaux et l'enregistrement associé expire immédiatement afin d'éviter qu'il soit en liste blanche une fois que nous avons laissé le message passer. Les messages en provenance de l'adresse d'expédition nulle (« <> ») ne sont utilisés (voir la RFC 821) que pour des messages spéciaux à caractères administratifs tels que les retours d'erreur. Ils ne devraient donc être utilisés qu'une seule fois par un message légitime. Pour cette raison, il n'y a aucun intérêt à continuer à les prendre en considération une fois que ce message est passé.

Malheureusement, beaucoup de spammeurs détournent cette utilisation et emploient cette adresse car elle ne générera pas de retour d'erreur de la part du MTA de destination (il ne sert à rien de générer un retour à un message qui est déjà un retour d'erreur). Expirer ces enregistrements immédiatement permet de limiter la possibilité pour les spammeurs qui utilisent cette technique d'envoyer plusieurs messages au même destinataire dans un intervalle de temps réduit.

Il y a par ailleurs plusieurs petites autres fonctions incluses dans l'exemple d'implémentation qui ne sont pas directement liées aux listes grises elles-même mais qui sont des tentatives pour améliorer ou mieux contrôler le filtrage de spam.

La structure de la base de données n'est pas une forme normale. Il s'agit d'un choix délibéré afin de permettre aux personnes qui ne sont pas familiarisées avec les notions de conception de bases de données puissent la comprendre. Cependant, retravailler l'implémentation de la base de données afin de l'exprimer sous forme normale devrait s'avérer trivial.

Un aspect qui n'est pas abordé est la maintenance de la base de données. Aucune méthode permettant d'insérer manuellement des enregistrements en liste blanche n'est fournie sinon les requêtes SQL d'exemple dans le fichier dbdef.sql. J'espère qu'une belle interface Web permettant de maintenir la base de données sera écrite mais je n'ai pas encore eu le temps de le faire. Ou, peut-être, quelqu'un s'en chargera et partagera son travail.

Source de l'implémentation de référence

Liens vers d'autres implémentations et informations

Crédits et remerciements

Si vous êtes intéressé par la première forme originalement publiée de ce document, elle est disponible ici.