Statistiques de greylisting

Pour ceux qui ne connaissent pas, le « Greylisting » est un mécanisme utile et extrêmement simple à mettre en oeuvre pour réduire significativement le nombre de spams en entrée des serveurs de mails, sans même avoir besoin de les analyser. En gros, vous pouvez diviser par 10 vos mails entrants et le boulot de votre spamassassin, du coup.
Magique ? non, logique.
Je vous propose dans cet article un résultat chiffré sur une installation comptant un backup MX, un frontal (qui encaisse les tentatives d’abus etc + analyse virus) relayant enfin à un serveur final (backend) faisant tourner un bon gros spamassassin/SARE des familles avant la distribution du courrier. Le tout pour desservir 150 utilisateurs et/ou boîtes mails environ (sans compter des vieux comptent qui n’existent plus et que les spammeurs doivent avoir encore « en tête »).
La mise en place du greylisting pour postfix est détaillée dans ma doc, il ne manque qu’une indication : démarrer le service postgrey après installation 🙂

Informations en préambule

Les impacts pour l’utilisateur sont minimes : délai d’environ 30 minutes (en théorie 5 minutes) lors des x (x = 5 par défaut) premiers échanges entrants avec un serveur donné. L’article anglais sur wikipedia se veut un peu plus méfiant que sa traduction minimaliste en français. A vous de voir. L’autre risque serait de se retrouver face à un vieux serveur de mails tout pourri qui implémente mal le protocole… boarf, je doute que ça arrive dans la pratique. Au pire l’utilisateur verra le problème et il sera temps de whitelister ledit serveur.

Principe

Le principe – je vous renvois à l’article wikipedia pour plus de détails – est d’utiliser une fonction standard du procotole SMTP pour redemander l’envoi d’un mail lorsqu’on le reçoit. On indique au serveur de renvoyer le message dans 5 minutes. Deux options : le serveur en face le fait, ou non. Au bout de x fois – si le serveur s’est bien comporté – on le « whiteliste » pour de bon et il n’y aura plus de délai pour celui-ci.

Quel lien avec les spammeurs ?

Imaginez une armée de PC (windows) zombies envoyant des mails à tout va (à l’insu de l’utilisateur, forcément). Le zombie utilise un programme le plus simple possible qui se contente d’envoyer la purée. De toute manière, un PC zombie comme de ce type n’a en général pas de lien retour possible vers lui même sur le port 25 (pensez à votre PC derrière un routeur genre freebox). Donc il ne recevra jamais votre demande standard de renvoi de mails. Et donc vous n’aurez jamais le mail, qui était un spam à coup sûr. CQFD.
Lisez plus bas dans l’article quelques extraits d’adresses « greylistées », vous comprendrez que des zombies, il y en a des millions sur la planète… que fait Buffy ???
Reste ensuite les *vrais* spammeurs. Je ne sais pas dire si beaucoup d’entre eux utilisent des serveurs standard de mails. Ceux qui n’ont pas prévu le coup en tout cas, ils passent aussi à la benne. Les autres, je ne sais pas s’ils perdent du temps à renvoyer la purée alors que des gens mal protégés, il y en a tant d’autres…
Alors, en attendant que les zombies prennent en charge correctement le protocole et fasse des contournements réseaux compliqués (impossible ?), le greylisting peut vous aider.

Léger pré-requis sur les backups MX

Dernière petite remarque en préambule : il faut que tous vos serveurs frontaux (donc les backups MX) implémentent le greylisting !!! Donc oubliez les backups gracieusement offerts par votre fournisseur/hébergeur etc. En général ils ne le font pas. Si vous avez un tel backup MX – par pseudo-sécurité – il est en général déclaré de faible priorité et c’est justement celui qui est d’abord visé par les envois de spammeurs car on n’a moins souvent la main dessus. S’il ne greyliste pas, alors il enverra tout à votre MX principal qui acceptera sans broncher. Le greylisting ne servira pas à grand chose dans ce cas.
(Tiens, ça me fait penser à une technique qui consiste à utiliser un serveur inexistant comme MX de plus faible priorité. Faudra que je teste ça un jour. Si quelqu’un a un retour, je suis preneur)

Graphiques après plusieurs semaines d’utilisation

Plutôt qu’un long discours, quelques dessins. Je vous laisse deviner la date de mise en place…

Sur le frontal (MX primaire) :
Greylisting sur le frontal

Et sur le backend (qui identifie les spams une fois le mail accepté) :
Greylisting sur le backend

En chiffres

Avec quelques chiffres moyens pris avant et après le greylisting (ceux sur le graphe sont pris « pendant » la mise en place, donc une moyenne d’avant/après, pas terrible), ça donne ça :
– Sur le frontal, avant, on recevait environ 9,5 msg/min et on rejetait 1/3 (tentatives d’openrelay, destinataires bidon etc). Maintenant, on en reçoit 3,2 par minute, toujours 1/3 de rejet pour les mêmes motifs.
– Sur le backend du coup, il y a une sacrée chute d’occupation CPU par « spamd » et on identifie 0,6 msg/min contre 6 par minute avant (même taux de faux-positifs ou d’oubli, à savoir presque nul).
– En une semaine, ce ne sont pas moins de 137000 « serveurs » (zombies) qui ont été greylistés, avec des charmants noms comme :

         0x50a1511f.hknxx3.adsl-dhcp.tele.dk[80.161.81.31] 2 Time(s)
         0x50a403bf.abnxx10.adsl-dhcp.tele.dk[80.164.3.191] 2 Time(s)
         103.95.119-80.rev.gaoland.net[80.119.95.103] 4 Time(s)
         12-208-209-2.client.mchsi.com[12.208.209.2] 2 Time(s)
         12-219-39-94.client.mchsi.com[12.219.39.94] 2 Time(s)
         124-171-184-145.dyn.iinet.net.au[124.171.184.145] 2 Time(s)
         129-28-235-201.fibertel.com.ar[201.235.28.129] 2 Time(s)
         131.201.218.87.dynamic.jazztel.es[87.218.201.131] 2 Time(s)
         131.206.50.60.cbj04-home.tm.net.my[60.50.206.131] 2 Time(s)
         1434933186.ip2long.net[85.135.87.194] 2 Time(s)
         149.pool85-49-8.dynamic.orange.es[85.49.8.149] 2 Time(s)
         1503021874.dhcp.dbnet.dk[89.150.75.50] 4 Time(s)
         152-60.go.evo.bg[85.217.152.60] 2 Time(s)
         156-90-99-58-T-tdtv.tinp.net.tw[58.99.90.156] 2 Time(s)
         167-68-246-201.adsl.terra.cl[201.246.68.167] 2 Time(s)
         168-226-244-166.mrse.com.ar[168.226.244.166] 2 Time(s)
