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 Henry-Nicolas Tourneur (site web personnel) . Évalué à 2.
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 suJeSelS . Évalué à 4.
[^] # Re: Effets de bord
Posté par fcartegnie . Évalué à 5.
[^] # Re: Effets de bord
Posté par Pascal Terjan (site web personnel) . Évalué à 5.
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 Henry-Nicolas Tourneur (site web personnel) . Évalué à 2.
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 Amand Tihon (site web personnel) . Évalué à 4.
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 GG (site web personnel) . Évalué à 2.
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
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Le truc du MX secondaire
Posté par Amand Tihon (site web personnel) . Évalué à 7.
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 Amaury . Évalué à 6.
> 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 Amand Tihon (site web personnel) . Évalué à 3.
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 Joris Dedieu (site web personnel) . Évalué à 1.
Ou tout simplement pour y balancer le backscatter.
http://en.wikipedia.org/wiki/Backscatter
# RFC 2821 --> 5321
Posté par chl (site web personnel) . Évalué à 8.
http://www.ietf.org/rfc/rfc5321.txt
# moué
Posté par TImaniac (site web personnel) . Évalué à 3.
Nan parcque les spammeurs s'adaptent et fassent plusieurs tentatives d'envoi ?
[^] # Re: moué
Posté par Henry-Nicolas Tourneur (site web personnel) . Évalué à 5.
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 JoeltheLion (site web personnel) . Évalué à 2.
[^] # Re: argument "rien ne dit que ça fonctionnera dans 2 semaines/10 ans"
Posté par Amaury . Évalué à 4.
Ce n'est pas parce qu'une technologie sera (éventuellement) obsolète demain qu'il ne faut pas l'utiliser aujourd'hui...
[^] # Re: argument "rien ne dit que ça fonctionnera dans 2 semaines/10 ans"
Posté par JoeltheLion (site web personnel) . Évalué à 2.
[^] # Re: argument "rien ne dit que ça fonctionnera dans 2 semaines/10 ans"
Posté par Henry-Nicolas Tourneur (site web personnel) . Évalué à 1.
Ne voit pas ceci comme une quelconque agression mais, comme je l'ai déjà dit, je ne suis pas un expert du domaine donc je ne fait que livrer mon analyse de la situation (qui est donc potentiellement éronée).
Si ce que je pense est incorrecte, je préfère mille fois que tu me corrige plutôt que d'en rester là.
[^] # Re: moué
Posté par Henry-Nicolas Tourneur (site web personnel) . Évalué à 2.
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 Henry-Nicolas Tourneur (site web personnel) . Évalué à 2.
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 Pierre Habouzit . Évalué à 1.
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 Xavier . Évalué à 1.
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 Amaury . Évalué à 2.
> 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 Zenitram (site web personnel) . Évalué à 4.
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 Pierre Habouzit . Évalué à 1.
* 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 Thomas Pedoussaut . Évalué à 1.
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 wilk . Évalué à 1.
# Le SMTP de l'X
Posté par Larry Cow . Évalué à 4.
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 Anthony Jaguenaud . Évalué à 1.
- 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 Pierre Habouzit . Évalué à 1.
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 Effraie (site web personnel) . Évalué à 1.
ç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 Amaury . Évalué à 1.
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 Dup (site web personnel) . Évalué à 1.
[^] # Re: C'est moi ou les modules ocaml c'est lourd à installer ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
[^] # Re: C'est moi ou les modules ocaml c'est lourd à installer ?
Posté par Dup (site web personnel) . Évalué à 1.
[^] # Re: C'est moi ou les modules ocaml c'est lourd à installer ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: C'est moi ou les modules ocaml c'est lourd à installer ?
Posté par GG (site web personnel) . Évalué à 2.
entre temps, je suis passé à aptitude, qui gère bien mieux les dépendances.
Il faut savoir évoluer avec son temps :)
Il y a aussi adept qui semble pas mal du tout, mais que en mode graphique.
A bientôt
Grégoire
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: C'est moi ou les modules ocaml c'est lourd à installer ?
Posté par Dup (site web personnel) . Évalué à 2.
Mais tout sauf une ubuntu que je suis loin de trouver stable :/
[^] # Re: C'est moi ou les modules ocaml c'est lourd à installer ?
Posté par Metzgermeister . Évalué à 3.
[^] # Re: C'est moi ou les modules ocaml c'est lourd à installer ?
Posté par auve . Évalué à 2.
Une fois compilé nativement, un exécutable écrit en OCaml est parfaitement indépendant du compilateur ou d'une forme quelconque d'environnement d'exécution.
[0] : http://godi.camlcity.org/godi/index.html
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.