[FRnOG] Re: [FRnOG] Re: [De plus en plus HS] Problème DNS S FR
2010/8/25 Clément Game cg...@xooloo.net: Stephane Bortzmeyer wrote: On Wed, Aug 25, 2010 at 04:09:36PM +0200, Yann GAUTERON yann.gaute...@gmail.com wrote a message of 68 lines which said: le courriel qui me hérisse toujours les poils. Moi aussi, mais peut-être pas pour les mêmes raisons : http://www.bortzmeyer.org/non-a-courriel.html --- Liste de diffusion du FRnOG http://www.frnog.org/ IMHO c'est beaucoup de blabla pour pas grand chose. De meme que je trouve un peu limite de perdre son temps à écrire une diatribe de 5 paragraphes pour expliquer pourquoi il n'est pas convenable d'utiliser le terme courriel, alors que moult améliorations ( que je n'énumérerais pas ici pour cause de non-trolldi) reclameraient toute l'attention des administrateurs de l'AFNIC C. Bonjour, Sans me faire le défenseur (ni l'accusateur) de l'AFNIC, je trouve le propos complètement déplacé (je crois que chacun occupe son temps comme il le souhaite, que ce soit du temps personnel (pour lequel on ne doit de compte à personne, sauf éventuellement à Madame) ou le temps professionnel (qui ne regarde globalement que les supérieurs hiérarchiques)) et accessoirement injustifié (puisque le billet date de 2009...) On s'interrogera cependant sur l'origine du temps utilisé pour rabrouer, sur cette liste, d'autres personnes. Personnellement, je suis en vacances et Madame n'est pas à la maison ! Champagne :P Bonne journée Florian MAURY --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] DNS RPZ
plus en demander d'autre = je ne peux plus spammer puisque je n'ai pas la possibilité de configurer des records DNS et qu'ils sont indispensables à la livraison de mes courriers. Si les grands webmail (plouf plouf live, gmail, yahoo) se mettent à appliquer ce genre de politique, on peut être sur de voir une adoption assez rapide et radicale. Bref, après cette digression sur le spam, et pour en revenir au sujet initial, ai-je manqué une étape ? Quel est votre avis sur DNS RPZ ? Cordialement, Florian MAURY S'en est suivi une réponse de Greg (le fondateur de FRsAG), que voici : Bonjour, Le 31/07/2010 01:39, Florian MAURY a écrit : J'ai beau me torturer, je ne vois pas le moindre intérêt à cette idée [...] On voit donc bien que ce genre de technologie n'apportera rien : le problème est ailleurs ; à mon sens, il se situe au niveau des registrars ; mais ça, ce n'est peut être pas politiquement correct de l'annoncer ouvertement de leur part. Remarque inutile, mais je suis entièrement d'accord avec toi. Une solution qui me parait viable serait tout simplement de renforcer le contrôle identitaire à la délégation d'un nom de domaine (notez l'emploi du terme délégation et non achat), par injonction de l'IANA et consort auprès des TLD. Si une personne physique ne peut plus enregistrer de nom de domaine pendant une période de X années après un abus constaté et que l'ensemble de ses noms de domaines sont repris par les registres en cas de faute, mathématiquement le nombre de domaines malicieux va être appelé à descendre. Afin d'empêcher la réservation massive (pour une campagne de spam, au hasard), la limite serait également imposée sur la quantité de noms de domaines réservables sur une période donnée. +1 Quel est le frein pour mettre ce système en place ? Les coûts de gestion administrative ? Face aux coûts du SPAM et autres systèmes de sécurité, ça me parait dérisoire, mais ce ne sont pas les mêmes personnes qui payent. Si je spam, on me reprend mes domaines et je ne peux plus en demander d'autre = je ne peux plus spammer puisque je n'ai pas la possibilité de configurer des records DNS et qu'ils sont indispensables à la livraison de mes courriers. Il reste la technique du kebab: une fois chopé, on change de noms de propriétaire: ma sœur, cousine, mes frères, ma grand-mère Mais ça limite quand même énormément les possibilités. J'aurais bien aimé avoir l'avis de Bortzmeyer mais il n'est pas membre de la liste. -- Greg -- Je me permets de plussoyer l'envie d'avoir un avis de Stéphane Bortzmeyer (entre autre, sinon je lui aurais écrit en personne) qui pourrait m'ouvrir les yeux sur des choses ignorées et me ferait me repentir de penser de telles choses :) En vous remerciant, Florian MAURY --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] DNS RPZ
2010/8/2 Jiw j...@jiworld.net: L'aspect philosophique. Sans parler d'un cadre philosophique, qui est relativement subjectif, il y a effectivement un cadre juridique, qui est très présent et problèmatique. Je me réponds à moi même puisque mes réflexions sur le sujet m'ont amené à cela : * Un registrar aurait il le droit de supprimer le contrat qui le lie à son client en cas de plaintes justifiées de tiers à propos de l'utilisation d'un nom de domaine dont il a donné la délégation, sans risquer de subir des représailles judiciaires de la part de son client (spammeur ou hammeçonneur, par exemple) en vu de toucher des dommages et intérêts sur l'interruption de son business (aussi légal ou non qu'il soit) ? * Un registrar aurait il, dans l'hypothèse où la réponse à la première assertion indiquerait que le droit de retrait d'usage est légal et sans représailles, le droit de faire un refus de vente pour causes historiques ? Si oui, ceci est il valable partout ? Au final, après cette réflexion, l'usage de DNS RPZ me vient un peu plus en tête (établir une liste qui n'ait pas besoin de cadre légal parce qu'appliquée au bon vouloir (et considéré comme best-pratice, à la limite)), mais dans la seule limite où l'owner du domaine ne puisse pas être dissimulé ni usurpé (contrôle approfondi) afin de pouvoir dresser une liste non pas de domaines nuisibles mais de owner nuisibles. Reste toujours le problème du kebab, comme le soulignait Greg (qui ne s'arrête pas qu'aux proches : on peut tout à fait imaginer l'utilisation de personnes payées pour enregistrer le nom de domaine contre paiement) ... A ca, je n'ai pas encore trouvé de solution. Florian MAURY --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: Suggestion pour les attachements lourds (was:Re: [FRnOG] Antispam : vaderetro, ironport, proofpoint... vos avis.)
2010/7/30 Jérôme Nicolle jer...@ceriz.fr: Le 30/07/10 11:29, Alain Richard a écrit : Mouiais, à mon humble avis, les gens qui utilisent le mail comme un moyen d'acheminement temps réel n'ont pas tout compris au film, ce sont souvent les mêmes qui se pleignent de ne pas pouvoir envoyer leur dernier PowerPoint de 100Mo pas mail :-). J'ai tenté (mais pas fini) de poser un bout de code qui dissocie les pièces jointes pour les acheminer vers un dépôt accessible en HTTP, et ce automatiquement à l'envoi du mail, par le relai SMTP local. Je n'ai pas trouvé de code tout fait et je n'ai pas eu le temps de finir le mien, vous savez si ça existe ? Dans l'idée : - Si la taille du mail dépasse 5Mo - Si des attachements dépassent 1ko (pour laisser les images des signatures et ces conneries là) - Les attachements de plus de 100ko sont détachés, hashés et envoyés sur un dl.free.fr-like interne, associé au mail-id - Le contenu du mail est altéré pour ajouter _en début de mail_ le lien de téléchargement - Le code coté httpd retourne par mail un accusé de téléchargement des pièces jointes à l'expéditeur Ca devrait être adaptable pour pas mal de cas d'utilisation, et le fait de hasher les fichiers et de les envoyer sur un canal distinct permet de dédupliquer et/ou compresser le contenu. Qu'en dites vous ? Ca vaudrait le coup de finir de développer ce merdier ? Bonjour, L'idée est intéressante ; elle l'est d'autant plus si on ajoute un système de détection des pièces jointes de masse et qu'on les repère par hash. Reste qu'il faudrait patcher le serveur imap (et quid du pop dans ce cas ?) pour supprimer la pièce jointe quand le mail est supprimé, sinon bonjour le stockage ad vitam (et supprimer la pièce après un délai n'est pas souhaitable car on en sait pas à l'avance l'attachement d'un user à un attachment :P Pour ce qui est de l'aspect technique de la solution, tu risques également d'être confontré à des problèmes avec les mails signés puisque tu altères le contenu en rajoutant le lien (je ne parle pas de clear signed GPG) Tant que ces deux points n'ont pas été résolus, il me parait cependant difficile d'implémenter une telle solution. Cordialement, Florian MAURY --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: Suggestion pour les attachements lourds
2010/7/30 Jérôme Nicolle jer...@ceriz.fr: - Chaque destinataire reçoit une URL différente pour chauqe fichier ou lot de fichier - Le serveur HTTP garde la trace des téléchargements et supprime la PJ dès que tous les destinataires l'ont téléchargé, ou passé un certain timeout Agir au niveau du MDA serait problématique puisque l'une des motivation est de réduire la place prise par les mailboxes des destinataires (très problématique en cas de politique de sauvegarde centralisée des mails...) Je comprends l'idée. J'avais bien percu le fonctionnement. Je parlais de purger le système à la suppression des mails (et qui la, demande un plugin/patch) et uniquement à ce moment là. Les users sont mal éduqués (quoique je fasse souvent pareil :/) et considèrent aussi le serveur de mail comme un serveur de fichier : si la pièce est dans un mail, tu retélécharges la pièce à chaque fois que tu en as besoin : les mails sont classés et les attachments avec. On ne peut donc pas supprimer un attachment du serveur de fichier dès le téléchargement par le user, et le timeout, comme expliqué dans mon précédent mail ne me parait pas envisageable. C'est une question d'opinion, après. Pour ce qui est de l'aspect technique de la solution, tu risques également d'être confontré à des problèmes avec les mails signés puisque tu altères le contenu en rajoutant le lien (je ne parle pas de clear signed GPG) Dans ce cas précis, c'est au niveau MUA qu'il faut agir, via un plugin qui opère _avant_ la signature du message, et fais signé la pièce jointe à part. Solution qui sera alors utilisable uniquement en interne, si cela se passe à l'expédition ; cela perd bcp de l'intérêt que j'y avais vu. A la première lecture de ta solution j'avais pensé qu'il s'agissait également de désengorger les serveurs mails des expéditeurs externes impolis. Tant que ces deux points n'ont pas été résolus, il me parait cependant difficile d'implémenter une telle solution. Tu as parfaitement raison, et c'est pour ça que je ne l'ai jamais fini :p Mais ça me tenterait bien de reprendre ce projet, pour le coup. C'est une bonne idée d'en parler en mailing list, alors, avant de s'y remettre :) Florian MAURY --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Comm ent vous protégez vous ?
Bonjour, Pour ce qui est des OTP, il n'y a pas eu de discussion publique : je l'ai contacté directement en privé pour éviter des gestes trop commerciaux directement sur la liste, mais puisque tu le demandes, je vais me faire un plaisir de parler d'un produit développé par mon précédent employeur et qui répond en parti au problème, puisqu'elle a déjà été utilisée pour sécuriser ce genre d'accès ; Il s'agit d'une solution d'authentification forte par téléphonie mobile, qui permet au travers d'un navigateur de générer de manière automatique un appel vocal avec le téléphone du client, puis de jouer un son sur l'ordinateur qui est un OTP sonore, chiffré et unique. Ce son entendu par le téléphone constitue une étape d'authentification, puisque effectuée par un autre média qu'Internet, non reproductible, et non transportable (une retransmission par un second téléphone ou autre dispositif avec compression altérera le message et le rendra inauthentifiable). L'authentification peut être renforcée par la demande pendant l'appel vocal de l'entrée d'un code PIN. Si le client voulant s'authentifier est susceptible de ne pas avoir de matériel sonore (enceintes, casque, etc...), il est possible d'effectuer l'authentification par l'entrée d'un code de transaction : il est à noter cependant que l'on perd dès lors l'OTP. Je précise, quitte à présenter le produit en détail qu'il est accessible en SaaS ou en mode appliance, rackable en datacenter, et que le produit est commandable à partir de n'importe quel langage disposant d'une librairie d'appel SOAP. Je précise également que cette solution est compatible avec tous les téléphones, tous les opérateurs, dans tous les pays. Je suis là demain, pour en parler, si vous le souhaitez. Je vous laisse l'URL du site, afin de pouvoir tester la solution et pouvoir discuter du produit en connaissance de cause demain. http://www.certificall.net Ce type de solution s'intercale donc très bien dans l'étape d'authentification pour accès à l'espace privé du client. Il est dès lors possible de savoir que le client est bien celui qu'il prétend être, et ouvrir son IP sur le firewall pour une session de courte/moyenne durée. Le client peut donc partir en vacances à l'autre bout du monde et toujours pouvoir se connecter d'urgence (ne me remerciez pas de vous gacher vos vacances ;) ) A demain, Florian MAURY 2010/6/24 Mehdi Badreddine mehdi.badredd...@gmail.com: à ce propos, quid des OTP ? des retours d'expériences ? Mehdi Le 24 juin 2010 10:35, Jérémie Pogeant jeremie.poge...@gmail.com a écrit : [snip] Citez moi un serveur SFTP qui est capable de : - faire des soft quota - trouver ses uid/gid/login/pass/clef publique depuis une db ou un annuaire ldap - qui soit évidement opensource et portable ailleurs que sur du linux... [/snip] proFTPd avec mod_sftp et mod_sql (pour la base des users). Il est compatible avec la gestion des quotas. Par contre je ne sais pas pour le stockage de la clé publique dans la db. -- Jérémie Pogeant --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [FRnOG] RE: [Comment vous protégez vous ?
Bonjour, En fait, les banques trouvent actuellement le système par SMS insuffisant et sont obligées de chercher des solutions à authentification plus forte. La solution de remplacement devrait être disponible dans les quelques mois/années à venir : les process des banques sont toujours super longs (dans un soucis de qualité, certainement ^^). Toujours est il que le SMS n'est pas assez sécurisé : * Il peut être lu par n'importe qui * Il ne requiert pas de code PIN pour être recu * Il n'a pas une délivraison garantie, et instantanée (que celui qui n'a pas raté un problème parce que son SMS est arrivé avec 15 min (ou plusieurs heures dans les moins bon cas) de retard lève la main =)) * Il est transmissible (renvoi du SMS, épelé sur un appel vocal, etc) En soi, le sms garantit que *quelqu'un* détient le téléphone et non la personne très précise qu'on cherche à authentifier (incarnée par le couple téléphone/Homme). Florian MAURY 2010/6/24 Giles R DeMourot giles.r.demou...@free.fr: Bonjour, Cela fait penser au système d'authentification employé par certaines banques (la mienne) en http comme en ftp pour valider les virements (https) ou télécharger des documents (ftp), avec code pin généré à chaque demande d'accès et envoyé par sms par le serveur de la banque, code qui doit être réentré pour accéder à la section virement de son compte sur le serveur https, ou ftp pour les documents. Le système est aussi utilisé en https pour valider les paiements carte bancaire d'un montant élevé, voire d'un montant pas particulièrement élevé pour certaines banques intermédiaires. GRM -Original Message- From: owner-fr...@frnog.org [mailto:owner-fr...@frnog.org] On Behalf Of Florian MAURY Sent: Thursday, June 24, 2010 12:13 PM To: Liste FRnoG Subject: [FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Comment vous protégez vous ? Bonjour, Pour ce qui est des OTP, il n'y a pas eu de discussion publique : je l'ai contacté directement en privé pour éviter des gestes trop commerciaux directement sur la liste, mais puisque tu le demandes, je vais me faire un plaisir de parler d'un produit développé par mon précédent employeur et qui répond en parti au problème, puisqu'elle a déjà été utilisée pour sécuriser ce genre d'accès ; Il s'agit d'une solution d'authentification forte par téléphonie mobile, qui permet au travers d'un navigateur de générer de manière automatique un appel vocal avec le téléphone du client, puis de jouer un son sur l'ordinateur qui est un OTP sonore, chiffré et unique. Ce son entendu par le téléphone constitue une étape d'authentification, puisque effectuée par un autre média qu'Internet, non reproductible, et non transportable (une retransmission par un second téléphone ou autre dispositif avec compression altérera le message et le rendra inauthentifiable). L'authentification peut être renforcée par la demande pendant l'appel vocal de l'entrée d'un code PIN. Si le client voulant s'authentifier est susceptible de ne pas avoir de matériel sonore (enceintes, casque, etc...), il est possible d'effectuer l'authentification par l'entrée d'un code de transaction : il est à noter cependant que l'on perd dès lors l'OTP. Je précise, quitte à présenter le produit en détail qu'il est accessible en SaaS ou en mode appliance, rackable en datacenter, et que le produit est commandable à partir de n'importe quel langage disposant d'une librairie d'appel SOAP. Je précise également que cette solution est compatible avec tous les téléphones, tous les opérateurs, dans tous les pays. Je suis là demain, pour en parler, si vous le souhaitez. Je vous laisse l'URL du site, afin de pouvoir tester la solution et pouvoir discuter du produit en connaissance de cause demain. http://www.certificall.net Ce type de solution s'intercale donc très bien dans l'étape d'authentification pour accès à l'espace privé du client. Il est dès lors possible de savoir que le client est bien celui qu'il prétend être, et ouvrir son IP sur le firewall pour une session de courte/moyenne durée. Le client peut donc partir en vacances à l'autre bout du monde et toujours pouvoir se connecter d'urgence (ne me remerciez pas de vous gacher vos vacances ;) ) A demain, Florian MAURY 2010/6/24 Mehdi Badreddine mehdi.badredd...@gmail.com: à ce propos, quid des OTP ? des retours d'expériences ? Mehdi Le 24 juin 2010 10:35, Jérémie Pogeant jeremie.poge...@gmail.com a écrit : [snip] Citez moi un serveur SFTP qui est capable de : - faire des soft quota - trouver ses uid/gid/login/pass/clef publique depuis une db ou un annuaire ldap - qui soit évidement opensource et portable ailleurs que sur du linux... [/snip] proFTPd avec mod_sftp et mod_sql (pour la base des users). Il est compatible avec la gestion des quotas. Par contre je ne sais pas pour le stockage de la clé publique dans la db. -- Jérémie Pogeant --- Liste de diffusion du FRnOG http
Re: [FRnOG] Filtre antispam
2010/5/25 Jérôme Nicolle jer...@ceriz.fr: Ca, c'était valable quand le SPAM ne marchait que sur de la collecte active. Maintenant que 80% des adresses existantes chez les gros est dans des listings et que les 20% restants sont touchés en brute-force, la responsabilisation du titulaire de la boite serait stupide. Je suis étonné de lire que 20% des adresses victimes de spam seraient trouvées par brute force. La pratique d'Hotmail (notamment) de faire des statistique par IP émettrices sur le nombre de tentatives de RCPT TO valides/invalides serait si peu répandue parmi les professionnels de l'email ? Est ce inefficace du fait de la multiplicité des sources d'envoi avec les botnets ? Florian MAURY --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Cloud computing
2010/5/18 Clément Game cg...@xooloo.net: Faut quand meme arreter de se foutre de la gueule du monde. Faire une révolution technologique à partir pauvre fonction javascript et d'une methode de serialisation d'objets...parfois on se demande à avec quoi ils coupent leur coke ces gentils monsieurs du marketing... Bonjour, Tout dépend de ce qu'on appelle cloud. Amazon EC² (Elastic *cloud computing*), ce n'est pas exactement la même chose que ce que propose Google Apps, Chrome OS, Zoho ou des webos tels que EyeOS ou Jolicloud... Le cloud, c'est aussi des webservices, potentiellement orientés administration : requêtes (XMLRPC/SOAP/REST/whatever) pour changer une route BGP, reconfigurer le mot de passe du serveur FTP, modifier des enregistrements DNS, envoyer des requêtes IPMI... Bref, tout ce qui constitue de prêt ou de loin du SAAS et IAAS. Je vais peut être m'aventurer un peu, mais pour moi, le cloud, c'est une offre de services et/ou de moyens techniques (parfois, souvent complexes) masqués derrière des appels de fonctions simples à distance (SOAP, XMLRPC, ReST), parfois, mais pas toujours recouvert d'une interface d'administration (web ou lourde). En ca, le cloud est donc relativement opaque (on n'a pas besoin de savoir comment ca marche à l'intérieur, on sait que ca le fait), lointain (appels à des services web), léger (programmation simple pour faire des opérations complexes). On peut s'interroger sur la pertinence de ce sujet sur FRnOG, on peut rejeter l'esprit marketeux de ce phénomène, mais on peut difficilement nier l'existence d'une émulation autour de cette manière de concevoir l'industrie informatique moderne (manière qui n'est certes pas nouvelle, mais à la mode... et on aura beau dire que javascript sait faire ce qu'on a redécouvert sous le nom Ajax depuis 15 ans, sans ce phénomène marketing, nous n'aurions probablement pas aujourd'hui une course à l'optimisation des interpréteurs Javascript et des applications aussi jolies et impressionnantes que ce qu'on peut trouver à l'heure actuelle, et une promesse de décroissance pour les plugins Flash/Silverlight/O3D/Java... alors même si Ajax est une connerie de marketeux, moi ca me va très bien, si c'est aussi sain et je souhaite la même chose au cloud...). Cordialement, Florian MAURY --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Troll du vendredi
2010/4/16 Raphael Bouaziz rap...@noemie.org: On Fri, Apr 16, 2010, Sbastien Namche wrote: Bonjour, je m'appelle Sébastien et moi aussi je suis clamalcoolique. Pourtant, c'était annoncé depuis le 5 octobre 2009 que la version 0.94 serait obsolète le 15 avril 2010. Sauf que ce serait bien qu'un jour, les gens arrêtent de pousser à la mise à niveau. Mises à niveau automatiques, mises à niveau en tâche de fond, bientôt le papier toilette sera conçu pour se dissoudre automatiquement au bout d'un certain temps afin d'en forcer la mise à niveau. Pour avoir une production stable, on doit conserver les versions dont on est sûr du fonctionnement. Mais là en plus, la manière de procéder, en rendant non fonctionnelle une ancienne version, est totalement anti-production. Bien qu'ils pratiquent pour les versions bêta, sur une release même Microsoft n'a pas encore osé. Heureusement qu'on n'a pas la même chose sur les routeurs, et que je peux continuer d'utiliser mes versions d'IOS de 2003 que je n'ai jamais vu planter. Bonjour, Je suis d'accord que la upgradïte aigue est dangereuse pour la bonne santé de l'administrateur et de sa production (alias sa fiche de paie), mais ceux qui font encore tourner du BIND 8, parce que ca tourne encore très bien, c'est du suicide. Autant je suis d'accord que la méthode est un peu brutale (ils auraient pu faire une absence de mise à jour et contacter les mainteneurs de paquets des distributions majeures pour qu'une annonce soit lancée pour fin de vie du paquet, plutôt qu'une rupture de compatibilité sèche), autant faire tourner des antiquités, c'est assez discutable niveau sécurité. Cela dit, je donne de leçon à personne, je me serais fait prendre comme bcp de monde ce matin, si c'avait été ce que j'utilisais. Même Debian commence (enfin ? miracle ?) à se rendre compte qu'il y a des applications qu'il faut mettre à jour en terme de version, entre deux générations (repository volatile) Vendredi =) Florian MAURY --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] anti-spam cote botnet
Bonjour, Effectivement, je trouve la solution très élégante, moi aussi. Elle est non intrusive vis à vis du protocole et même de l'architecture vu que l'analyse peut être faite out-of-band, et de toute facon, comme dit dans le premier mail, c'est une solution additive, pas substitutive. On peut donc tout à fait imaginer des providers comme Free scanner les flux pour les clients qui ont débloqué le port 25. Je suis cependant intrigué par la non-analyse du contenu du mail. Est ce pour des raisons d'image publique (confidentialité des données, tout ca, tout ca) ou pour des raisons de performances ou persistances/stockage ? Il est imaginable de faire un analyse par blocks de texte hashés (ce qui permettrait de ne pas se faire avoir par un bête compteur). Le 18 février 2010 11:28, Dominique Rousseau d.rouss...@nnx.com a écrit : Et donc, tu sniffes, sans leur dire (parceque sinon, ils pourraient juste faire sortir explicitement leur trafic smtp par ton antispam) leur trafic. Et une solution antispam sortant ne fait elle pas exactement la même chose, avec le défaut d'être inband ? Florian MAURY --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] reverse DNS chez orange pro
Le 17 février 2010 00:47, Manuel Guesdon ml+fr...@oxymium.net a écrit : On Tue, 16 Feb 2010 22:56:25 +0100 Radu-Adrian Feurdean r...@ftml.net wrote: | Les pratiques en question impactent de nos jours plus les gens qui ont | autre chose a beep que configurer un serveur de mail tout le long de | la journee. A chacun son truc: s'occuper d'un serveur c'est un boulot comme réparer les voitures en est un autre après chacun peut bidouiller sa voiture et le résultat est fonction de la compétence. Bonjour, Sans vouloir la jouer faut tout casser et tout reprendre à zéro (si c'était si facile, on l'aurait déjà fait), je trouve tout de même qu'il y a une sérieuse dérive dans la lutte anti-spam. Chacun part dans une direction différente, en implémentant des best pratices qui lui sont propres, ou communes à une portion seulement de la toile, avec des règles qui sont parfois complètement absurdes. Le protocole est complètement trituré, et c'est ainsi qu'on voit arriver des choses comme le greylisting, ou bien des should interprétés en must (alors qu'il existe parfois de très bonne raison de ne pas faire ce qui est conseillé). On cherche tellement à se prémunir du spam, qu'on en vient à faire de la bidouille que seuls quelques élus connaissent, ou à faire du spécifique par fournisseur de services, pour se soumettre à leur dernière fantaisie. Il existe déjà un certain nombre de méthodes, intelligentes, qui se greffent par dessus le protocole, qui sont rétro-compatibles avec qqn qui ne souhaite pas les implémenter et qui permettent déjà de lutter efficacement : DKIM (et DK) et SPF (et SenderID). Vous connaissez bcp de botnet qui utilisent ces fonctionnalités ? Des méthodes comme tarpit sont également des astuces, qui sont rétro-compatibles et qui vont effectivement dans le sens de la lutte contre le spam. Ce qui distingue à mes yeux tarpit et greylisting, alors que les deux jouent sur des astuces de protocole, c'est que là où tarpit a une action directe qui est de ralentir le spammeur, le greylisting se base uniquement sur la supposition que le serveur SMTP du spammeur est une bouse, ou que ca lui coute trop cher de gérer des messages d'erreur... ce qui constitue pour moi du bricolage. A mon sens, il vaut mieux réfléchir à des méthodes intelligentes, se greffant au protocole, et étant rétro compatibles, plutôt que de se retrouver avec des inepties comme la dernière en date dont je me souviens : avoir un return-path identique au From... (comme si ca permettait vraiment de distinguer un spam d'un courrier légitime ...) Amicalement, Florian MAURY --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] reverse DNS chez orange pro
Le 17 février 2010 11:21, Dominique Rousseau d.rouss...@nnx.com a écrit : Le Wed, Feb 17, 2010 at 11:10:34AM +0100, Florian MAURY [pub-fr...@x-cli.com] a écrit: Il existe déjà un certain nombre de méthodes, intelligentes, qui se greffent par dessus le protocole, qui sont rétro-compatibles avec qqn qui ne souhaite pas les implémenter et qui permettent déjà de lutter efficacement : DKIM (et DK) et SPF (et SenderID). Qui ne luttent pas contre le spam, mais contre l'usurpation d'expéditeur. (et donc, pour une petite part, ça réduit le bruit induit par les bounces) Oui, effectivement, elles luttent contre l'usurpation d'identité (ce qui limite déjà le spam de type spoofing, c'est toujours ça de pris). Mais l'essence de ce que je voulais dire, c'est que si une personne est soucieuse de son identité vis à vis de l'expédition de mail, c'est qu'elle est soucieuse de sa réputation, et confortable avec l'expédition de mails (en gros qu'elle a une architecture suffisante pour justifier son identité). De fait, elle assume l'entière paternité de son mail, ce qu'aucun spammeur ne peut, ni ne désire faire. J'imagine assez difficilement un spammeur faire un SPF record avec les IPs de ses botnets :D On peut donc créditer allègrement les possesseurs de ce type de signatures d'un bon bonus dans les filtres anti-spam (en sachant qu'une société qui fait du spamming en signant avec DKIM risque d'avoir des surprises sur la réputation de ses IPs !), ou à l'inverse coller un sacré malus à ceux qui ne signent pas. Donc, en soi, je les catégorise comme des solutions anti-spam à part entière... Elles offrent deux services simultanément, sont une best pratice reconnue et documentée, et que de toute facon, tout un chacun devrait se doter (m'est avis). Le problème, c'est que peu de personnes les mettent en place. Florian MAURY --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] reverse DNS chez orange pro
Les spammeurs sont très bon a signer leur mails et utiliser SPF Oui, mais s'ils signent ou SPF, alors il devient très facile de les identifier et une fois identifier, hop, direct dans la RBL, non ? Je ne connaissais pas le domain tasting. Effectivement, ca n'aide pas, mais je pense que cela joue à la marge : quand on voit le chiffre d'affaire que peut rapporter une campagne de spam, l'acquisition, même à long terme, d'un nom de domaine ne représente pas un facteur suffisamment dissuadant. Il fait un SFP qui dit accept tout de partout :D Autant dire que le SPF record qui accepte tout devrait être considéré comme pire que l'absence de SPF record, tant il n'y a aucune bonne raison de le configurer ainsi. Et vu que SFP casse le revoie de mail beaucoup de domaines n'auront jamais de SPF - car personne dans la SME comprends ce que c'est et comment ca marche. Le SPF casse le renvoi de mails ? Je ne comprends pas en quoi. Pour ce qui est des SME, si elles ne comprennent pas et ne font pas l'effort, elles prennent un prestataire, et si elles veulent faire elles-même, de toute facon, à l'heure actuelle, elles doivent déjà faire des prouesses pour comprendre la liste des bidouilles qu'il faut faire pour se faire accepter ses mails par untel ou untel (hotmail au hasard). Je pense donc que ca ne change pas le problème. Ca aide spam assassin - c'est ou que je commence la thread sur le cout en CO2 du spam ?? http://motherjones.com/blue-marble/2009/04/spams-co2-emissions Tu veux vraiment eviter autant de spam que possible aux MX car l'analyse du contenu ca coute en ressources (machines, etc.) Bof, si on place le filtrage par réputation avant le filtrage par SPF/DKIM, on économise déjà bcp de traitement. Je sais bien que le SPAM produit indirectement bcp de CO2, mais si ces pratiques coutent nettement moins cher que les pseudo calculs statistiques d'outils comme SPAM Assassin qui vérifient 15000 règles qui ne sont pas spécialement économes (si on était vendredi, je m'interrogerai sur le pourquoi de Perl, vis à vis des performances =)) Je n'ai pas d'action chez Cisco, mais les Ironport faisait du bon boulot à ce niveau, du temps où j'en avais dans les mains. Hum, je me creuse la tete mais quelle raison peut on avoir de ne pas mettre de rDNS ou un helo correct sur un serveur de mail destiné à communiquer avec l'extérieur ? Disons qu'en soit, pouvoir résoudre une vérification reverse-forward est une bonne idée. Ce qui est problematique, c'est quand un fournisseur de service te demande de résoudre reverse-forward + reverse et ehlo = domaine d'expédition, puisque plusieurs A record peuvent pointer sur la même IP alors qu'on n'a qu'un seul PTR. J'ai déjà eu le cas. Je suis un peu d'accord, cela dit les usagers/clients veulent une 'solution' la maintenant, pas dans 10ans :-) Cela dit rien n'empeche de reflechir à la solution pour dans 10ans. Sans vouloir troller, ca me rappelle la discussion sur le Green IT : Si personne ne lance la machine, elle ne démarrera pas. On a l'avantage que SPF, DKIM et les RBL existent depuis déjà des années. J'ai juste souvent le sentiment (je ne pointe personne de précis du doigt en disant ça) que certains aiment bien ces bidouilles et aiment en inventer d'autres parce que ca les rend savant (= business), et que ca permet de palier temporairement au spam. Florian MAURY --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] reverse DNS chez orange pro
Le 17 février 2010 13:59, Julien Reveret shad...@c0a8.org a écrit : Je ne connais pas de botnet qui utilise DKIM ou SPF, par contre il m'arrive de recevoir des nigerian scams venant de webmails qui eux ont des en-têtes SPF et/ou DKIM. Alors utiliser ces informations pour différencier un spam d'un mail légitime, c'est tout sauf une bonne idée. Leur intérêt est d'aider lorsqu'on remonte le problème à l'abuse. Que ce soit une technique contre l'usurpation d'identité, ou une technique anti-spam, du moment que ca marche pour limiter le spam que c'est documenté, et que c'est référencé, personnellement, je prends. Les scams, s'ils sont signés ou SPF, alors c'est qu'il y a un problème chez ce fournisseur de webmail qui permet d'en envoyer en masse ; et s'il ne permet d'envoyer en masse, alors je le dis haut et fort : je préfère un faux-négatif à des dizaines de faux-positifs dûs à des techniques antispam saugrenues (cf. exemples donnés précédement) Ce qui distingue à mes yeux tarpit et greylisting, alors que les deux jouent sur des astuces de protocole, c'est que là où tarpit a une action directe qui est de ralentir le spammeur, le greylisting se base uniquement sur la supposition que le serveur SMTP du spammeur est une bouse, ou que ca lui coute trop cher de gérer des messages d'erreur... ce qui constitue pour moi du bricolage. Le greylisting ne ralentit pas le spammer ? Le tarpit, tout comme le greylisting ont un but unique: taper là où ça fait mal. Le spam est un business, toute personne empêchant le business de se faire coûte de l'argent aux spammers. Il n'y a pas à mes yeux de raison de préférer l'un à l'autre, chacun a ses défauts et ses qualités. Un outil libre comme spamd qui fait les deux, c'est une bonne idée, à chacun de voir si ça lui convient, des résultats (qui commencent à dater) sont disponibles ici : http://www.openbsd.org/papers/bsdcan05-spamd/ Ce qui me gène dans le grey listing, c'est que c'est un procédé non transparent, retardant sévèrement, suivant l'expéditeur, la délivraison des mails, et le tout basé sur une technique qui présume que le spammeur utilise un programme qui ne gère pas le retour d'erreur temporaire et ne rééditera pas le message. Si le grey-listing se généralise, ils seront acculés et mettront en place des mécanismes de réédition : retour à la case départ. Le tarpit a l'avantage de ne retarder que de quelques secondes et ralentit à la marge le traffic légitime. A mon sens, il vaut mieux réfléchir à des méthodes intelligentes, se greffant au protocole, et étant rétro compatibles, plutôt que de se retrouver avec des inepties comme la dernière en date dont je me souviens : avoir un return-path identique au From... (comme si ca permettait vraiment de distinguer un spam d'un courrier légitime ...) Yakataka. FRnOG à pour but d'améliorer la qualité d'Internet. Discutons-en. Et si j'arrive à convaincre ne serait ce qu'un seul admin de messagerie de ne pas demander des règles saugrenues pour qu'on arrive à lui parler, par mes mails d'aujourd'hui, alors j'aurai sérieusement gagné ma journée. --- Radu-Adrian = +1 Florian MAURY --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: Semaine de la signature de la racine DNS
Le 16 février 2010 16:46, frede...@placenet.org a écrit : y'en a qui vont prendre une douche froide, un beau matin de juillet. c'est ca de choisir un logiciel presque libre avec un seul développeur guru didacteur... Me semble bien que Qmail est dans le domaine publique (et donc complètement libre (même plus libre qu'aucune licence ne le permet en fait)) depuis qq années maintenant :) Mais rien n'interdit de patcher Netqmail de toute facon ;) Florian --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Green IT et Internet
Le 11 janvier 2010 13:41, Greg g...@easyflirt.com a écrit : La virtualisation c'est bien quand on a trop de puissance par service, mais pas quand il faut faire tourner 1 service sur N serveurs. Sauf pour les feignasses bourgeoises de l'administration système ... -- Greg Bonjour, Ce n'est pas tellement vrai. La virtualisation ne sert pas qu'à consolider. Bcp de services ne tournent pas à 100% toute la journée, voir à 100% toute l'année. J'ai précédemment travaillé pour un très gros site de e-commerce qui tournait sur un cluster de plusieurs machines ; la plupart du temps, on aurait pu éteindre 20 à 40% des serveurs du cluster, et les rallumer pour les pics. A faire manuellement (scripté...), c'est possible mais du bricolage (en particulier pour gérer un pic de charge inattendu (genre un marketeux qui oublie de prévenir qu'il a prévu une campagne de pub télé le soir même)). Avec des solutions comme DRS/DPM de VMWare, la journée, toutes les machines tournent sur quelques ESX, et au fur et à mesure que la charge revient, le service rallume des machines et place les VM dessus. L'overhead apporté par la virtualisation si 1 ESX = 1 VM n'est pas énorme. Cordialement, Florian MAURY --- Liste de diffusion du FRnOG http://www.frnog.org/