...
         adsl-67-114-84-118.dsl.lsan03.pacbell.net[67.114.84.118] 2 Time(s)
         adsl-68-23-4-190.dsl.ipltin.ameritech.net[68.23.4.190] 2 Time(s)
         adsl-69-209-147-42.dsl.sfldmi.ameritech.net[69.209.147.42] 2 Time(s)
         adsl-69-209-154-96.dsl.sfldmi.ameritech.net[69.209.154.96] 2 Time(s)
...
         host234-234-static.116-81-b.business.telecomitalia.it[81.116.234.234] 2 Time(s)
         host241-167-dynamic.19-79-r.retail.telecomitalia.it[79.19.167.241] 2 Time(s)
         host246-209-dynamic.15-87-r.retail.telecomitalia.it[87.15.209.246] 2 Time(s)
         host248-13-dynamic.1-87-r.retail.telecomitalia.it[87.1.13.248] 2 Time(s)
...
         pool-71-241-246-243.washdc.fios.verizon.net[71.241.246.243] 2 Time(s)
         pool-71-244-163-181.chi01.dsl-w.verizon.net[71.244.163.181] 2 Time(s)
         pool-71-246-128-243.aubnin.fios.verizon.net[71.246.128.243] 2 Time(s)
         pool-71-251-115-130.tampfl.fios.verizon.net[71.251.115.130] 2 Time(s)
         pool-71-251-140-235.cmdnnj.east.verizon.net[71.251.140.235] 2 Time(s)
         pool-71-252-137-81.dllstx.fios.verizon.net[71.252.137.81] 2 Time(s)
         pool-71-99-87-26.tampfl.dsl-w.verizon.net[71.99.87.26] 6 Time(s)
...
         ppp83-237-30-117.pppoe.mtu-net.ru[83.237.30.117] 2 Time(s)
         ppp85-140-146-212.pppoe.mtu-net.ru[85.140.146.212] 2 Time(s)
         ppp85-140-21-109.pppoe.mtu-net.ru[85.140.21.109] 2 Time(s)
         ppp85-140-43-193.pppoe.mtu-net.ru[85.140.43.193] 2 Time(s)
         ppp85-141-174-160.pppoe.mtu-net.ru[85.141.174.160] 4 Time(s)
...
         unknown[116.22.163.196] 6 Time(s)
         unknown[116.45.106.170] 2 Time(s)
         unknown[117.12.65.40] 4 Time(s)
...

- 

Conclusion

N’hésitez pas, apt-get install postgrey, modif du fichier main.cf et reload de postfix. Ca prend 3 minutes et ça envoi du gros !

5 comments

  1. Juste pour information : pas besoin de « chemin retour » pour indiquer à l’émetteur qu’il y a une erreur temporaire (le coeur du greylisting). C’est transmis par la connexion SMTP initiale. Donc le spammeur potentiel recevra _toujours_ la « demande standard de renvoi de mail ». Et vu l’évolution de mes statistiques de greylisting depuis quelques années, ils commençent à avoir pigé le truc. Mais le fait de greylister les 5 premiers envois au lieu d’un seul doit limiter la casse (et en tous cas faire perdre 5 fois plus de temps aux spammeurs).

    Pour la partie logicielle, je suis en général plus adepte de postfix-policyd, qui offre l’avantage de pouvoir faire piège-à-miel (ou honeypot : une ou plusieurs adresses fictives et improbables qui ajoutent automatiquement tout émetteur dans une liste noire), régulateur de flux (pour gérer une QoS rudimentaire), etc.

    Pour le fait d’avoir un MX inexistant, c’est probablement efficace, mais il n’y a guère de moyen de s’en assurer : par définition, les tentatives d’envoi sur ce MX ne seront jamais comptabilisées.

  2. Mmmmm, certes, tu dois avoir raison. Je ne sais pas pourquoi je me suis mis dans la tête qu’une fois l’envoi effectué, la connexion était fermée. Mais en effet, la réponse du destinataire fait parti du dialogue lors de l’envoi…

    J’ai aussi lu qu’il était bon de virer sa base de serveurs whitelistés par postgrey, de temps en temps. Si ton greylisting date un peu, peut-être que ça lui filera un coup de jeune. Tiens moi au courant. Attention : RAZ => léger délai pour tes utilisateurs pendant quelques jours.

    Mon autre installation de greylisting – qui a + d’un an – n’est pas assez grosse (~10 users) pour y voir quelque chose.

    Pour le MX inexistant, tu verrais l’impact par une baisse du nombre de spams en entrée de ton vrai MX, si le programme du spammeur est assez con pour ne pas tenter un autre MX (et si le « chemin retour » est possible ;).

    merci pour le post

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.