Journal Luttons intelligemment contre le spam avec Whitelister

Posté par .
Tags : aucun
25
22
jan.
2009
La dépêche sur Dspam génère pas mal de commentaires sur les RBL, leurs avantages et leurs inconvénients.

Ce débat est pourtant dépassé, au moins pour les utilisateurs de postfix, depuis la publication, en 2005 (!) de Whitelister. Il s'agit d'un logiciel de filtrage écrit en OCaml par Pierre Habouzit dans le cadre de l'administration de serveur de mails au sein de l'école Polytechnique.
Le concept derrière whitelister est très simple : on prend deux mauvaises techniques de filtrage de spam pour en faire une bonne :
  • Premièrement, le greylisting. Cela consiste à configurer un serveur SMTP afin qu’il demande systématiquement aux émetteurs de courriers de retenter d'envoyer le message ultérieurement, conformément à la RFC (merci chl). En effet, on s'est aperçu que les logiciels d'envoi de spam ne retentent pas (ou peu) l'envoi du mail, alors que les serveurs SMTP légitimes adoptent un comportement conforme et acceptent de recontacter le serveur un peu plus tard.
    Cette technique n’est pas mauvaise en soit, mais elle introduit des délais non négligables : du fait du rejet temporaire, les mails mettent plus de temps à arriver au destinataire, entre 30 minutes et 2h en général… C’est donc pénalisant au quotidien.
  • Deuxième technique, les fameuses RBL. Ce sont des listes noires, gérées en dehors de toute autorité officielle : n’importe qui peut créer une RBL et la diffuser sur le web. Certaines RBL recensent les serveurs SMTP en « open relay » (serveurs utilisés pour envoyer du spam) ; d’autres incluent des netblocks habituellement utilisés pour envoyer du spam (ex : Chine, Corée) ; d’autres encore recensent tous les subnets que les providers attribuent à leurs clients, partant du principe que les botnets (source majeur de spam aujourd’hui) sont quasi-exclusivement constitués d’ordinateurs vérolés tournant sous Windows et appartenant à un particulier peu au fait du concept de « patch de sécurité ».
    Problème : la qualité d’une RBL dépend de l’organisation en charge de sa maintenance. Lu'tilisation d'une RBL revient à déléguer la gestion du SMTP à une entité externe sur laquelle l'on n'a aucun contrôle : si certaines RBL ont bien gérées, d’autres ont tendance à blacklister à tort et à travers, générant de nombreux problèmes par la suite. En tout état de cause utiliser une RBL nécessite de faire confiance à son auteur.

Et c’est là qu’intervient Whitelister : au lieu de refuser un serveur apparaissant dans une RBL, Whitelister permet de le rejeter temporairement !

De cette approche découlent deux bonnes choses :
  • seuls les emails suspicieux subissent le délais de greylisting, les autres arrivent directement : plus d'attente systématique !
  • si une machine est listée dans une RBL, la sanction est très légère : un simple passage en greylisting (sans whitelister, le mail est refusé) : il est donc possible d’utiliser plein de RBL différentes (notamment les RBL d’IP dynamiques, voire des RBL avec un niveau de confiance moindre) sans risque de voir un serveur légitime blacklisté indument.

Bref que du bon !

J’administre un certain nombre de serveurs mails, whitelister a permis de réduire considérablement le niveau de spam sans effet de bord notable (refus de mail…).

Le logiciel est en théorie hébergé sur le serveur aaege mais celui-ci ne répond pas depuis quelques temps. Le mieux consiste à installer le paquetage de votre distribution ou d'aller chercher les sources sur le serveur Debian

