Faux Enregistrement MX
Bonjour, Je suis actuellement à la recherche d'une potentielle solution Online pour protéger un serveur mail en scannant via un système type AltoSpam ou similaire. Il se trouve que lors de cette recherche, je suis tombé sur de nombreux tips qui propose d'ajouter sur le serveur DNS des faux enregistrements MX : - https://wiki.apache.org/spamassassin/OtherTricks - http://goo.gl/EtqiEX - http://goo.gl/iXeKa0 - http://www.hermes-project.com/pages/fakehermes Je me demande tout de même si il n'y a réellement aucun risque de perte de mail avec l'utilisation d'une telle "astuce". Si vous avez des retours, n'hésitez pas, et merci d'avance :) Bonne fin de journée. -- Sébastien
On 03/10/2013 17:02, Séb wrote:
Je suis actuellement à la recherche d'une potentielle solution Online pour protéger un serveur mail en scannant via un système type AltoSpam ou similaire.
Il se trouve que lors de cette recherche, je suis tombé sur de nombreux tips qui propose d'ajouter sur le serveur DNS des faux enregistrements MX : - https://wiki.apache.org/spamassassin/OtherTricks - http://goo.gl/EtqiEX - http://goo.gl/iXeKa0 - http://www.hermes-project.com/pages/fakehermes
Je me demande tout de même si il n'y a réellement aucun risque de perte de mail avec l'utilisation d'une telle "astuce".
Si vous avez des retours, n'hésitez pas, et merci d'avance :)
Bonjour, Je suis assez fan des "fake MX", ce qui permet de se débarasser d'une quantité inimaginable de zombies, bots, ... Inconvénient: Tu *dois* dédier une IP à cet effet. Je ne me risquerai en effet pas à avoir un enregistrement MX d'un nom ne résolvant pas, voire pire, de le faire pointer vers une IP contrôlée par un tiers. Une 2eme solution (temporaire, car les spammeurs s'adaptent) est d'annoncer un MX (avec la priorité la plus faible) en IPv6 seulement. Attention alors aux exchange, qmail, ... qui apprécient (appréciaient?) assez moyennement (vécu il y'a ~18 mois). Selon le profil de tes utilisateurs (clients, ...), ... tu peux aussi blacklister un pays, continent, ... Question: Pourquoi ne pas utiliser une solution type SPAMd (OpenBSD) en frontal, puis un système de scoring sur plusieurs RBLs, contrôle des HELO, reverse DNS, ... ?
Bonjour moi j'utilse depuis plusieurs année une passerelle fitrante sur les ip des mes mx port 25 et 465 : ASSP http://www.magicvillage.de/~Fritz_Borgstedt/assp/0003D91C-8000001C/ ça fonctionne très bien mais c'est un peu long a configurer Hugues. Le 03/10/2013 17:02, Séb a écrit :
Bonjour,
Je suis actuellement à la recherche d'une potentielle solution Online pour protéger un serveur mail en scannant via un système type AltoSpam ou similaire.
Il se trouve que lors de cette recherche, je suis tombé sur de nombreux tips qui propose d'ajouter sur le serveur DNS des faux enregistrements MX : - https://wiki.apache.org/spamassassin/OtherTricks - http://goo.gl/EtqiEX - http://goo.gl/iXeKa0 - http://www.hermes-project.com/pages/fakehermes
Je me demande tout de même si il n'y a réellement aucun risque de perte de mail avec l'utilisation d'une telle "astuce".
Si vous avez des retours, n'hésitez pas, et merci d'avance :)
Bonne fin de journée.
Hello, Ma petite expérience vis a vis des MX et du spam : 1- Avoir TOUT SES MX sous contrôle. Le postulat de base. Si l'un des mx est un gruyère, la dose de spam augmente de facon exponentielle 2- Les répondeurs (out of office) c'est mal, très mal. A- C'est un trou de secu : on sait quand telle ou telle personne n'est pas là (surtout les administrateurs) B- Ca aide les spammeur a apprendre de nouveaux mails ("eg je ne suis pas la veuiller contacter truc sur toto@example.com"), et aussi ça les aident a confirmer que l'email n'est pas tombé dans /dev/null (et que ca passé a travers le SA) C- Ca peux faire chier les mailing listes (outlook par exemple) 3- Les poids des MX, les spammeurs s'en foutent, sauf si le poids est > 1000 étonnamment... 4- Le graylisting evite une partie du spam, mais les utiliseurs ralent car c'est lent. 5- Les RBL c'est bien mais... Donc il reste des trucs a faire : 1- Configurer le postfix pour faire les fâcho : si domaine inexistant sur le DNS -> Deny par ex. 2- Mettre postscreen 3- Utiliser quels RBL propres : dev.null.dk / spamhauss 4- Avoir une liste d'utilisateurs sur tous les MX qui permet donc de reject un mail innexistant 5- Utilisation de la verification d'adresse mail (attention ca peux merder avec free.fr, alors mettre un whitilist) 6- Clamav + les signatures tierces + spam assassin bien configuré, on arrive donc a faire baisser significativement le spam. 7- IPv6 c'est une idée, y a pas encore de spam (enfin pas beaucoup) qui y arrive, p'tet que finalement c'est la killer feature qui fera que l'IPv6 vas sortir du bois ? Xavier
Bonjour, Merci à tous pour vos réponses, qui en fait ne font que confirmer qu'il ne vaut mieux pas tenter d'utiliser cette solution si nous désirons recevoir *TOUS* nos mails :) Pour répondre à Laurent CARON & Hugues Max sur la mise en place d'une solution en interne de type "SPAMd" ou "ASSP", c'est uniquement pour simplifier l'administration que je souhaite en externaliser une partie, car actuellement nous devons créer un compte utilisateur sur notre serveur mail interne (Exchange) et un compte POP sur le serveur mail externe. Cette solution avait été mise en place suite à nos nombreuses coupures électrique et avant mon arrivée. Sinon pour de la gestion locale, je suis également passé rapidement sur les sites de "MailCleaner" et "Scrollout F1" qui proposent des solutions OpenSource. Pour répondre maintenant à Xavier Beaudouin, nous avons déjà chez notre prestataire actuel une solution AntiSPAM (SurgeMAIL), mais elle laisse malgré tout passer de nombreux mail. Nous avons testés en interne un Kaspersky Security 8.0 for Microsoft Exchange Servers, mais le temps d'apprentissage est un peu trop long, car au bout de 3mois il laisse toujours passer une partie des SPAM. De plus il peut mettre jusqu'à 30secondes pour traiter un mail, ce qui provoque des engorgements à son niveau. Je vais donc me rapprocher de Stephane MANHES afin de voir la solution qu'il propose. Merci encore et très bon WE à vous. -- Sébastien
On 10/04/2013 09:52 AM, Xavier Beaudouin wrote:
Donc il reste des trucs a faire :
5- Utilisation de la verification d'adresse mail (attention ca peux merder avec free.fr, alors mettre un whitilist)
Cela revient à déporter une partie du coût des filtres antispams sur un tiers. C'est mal...
7- IPv6 c'est une idée, y a pas encore de spam (enfin pas beaucoup) qui y arrive, p'tet que finalement c'est la killer feature qui fera que l'IPv6 vas sortir du bois ?
Quand Comcast a ajouté le support d'IPv6 sur ses MXes, le premier mail reçu en IPv6 a été un spam... IPv6 pose pas mal de question sur la gestion des RBLs du fait de l'espace d'adressage. La tendance actuelle est plutôt de laisser les MXes en IPv4 et d'attendre que la signature des mails par le domaine emeteur se généralise avant de migrer en IPv6 (la réputation se fera alors sur le domaine et non sur l'IP). François
Le 04/10/2013 14:05, Francois Petillon a écrit :
7- IPv6 c'est une idée, y a pas encore de spam (enfin pas beaucoup) qui y arrive, p'tet que finalement c'est la killer feature qui fera que l'IPv6 vas sortir du bois ?
Quand Comcast a ajouté le support d'IPv6 sur ses MXes, le premier mail reçu en IPv6 a été un spam...
IPv6 pose pas mal de question sur la gestion des RBLs du fait de l'espace d'adressage. La tendance actuelle est plutôt de laisser les MXes en IPv4 et d'attendre que la signature des mails par le domaine emeteur se généralise avant de migrer en IPv6 (la réputation se fera alors sur le domaine et non sur l'IP).
C'est effectivement un problème et surtout les RBL vont blacklisté quoi, une ip, le subnet du host, le subnet du prestataire car on connait pas l'étendu des subnets hosts (équivalent des PI/PA v4) attribués au client qui fait n'importe quoi? On est full ipv6 depuis plus d'un an sur toute notre archi dont les mails, on a 25% de nos requêtes dns en v6 ce qui commence à faire du monde, pour les mails j'ai vu que ça causait v6 avec Gmail et quelques entreprises de taille petite et moyenne qui avancent sur le sujet. Je vais donc regarder ce que ça donne niveau spam mais soit les filtres derrière font bien leur boulot soit on est pas encore concerné.
Hello, Le 10 oct. 2013 à 09:42, Wallace <wallace@morkitu.org> a écrit :
Le 04/10/2013 14:05, Francois Petillon a écrit :
7- IPv6 c'est une idée, y a pas encore de spam (enfin pas beaucoup) qui y arrive, p'tet que finalement c'est la killer feature qui fera que l'IPv6 vas sortir du bois ?
Quand Comcast a ajouté le support d'IPv6 sur ses MXes, le premier mail reçu en IPv6 a été un spam...
IPv6 pose pas mal de question sur la gestion des RBLs du fait de l'espace d'adressage. La tendance actuelle est plutôt de laisser les MXes en IPv4 et d'attendre que la signature des mails par le domaine emeteur se généralise avant de migrer en IPv6 (la réputation se fera alors sur le domaine et non sur l'IP).
C'est effectivement un problème et surtout les RBL vont blacklisté quoi, une ip, le subnet du host, le subnet du prestataire car on connait pas l'étendu des subnets hosts (équivalent des PI/PA v4) attribués au client qui fait n'importe quoi?
C'est marrant, car en 2000 (oui vous avez bien lu en 2000) quand avec v0x on jouais avec le 6bone, on se posais les mêmes questions. Certaines RBL (dont l'OBL) se sont pas compliqué : sachant que le subnet de base délégué est un /64 -> blacklist le /64. Ceci dit, les RBL vident pas mal de merde, mais il y a beaucoup de dommages collatéraux. Donc "se protéger qu'avec les RBL" c'est potentiellement avoir des clients furieux.
On est full ipv6 depuis plus d'un an sur toute notre archi dont les mails, on a 25% de nos requêtes dns en v6 ce qui commence à faire du monde, pour les mails j'ai vu que ça causait v6 avec Gmail et quelques entreprises de taille petite et moyenne qui avancent sur le sujet. Je vais donc regarder ce que ça donne niveau spam mais soit les filtres derrière font bien leur boulot soit on est pas encore concerné.
Le DNS en IPv6 c'est facile et le protocole DNS est prévu dès le début pour être assez fiable en IPv6 ET en IPv4. (Checkez le log d'un unbound ou bind9 avec un support ipv6 dans le code mais pas d'ipv6 sur la machine, vous verrez que ca marche quand même très bien !). D'ailleurs les gars qui ont un site web accessible en IPv6 et pas un DNS... C'est un peu marcher sur la tête. Par contre, les recommandations ipv4 (plusieurs DNS dans plusieurs réseaux) sont aussi valables sur IPv6 (typiquement 3 DNS, 3 en IPv4 et un seul en IPv6 = danger). Pour revenir au spam en IPv6, j'ai plus de pseudo spam dûes aux ml en mousse de google ou, là clairement, les RBL = DTC. Et donc il n'y a que des check "élevés" qui peuvent être utilisés. Donc le coup : je ne vais pas mettre d'IPv6 parce que je pers les RBL qui n'existent pas en IPv6 = bullshit. A noter que FranceIX a foutus dehors Barracuda, et d'autres trucs antispam il y a 2 ans car ces rigolos ne sortais rien en IPv6. Un bon SA + avamvisd-new + clamav (et signatures tierces) font bien leur travail... D'ailleurs. Accepter en IPv6 et router en IPv4 en interne n'empêche pas les trucs legacy de fonctionner.... Xavier PS: qui a sont mail / web / dns en full ipv6 depuis plusieurs années.
participants (6)
-
Francois Petillon -
Hugues Max -
Laurent CARON -
Séb -
Wallace -
Xavier Beaudouin