Deux liens pour finir :
Présentation de Whitelister, par son auteur
Postgrey, le serveur de greylist sur lequel s’appuie Whitelister
  • # Génial...

    Posté par (page perso) . Évalué à 2.

    Franchement je connaissais pas ce logiciel et il est super.
    Je n'utilisait pas les greylisting effectivement à cause des latences mais j'utilisais par contre une rbl.

    Sinon vous mettez quoi dans votre fichier /etc/whitelister.conf ?
    Moi j'ai juste les deux rbl par défaut plus un ancien : zen.spamhaus.org
  • # Effets de bord

    Posté par . Évalué à 4.

    N'y a-t-il pas toujours un certain nombre d'effets de bord concernant tout les mails envoyés automatiquement? La plupart des services en ligne envoyant des mails automatiquement, en cas de présence dans une RBL il y a de grande risque que les messages en provenance de ces automates n'arrivent jamais. Combien implémentent réellement cette fonctionnalité de la RFC comprenant cette éventualité?
    • [^] # Re: Effets de bord

      Posté par . Évalué à 5.

      Les services en ligne réglos ne sont pas dans les DNSBL ! Et s'il y ont été abusivement , ils sont whitelisté là bas.
    • [^] # Re: Effets de bord

      Posté par (page perso) . Évalué à 5.

      Je n'ai que très rarement eu des problèmes à cause de greylisting (je me souviens d'un expediteur ou ca réessayait que après 24h, je prefere pas imaginer la taille de leur file d'attente de mails si en cas de pb temporaire ils attendent 24h avant de réessayer...)

      Pourquoi dis tu il y a de grande risque que les messages en provenance de ces automates n'arrivent jamais. ?

      La plupart de ces services utilisent un vrai serveur de mail et ils gerent tous très bien les erreurs de type "je peux pas accepter ce mail maintenant" qui arrivent pour d'autres raisons que le greylisting.

      Ceux qui ne gérent pas le renvoi c'est les vers qui ont une implemenatation de smtp en 10 lignes et pas de file d'attente.
    • [^] # Re: Effets de bord

      Posté par (page perso) . Évalué à 2.

      Souvent les messages envoyés automatiquement passe par un serveur SMTP non ? En fait, si c'est l'application qui envoie l'email qui fait le dialogue en SMTP avec le serveur ou whitelister tourne alors tu risque un problème. Si l'application qui envoie les emails passe par un serveur smtp en local, ça devrait pas poser de soucis.

      Enfin, c'est ma déduction logique, c'est correcte non ?

      De plus il me semble qu'un nombre non négligeable de serveur mails utilisent des techniques comparables donc les logiciels qui envoient des emails automatiquement ont tout intérêt à bénéficier des mécanismes d'un serveur smtp leur permettant de s'assurer de l'envoie de l'email.
  • # Splendide sur les MX secondaires

    Posté par (page perso) . Évalué à 4.

    Je l'utilise depuis un an et demi, et j'en suis très content.

    J'ajouterais que son principe de fonctionnement en fait un outil redoutable pour les MX secondaires.

    Quand quelqu'un me demande de faire MX secondaire pour son domaine, c'est typiquement la seule mesure anti-spam que j'active. Même si je préfère quelque chose de plus agressif pour mes boites, je ne voudrais pas avoir de faux positifs pour les autres.
    Si un mail légitime est perdu à cause de whitelister, c'est le MTA en amont qu'il faut mettre à la poubelle !
  • # Le truc du MX secondaire

    Posté par (page perso) . Évalué à 2.

    Bonjour

    La plupart du spam arrive sur généralement le premier serveur de courrier, rarement le second directement.

    Une étude (je n'ai plus les références) avait démontré que si le premier serveur MX était en "rade" les bons serveurs SMTP envoyaient le courrier sur le second.

    la technique était donc de repérer les serveurs SMTP qui faisaient une requête sur le premier, puis sur le second MX, ce qui permettait ainsi de rejeter 98% du spam sans surcharge de serveurs.

    A bientôt
    Grégoire
    • [^] # Re: Le truc du MX secondaire

      Posté par (page perso) . Évalué à 7.

      Une étude (je n'ai plus les références) avait démontré que si le premier serveur MX était en "rade" les bons serveurs SMTP envoyaient le courrier sur le second.

      C'est là le principe même du MX secondaire :)

      La plupart du spam arrive sur généralement le premier serveur de courrier, rarement le second directement.

      Justement pas. De nombreux spams sont simplement envoyés aux MX de basse priorité, dans l'espoir que les mesures antispam y seront plus légères (ce qui a tout à fait son sens, si c'est une plateforme partagée qui doit satisfaire tout le monde).
      Or, quand le MX secondaire fait suivre vers le primaire, il est trop tard pour appliquer les RBL et autres tests sur l'enveloppe et l'expéditeur ; tout ce qu'il reste, c'est le corps et les en-têtes.
      • [^] # Re: Le truc du MX secondaire

        Posté par . Évalué à 6.

        >Justement pas. De nombreux spams sont simplement envoyés aux
        > MX de basse priorité,


        Exactement !
        Et c'est pourquoi la configuration du mx secondaire doit être au moins aussi restrictive que pour le primaire : en temps normal (= primary mx operationnel), la quasi totalité du traffic sur le secondaire est du spam. Si le primaire fonctionne, il y a peu de raisons qui justifient de contacter le secondaire pour envoyer un mail.

        Par exemple, la liste d'utilisateurs valides doit être présente sur le mx secondaire pour rejeter les spams dès leur émission. Si cette liste n'est que sur le primaire, le mx secondaire va accepter le message, le relayer au primaire qui va le rejeter dans la foulée, générant un "bounce" sur une adresse de retour forgée, innondant au passage un pauvre internaute qui n'a rien demandé à personne.

        Chaque administrateur de mx devrait savoir cela, et prendre les mesures adéquates...
        • [^] # Re: Le truc du MX secondaire

          Posté par (page perso) . Évalué à 3.

          C'est clair que c'est la solution idéale.

          Ce n'est malheureusement pas toujours faisable en pratique, spécialement quand ce ne sont pas les mêmes personnes qui administrent le serveur primaire et les secondaires.
      • [^] # Re: Le truc du MX secondaire

        Posté par (page perso) . Évalué à 1.

        >Justement pas. De nombreux spams sont simplement envoyés aux MX de basse priorité, dans l'espoir que les mesures antispam y seront plus légères

        Ou tout simplement pour y balancer le backscatter.
        http://en.wikipedia.org/wiki/Backscatter
  • # RFC 2821 --> 5321

    Posté par (page perso) . Évalué à 8.

    Juste pour pinailler ... ce n'est plus la RFC 2821, mais la 5321 :
    http://www.ietf.org/rfc/rfc5321.txt
  • # moué

    Posté par (page perso) . Évalué à 3.

    Moué, ca va marcher combien de temps ?
    Nan parcque les spammeurs s'adaptent et fassent plusieurs tentatives d'envoi ?
    • [^] # Re: moué

      Posté par (page perso) . Évalué à 5.

      La j'ai un doute...
      D'abord l'idée même de greylisting (trop contraignent certe, mais à la base du problème pour les spammeurs) n'est pas récente.

      En plus, le ver qui envoie les mails doit être léger. T'imagine ce que ça donnerait si tu devait maintenir des queue de mail "deferred", ça implique regarde les codes de retour en SMTP, maintenir une queue, avoir un démon qui regarde la queue et gère des timers...

      Sans compter que ça freinerai bien les performances de devoir envoyer plusieurs fois.

      Pour une implémentation de SMTP en 10 lignes ça fait beaucoup, en 10 lignes ce que le vert doit faire c'est ouvrir une connexion, dire HELO, balancé sa merde et basta.

      Alors autant inclure directement Postfix dans ton ver...

      Ceci dit, ça n'exclut pas la possibilité que les spammeurs aient une autre idée génial pour contrer ce mécanisme, mais les tentatives multiples, j'ai un doute.
      • [^] # Re: moué

        Posté par (page perso) . Évalué à 2.

        Je vois pas vraiment pas pourquoi maintenir une liste et gérer des timers ferait peur a des auteurs de virus capables de gérer un botnet de plusieurs centaines de milliers de machine à travers un réseau tellement bien sécurisé que même les meilleurs spécialistes mondiaux n'arrivent pas à le désactiver.
        • [^] # Re: argument "rien ne dit que ça fonctionnera dans 2 semaines/10 ans"

          Posté par . Évalué à 4.

          Force est de constater que depuis que le greylisting a été inventé (plus de 4 ans quand même), le principe fonctionne. Ca changera peut-être demain mais aujourd'hui cela permet, pour un coût minime, de filtrer les spams des mails légitimes. Dspam, spamassassin et consors sont beaucoup plus coûteux (CPU, RAM). Sur un serveur chargé cela fait une sacrée différence.

          Ce n'est pas parce qu'une technologie sera (éventuellement) obsolète demain qu'il ne faut pas l'utiliser aujourd'hui...
        • [^] # Re: moué

          Posté par (page perso) . Évalué à 2.

          Je ne sais pas exactement comment les virus fonctionnent car je ne suis pas un spécialiste du domaine.
          Mais ce serait obligatoirement moins performant (et ça les spammeurs veulent surement l'éviter), de plus, la gestion du botnet doit certainement se faire de manière centralisée, via les pcs des pirates, les pc verolés ne sont que des terminaux sans intelligence qui obéissent aux ordres.

          Imagine un peu que tu es un pirate, tu as ton petit botnet de 10 000 machines, tu lance une attaque par spam car une gentille société X te paye pour. Le résultat de ton attaque avec les queues est que tu ne sais pas prévoir à l'avance quand tes queues seront vides, donc quand tes pc clients seront à nouveau pleinement opérationnels (pour un système qui se doit d'être très rapide en étant discret, sinon l'utilisateur moyen appelle son neveu qui formate la machine pour remettre XP).

          Le fait de devoir gérer les queues rallongera le temps de tes attaques, donc tu as moins de temps pour l'attaque suivante donc moins d'argent. On peut imaginer que le pirate puisse donner un ordre aux clients de flusher la queue, alors on peut se poser la question de l'intérêt de la queue...

          Outre le fait que c'est plus complexe je crois que la perte de temps est un élément assez important.

          Je n'ai pas de chiffre, mais le greylisting n'est pas utilisé partout car il est chiant (les délais - donc les spammeurs préfèrent sans doute l'ignorer plutôt que dans se lancer dans des trucs super complexe). Le whitelisting est plus récent et peut être pas encore trop trop répendu.
        • [^] # Re: moué

          Posté par (page perso) . Évalué à 2.

          Et pour la désactivation du réseau c'est un peu ridicule. Évidemment qu'on ne sait pas le désactiver !

          Si tu coupe les pc identifier comme faisant partie des botnets tu coupera peut-être la moitié des pc connectés au net dans le monde, pas très réaliste.

          Quand à une potentielle détection du trafic généré par un attaqueur (dans le but de le bloquer bien entendu), je vois difficilement un ISP scanner tout le trafic de tout ses abonnés (sans compté le fait que les communications sont sûrement cryptées) avec une sorte d'IPS pour bloquer le trafic illégitime. Ca voudrait dire des mises à jours régulière, des potentiels faux positifs (soit utilisateurs pas content), des ISP pas neutres sur le transport des données (ce qu'on leur reproche parfois), une énorme consommation de ressource...

          Bref, la solution n'est pas dans la désactivation de quoi que ce soit mais plutôt dans le fait de responsabiliser les gens face aux problèmes de sécurité.
    • [^] # Re: moué

      Posté par . Évalué à 1.

      FUD: le greylist ça ne marche pas

      Fact: sur les 12 derniers mois glissants, le server MX principal de polytechnique.org a greylisté 128.330.938 messages (oui 128 millions) pour n'en laisser entrer (avant tout anti-virus et autre anti-spam bayésien) que 8.268.338 mails. Notre évaluation est qu'environ 3 ou 4M de ces mails sont légitimes.

      Et pourtant nous ne greylistons _que_ des IP qui sont blacklistées.

      cf http://blog.madism.org/index.php/2006/03/25/79-debianorg-and(...)

      l'idée sous-jacente est que ça ne sert a strictement rien de greylister un _vrai_ SMTP qui va réessayer plus tard. Ça ne fait qu'agacer son admin sys. Et il est raisonnable de supposer que un bon admin sys a aussi déblacklisté son SMTP, donc le greylist sert à "compenser" les mauvais admins de SMTP Légitimes.
  • # sqlgrey...

    Posté par . Évalué à 1.

    Bonjour,

    j'utilise sqlgrey et il implemente le concept de whitelist: il stock ipsource:sender:destinatiaire si le mail revient, il est whitelisté pour une période choisie. Donc la latence est uniquement pour le premier mail.

    J'ai aussi utilisé postgrey, le truc bien c'est que tu peux en faire causer deux entre eux par un port choisi, ce qui permet de tenir a jour le mx de maniere synchrone.

    Donc, je ne suis pas sûr de la mega bestialité du cette "nouvelle chose"

    @+
    • [^] # Re: sqlgrey...

      Posté par . Évalué à 2.

      > j'utilise sqlgrey et il implemente le concept de whitelist: il stock
      > ipsource:sender:destinatiaire si le mail revient, il est whitelisté pour
      > une période choisie. Donc la latence est uniquement pour le premier
      > mail.

      Oui, enfin du greylisting classique appliqué à 100% des mails, quoi...

      Whitelister (le logiciel) ne greyliste que les mails en provenance de machines louches. Et du coup annule les inconvénients des deux méthodes sus-citées (RBL / greylist).

      Pour finir, Whitelister n'est pas nouveau, il date de 4 ans mais je suis toujours surpris de son manque de popularité.
      • [^] # Re: sqlgrey...

        Posté par (page perso) . Évalué à 4.

        Pour finir, Whitelister n'est pas nouveau, il date de 4 ans mais je suis toujours surpris de son manque de popularité.

        Tu as sans doute répondu à la question dans le journal : "Le logiciel est en théorie hébergé sur le serveur aaege mais celui-ci ne répond pas depuis quelques temps."

        --> Pas de site officiel, pas de mailing list, pas d'évolution (le diff Debian date de "15 Apr 2005"), bref pas de communication, ça explique!
        • [^] # Re: sqlgrey...

          Posté par . Évalué à 1.

          Dans la pratique je m'en tape doublement parce que:

          * j'utilise whitelister pour moi et je le conseille autour de moi, mais je m'en fous un peu si il n'est pas connu
          * nous sommes en train d'écrire un remplacement bien plus puissant et plus souple (et en C lui) qui remplace en particulier postgrey aussi et permet d'utiliser les features de sessions de POLICY de Postfix.

          cf http://pfixtools.mymind.fr/
      • [^] # Re: sqlgrey...

        Posté par . Évalué à 1.

        D'un autre coté greylisting + RBL te donne le temps de rejeter temporairement les mails inconnus, le temps que les RBLs soient a jour, pour ensuite les jetter definitivement.

        Franchement greylist + RBL + petite liste des serveurs SMTP legitimes mais mal gérés, ca marche d'enfer et jamais eu de plaintes de mes utilisateurs.

        --
        Thomas
        • [^] # Re: sqlgrey...

          Posté par . Évalué à 1.

          Quelle est le meilleur ordre ? greylist puis rbl ou l'inverse ?
  • # Le SMTP de l'X

    Posté par . Évalué à 4.

    L'idée évoquée ici me semble fort intéressante, mais s'il elle vient bien de l'école polytechnique, alors beaucoup de choses ont changé depuis.

    Il y a moins d'un an, le serveur de messagerie que j'administre (sur une dédibox) comptait, parmi sa dizaine d'utilisateurs, une jeune personne qui fréquentait des élèves de l'X. Assez logiquement, j'ai donc eu assez régulièrement des courriels à faire suivre à leur SMTP. Et ça là que, bien souvent, le bât a blessé : des mails refusés sans autre forme de procès, soit disant que mon réseau n'était pas digne de confiance.

    L'analyse étant assez légitime (c'est dédibox, après tout), je me suis alors tourné vers l'administrateur du-dit serveur (pas celui qui est cité dans ce journal, apparemment) en lui demandant comment procéder pour faire suivre. Vu la fréquence et l'importance du traffic Moi -> X à ce moment-là, j'étais près à pas mal de concessions (rajouter une méthode d'authentification tordue, échanger des certificats, peu importait).

    Seulement voilà, la réponse du monsieur était sans appel : pour envoyer du courriel à polytechnique, il fallait passer par le SMTP d'un FAI (un smarthost, donc). Manque de bol, dédibox ne propose (proposait?) pas un tel service. J'étais donc dans l'incapacité de mettre en place un flux opérationnel vers leur SMTP, sauf à déménager mon serveur. Paradoxalement, j'aurais été mieux servi avec un sereur hebergé chez moi (malgré les règles souvent drastiques envers les IPs dites "résidentielles", j'aurais au moins pu bénéficier d'un smarthost en règle). Détail comique : les mails que j'ai reçu de ce monsieur ne respectaient pas la règle qu'il édictait lui-même (il attaquait mon serveur "en direct"). Si tout le monde avait appliqué sa politique, l'école polytechnique aurait été dans l'incapacité d'envoyer du courriel à qui que ce soit.

    Pour nuancer un peu mon propos, les choses ont fini par s'arranger partiellement, et j'ai pu bénéficier d'un flux entrant "jusqu'au moindre spam émanant de chez moi", après quoi il coupait définitivement. Dans la pratique, la connectivité était "alternative" : par moments, ça passait, par d'autres nada. Cela fait un moment que je n'ai pas regardé où l'on en était, cela dit. Mais j'espère que c'est la politique décrite dans ce journal qui est actuellement en place, plutôt que celle que j'ai malheureusement expérimenté. L'école en question faisant encore partie des "symboles" français visibles à l'étranger, il serait souhaitable qu'elle fasse _aussi_ bonne figure lors des dialogues SMTP ;)
    • [^] # Re: Le SMTP de l'X

      Posté par . Évalué à 1.

      J'avais eu le même cas avec une grosse société de télécom canadienne, mais là, c'est mon serveur chez moi qui attaqué directement le MX, sans passer par mon FAI.
      - Mail refusé
      - envoie demande d'explication (postmaster@...)
      - il m'explique leur politique de sécurité
      - je lui demande d'ouvrir mon domaine
      - Ce qu'il a fait.

      Résultat, réglé en une ou deux heures.
    • [^] # Re: Le SMTP de l'X

      Posté par . Évalué à 1.

      Juste pour info, le smtp de polytechnique.fr et de polytechnique._org_ ne sont pas du tout les mêmes, ni administrés par les mêmes personnes.

      Celui qui utilise des RBLs comme un sale c'est celui de l'école, en .fr. Celui en .org a utilisé whitelister pendant 2 ou 3 ans, et utilise maintenant son remplaçant que je vais tacher de packager, aka postlicyd des pfixtools, qui notament remplace postgrey qui est une grosse bouse imonde qui traine sa graisse (il lui fallait plus de 20 minutes pour effectuer son cron journalier, depuis notre réimplémentation il faut moins de quelques secondes).
  • # et en pratique...

    Posté par (page perso) . Évalué à 1.

    je l'utilises comment ?

    ça remplace postgrey, ou ça s'utilise en plus ? il faut toucher a son main.cf, etc, etc...
    je serais ravi d'être orienté vers une page qui explique un peu comment on s'en sert et comment ça se configure...

    \Ö<

    • [^] # RTFM :-)

      Posté par . Évalué à 1.

      Les sources de Whitelister (dispos par exemple sur http://ftp.de.debian.org/debian/pool/main/w/whitelister/whit(...) contiennent un fichier README qui détaille tout ce qu'il y a à savoir, comme en témoigne l'extrait ci-dessous :

      Whitelisyer is intended to be used like that :
      (1) Default inet socket :
      in your main.cf :

      smtpd_recipient_restrictions =
      ...
      reject_unauth_destination
      check_policy_service inet:127.0.0.1:10000
      ... here your nasty treatments , like postgrey ...

      Whitelister s'utilise en plus (avant, en fait) de postgrey, il faut éditer un fichier de conf propre à whitelister et le main.cf de postfix.

      ATTENTION néanmoins avant de faire n'importe quoi sans comprendre. Si l'appel à whitelister est placé trop en amont, le serveur SMTP sera potentiellement un relais ouvert. Chaque changement doit être compris et surtout validé. On trouve plein de site permettant de tester si une machine est open relay ou non...
  • # C'est moi ou les modules ocaml c'est lourd à installer ?

    Posté par (page perso) . Évalué à 1.

    Car oui je n'ai pas débian et installer les modules nécessaires pour whitelister ca n'a pas l'air au point sans compter que je connais pas trop ocaml :p

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.