[FRnOG] RE: RFC 6115: Recommendation for a Routing Architecture

2011-02-24 Par sujet Michel Py 
>> Michel Py a écrit:
>> La seule chose que j'ajouterai: les solutions (comme INLP)
>> fondées sur la séparation entre identificateur et localisateur
>> ne sont pas nouvelles. 

> Stephane Bortzmeyer a écrit:
> Certes. Elles ne prétendent d'ailleurs pas l'être. Ceci dit,
> entre dire « il faut séparer l'identificateur et le localisateur »
> et une norme complète, cohérente, gérant les cas vicieux et
> raisonnablement sécurisée, il y a de la marge.

C'est très vrai, mais ne pas oublier l'effet d'horizon: tu as une idée, tu 
écris un draft pas très complet, tu te prends une volée de bois vert. Pourquoi 
perdre du temps à pondre la norme complète, alors que même les gens qui ont de 
la sympathie pour ton idée te disent que tu perds ton temps?


> Le travail du RRG était justement de passer d'une vieille idée « dos
> de l'enveloppe » à une architecture correctement définie et réaliste

Avec 15 ans de retard. Les drafts de "requirements", "taxonomy", etc etc j'en 
ai plein mes tiroirs, dont certains étaient carrément nuls et d'autres très 
bons et écrits par des gens très compétents. Note que je ne dénigre pas le 
travail, bien au contraire. Mais comme tu le disais toi-même, c'est déjà un 
demi-échec avant même d'avoir un WG; franchement je ne vois rien de 
révolutionnaire par rapport à ce qui n'aurait pas déjà été écrit. Le RRG 
n'ayant ni "rough consensus" ni "working code", je les vois mal barrés. 
J'espère que tu m'accorderas le droit d'avoir une opinion qualifiée en la 
matière, ayant pris ma ration de volées de bois vert. Ecrire une lettre au Père 
Noël, c'est une chose. Qu'il la lise, c'en est une autre. Croire qu'il va venir 
en personne de porter tes cadeaux, j'ai essayé; depuis, j'ai grandi.

Ceci dit, je répète ce que j'ai dit hier:
http://www.bortzmeyer.org/6115.html
Très bon article, ceux qui ne l'ont pas (encore) lu méritent des coups de pied 
au cul.


> (je rappelle que plusieurs des propositions de séparation entre
> identificateur et localisateur contenaient des raccourcis du genre
> « supposons un mécanisme de correspondance entre I et L qui passe à
> l'échelle, soit sûr, bon marché et soit déployé »...)

Un vendredi, ce n'est pas prudent de me tendre le bâton pour te faire battre :P
Dans le genre raccourci de chez raccourci: IPv6: "supposons un mécanisme de 
multihoming qui ne fasse pas gonfler la table de routage, soit sûr, bon marché 
et soit déployable".


>> Toutes ces solutions se sont régulièrement fait tailler
>> en pièces par l'IETF dans le passé.

> Pour de bonnes raisons.

C'est vrai, et plein de mauvaises aussi. Genre, process troll.


>> Je n'ai remarqué depuis 15 ans aucun changement qui
>> permettrait d'espérer qu'une de ces idées voie le jour.

> Là, je ne suis pas d'accord, la science a progressé
> pendant ces 15 ans.

En théorie, la science et la manière dont L'IETF fonctionne, c'est très 
similaire. En pratique, beaucoup moins.

Question sérieuse (vendredi, on fait mieux de préciser):
Qu'est-ce qui a progressé? (dans le domaine du routage)

Mon opinion:
BGP: pas vraiment. Pas depuis BGP4, avant c'est la préhistoire.

Le hardware: oui. Je vois 3 époques:
La préhistoire: tout par soft. Ah, la bonne vieille époque de l'AGS et IGS 
(voix chevrotante).
Hier: disons l'époque CEF / dCEF / 7500. C'est toujours le CPU qui s'occupe de 
BGP et possiblement du premier paquet d'un flux, après ça c'est la linecard qui 
pousse le paquet avec un chip spécialisé.
Aujourd'hui (sur le haut de gamme): le processus BGP lui-même est assisté par 
le hard.

Je ne suis pas sûr qu'on puisse appeler çà du progrès. De l'évolution, 
certainement. Mais c'est une arme à double-tranchant: le CPU qui marche plus 
vite, la mémoire qui ne coûte presque plus rien, et le 10GigE pour pas trop 
cher c'est une évolution mais ça peut être contraire au progrès, dans le sens 
que finalement c'est la loi de Moore qui permet au routeur de gérer plus de 
merde qu'avant, mais que finalement c'est toujours la même merde qu'hier sauf 
qu'on en mange plus en moins de temps.

Peut-être que je me mélange les pinceaux entre progrès et évolution, aussi.

Michel.

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [FRnOG] Une idée rigolote pour prévenir les utilisateurs infectés

2011-02-24 Par sujet Charpentier Johan 
Le vendredi 25 février 2011 00:00:28, Francois Demeyer a écrit :
> [MODE TROLL DU VENDREDI 00:00  ON]
> 
> Que chaque net de l'inter s'occupe un peu de sa sécurité me semble assez
> normal et souhaitable. Qu'on aille coller un bourre-pif (légal) aux
> spécialistes de l'embourbage du dit réseau me semble encore plus normal et
> souhaitable :-)
> 
> N'aurions nous cependant pas oublié une des parties de cette affaire ?
> 
> Il me semble que les véhicules autorisés a rouler sur les départementales,
> nationales et autoroutes de tous poils doivent préalablement être
> homologués, sauf erreur de ma part. On attaque actuellement sévèrement
> l'industrie pharmaceutique pour la mise sur le marché de produits néfastes
> qui usurpent l'autorisation de mise sur le marché. Bien sur il ne
> viendrait a personne l'idée d'accuser le pharmacien de cette vendre des
> produits inadaptés.
> 
> Dans notre univers de bisounours, on tape et retape sur tout ou partie du
> réseau, tandis qu'on laisse libre de tout contrôle le principal fabricant
> (margeur) de e-véhicules accidentogènes (M$$) qui peut continuer a
> produire tout ce qu'il veut, sans volant ni freins, phares ou airbags
> (selon le millésime).

Allez, je saute dedans...

Tu préfères un monde ou l'informatique de confiance homologue ton matériel et 
tes logiciels pour les autoriser à accéder ou non au Réseau ?

Je connais pas mal de véhicules homologués et qui ont bien passé leur contrôle 
technique qui ont causé plus de tords que la mob rafistolée de pépé.

C'est l'interface chaise clavier qui choisit sa voiture et qui la pilote. On 
connaît ce que donnent les débats sur un Permis du Net... Mais il n'empêche 
que l'informatique ça reste un outil et que n'importe quel outil (même 
homologué en mousse) mal manié peut causer du tord.

Je suis juste d'accord de leur retirer temporairement le marteau et de les 
gronder si ils tapent sur leur petit voisin avec...

> 
> Mais bon… ce que j'en dis...
> 
> [MODE TROLL DU VENDREDI 00:00  OFF]
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

-- 
Charpentier Johan


signature.asc
Description: This is a digitally signed message part.

[FRnOG] Re: [FRnOG] Une idée rigolote pour prévenir les utilisateurs infectés

2011-02-24 Par sujet Francois Demeyer 
[MODE TROLL DU VENDREDI 00:00  ON]

Que chaque net de l'inter s'occupe un peu de sa sécurité me semble assez normal 
et souhaitable.
Qu'on aille coller un bourre-pif (légal) aux spécialistes de l'embourbage du 
dit réseau me semble encore plus normal et souhaitable :-)

N'aurions nous cependant pas oublié une des parties de cette affaire ?

Il me semble que les véhicules autorisés a rouler sur les départementales, 
nationales et autoroutes de tous poils doivent préalablement être homologués, 
sauf erreur de ma part. 
On attaque actuellement sévèrement l'industrie pharmaceutique pour la mise sur 
le marché de produits néfastes qui usurpent l'autorisation de mise sur le 
marché. Bien sur il ne viendrait a personne l'idée d'accuser le pharmacien de 
cette vendre des produits inadaptés.

Dans notre univers de bisounours, on tape et retape sur tout ou partie du 
réseau, tandis qu'on laisse libre de tout contrôle le principal fabricant 
(margeur) de e-véhicules accidentogènes (M$$) qui peut continuer a produire 
tout ce qu'il veut, sans volant ni freins, phares ou airbags (selon le 
millésime).

Mais bon… ce que j'en dis... 

[MODE TROLL DU VENDREDI 00:00  OFF]

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Une idée rigolote pour prévenir les utilisateurs infectés

2011-02-24 Par sujet Rémi Bouhl 
Le 24/02/2011 17:58, Stephane Cremel a écrit :


> 
> Pour repondre à Rémi.
> 
> Si justement, dans ce cas la "ne rien faire" est "LA" solution pour le FAI.
> Ce n'est pas le rôle du FAI d'automatiser de tel procédure.
> 
> C'est à la structure qui subit l'attaque de se prémunir de ces attaques.



Je n'aimerais pas vivre dans un monde où c'est aux voisins de prendre
des somnifères parce je fais du bruit toute la nuit, où c'est aux
piétons de porter une armure parce que les voitures roulent sur les
trottoirs.

C'est pourtant le monde que tu souhaites sur Internet: laisser libre
court à la nuisance, à la pollution, au spam, aux attaques, et chacun
doit se démerder pour échapper aux agressions des autres.
Bonjour l'âge des cavernes.

En suivant ta logique, celui qui subit une attaque sur ses serveurs peut
localiser les attaquants, et venir en personne leur mettre un poing dans
la gueule: ils n'avaient qu'à s'en "prémunir" en louant un garde du
corps. C'est ce monde-là dans lequel tu veux vivre?

> Si c'est le FAI, alors on coupe l’accès quelque temps.
> Si c'est quelqu'un d'autre, c'est à lui de prendre les mesures, pas au FAI


C'est une approche purement technique, sans envisager un instant que des
gens (comme Comcast) peuvent réfléchir au problème, sans envisager qu'il
puisse y avoir des lois contre ça. Internet, zone de non droit selon toi?

> 
> Je pense que prendre des mesures pour ÉRADIQUER des zombie est utopique.


Ben non: si on débranche les PC zombies, ils seront éradiquées
d'Internet. De facto.

> Je pense que faire prendre conscience tout les utilisateurs des malwares
> est aussi des utopiques.


Ben non. Si on les débranche, ils prennent conscience du fait que "avoir
un malware" implique "ne plus avoir Internet". Donc, ça devient
intéressant pour eux de ne pas avoir de malware (actuellement, le bilan
est nul).

Ça ressemble finalement beaucoup à ton idée de "chacun pour sa gueule",
avec la différence qu'on peut encadrer le processus. Que le FAI peut
faire tampon, et au lieu d'avoir l'admin du serveur qui va casser la
gueule à madame Michu (ce que tu sembles préférer, vu que tu rejettes
toute idée de régulation), l'admin du serveur va contacter le FAI de
madame Michu, lequel va prendre des mesures intelligentes, progressives
et pédagogiques, en faisant un compromis entre les droits de l'admin et
ceux de madame Michu.

> 
> Les vrai solution sont dans le développement d'antivirus efficace, dans
> la promotion de ceux-ci (et oui pourquoi pas par le biais du "kit de
> connexion")


dpkg -l | grep antivirus
Zut alors, j'en ai pas. C'est grave docteur?

> A la limite [et c'est encore très limite] dans des règles réseaux sur la
> machin box (c'est pas tout a fait à moi, mais au moins c'est chez moi .)


C'est ça ta neutralité du réseau? Tu trouves préférable qu'on mette des
règles pour bloquer les mails de tout le monde, plutôt que de
contraindre la poignée de spammeurs à ne plus spammer?

> 
> Je ne veut pas que l'on me rajoute le moindre javascript dans les pages
> que je consulte, je ne veut pas que l'on me redirige vers d'autre page.


Ce qui ne t'arrivera pas si tu ne fais pas n'importe quoi sur le réseau.
Et si tu fais n'importe quoi sur le réseau, si tu enfreins la loi et
gêne les autres utilisateurs, tu es très mal placé pour dire "je ne veux
pas". Si tu rajoutes des spams dans les mails des autres, qu'on te
rajoute du javascript dans tes pages à toi me paraît tout à fait mesuré
et proportionné.

> Pour moi internet fonctionne correctement ou ne fonctionne pas, mais je
> n'ai pas un semblant d'internet qui à été modifier par mon FAI . (même
> si c'est pour rajouter qu'un peu de javascript)


Et si c'est pour "ajouter des règles réseaux dans la machinbox"?
Soit l'internaute peut changer ces règles, et s'il les fait sauter on
retombe sur le problème initial, soit il ne peut pas et Internet ne
fonctionne pas, et pour tout le monde en plus.

> 
> Mon point de vue vous parais peut être radical, mais chez moi, dans mes
> canalisation, je fait passer tout ce que je veut et si jamais un jour je
> les bouche, c'est à moi de les déboucher, (soit je le fait moi même soi
> j'apelle un plombier), pour ici c'est pareil.


Sauf qu'Internet n'est pas un tout à l'égout, mais une canalisation qui
te lie à d'autres personnes, et il y a des règles communes d'usage de
ces canalisations.

> Ce n'est pas le FAI qui est responsable du pc du client, si c'est un
> zombi ce n'est pas sont problèmes. Sauf en cas d'attaque direct, auquel
> cas, il fera comme si c’était le client d'un autre.


Oui, d'accord. Le FAI n'y touche pas. Laissons la police faire son
travail: perquisition, saisie du matériel, garde à vue: le spam est un
délit, les DOS aussi, les tentatives d'intrusion également. Et tant pis
pour madame Michu si elle a choppé un virus. Tu trouves ça préférable?

Y'a des jours où je me dis que le javascript c'est trop gentil. Quand
j'épure une demi-douzaine de mails conçus pour faire croire qu'ils sont
légitime

Re: [FRnOG] Retour de prod sur du Juniper.

2011-02-24 Par sujet Jérôme Fleury 
2011/2/7 Sébastien FOUTREL :
> Bonjour,
> Je cherche des avis venant de production pour les EX4200 avec le stack
> virtual chassis et sur le MX80.
>
> Si vous avez des retours/avis/experiences sur l'un ou l'autre je suis
> preneur en privé ou pour le bien de tous :)

Salut,

EX4200:

Nous en avons une douzaine en prod.
Stable depuis la version 10.2R3
Comme le dit Olivier, l'absence d'ISSU peut-être très handicapante en prod.

En revanche pas mal de soucis sur ceux en configuration "entreprise",
en particulier sur le 802.1x. Le process crashe avec mon serveur
Radius. Case ouvert depuis la version 9 et toujours pas corrigé en
10.2. JTAC inexistant sur ce problème. Pas encore testé 10.3 et 10.4
Efficace en routage OSPF et IS-IS (avec licence)

Quelques soucis de fiabilité avec les alim 900W POE.

Dans l'ensemble un très bon switch.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [FRnOG] Re: [FRnOG] Une idée rigolote pour prévenir les utilisateurs infectés

2011-02-24 Par sujet Stephane Cremel 
Oui ou l'envoi d'un mail. c'est suffisant (si on suit la logique d'HADOPI,
le FAI est sur de joindre sont client par mail.)
-> pour moi c'est le moins pire techniquement.
Concernant la confiance que l'on fait au FAI pour installer sont antivirus,
dans ce cas quelle confiance j'ai de ce qui fait de mes tram réseau ?

De mon point de vue, ce n'est pas au FAI de régler ce problème.

Pour repondre à Rémi.

Si justement, dans ce cas la "ne rien faire" est "LA" solution pour le FAI.
Ce n'est pas le rôle du FAI d'automatiser de tel procédure.

C'est à la structure qui subit l'attaque de se prémunir de ces attaques.
Si c'est le FAI, alors on coupe l’accès quelque temps.
Si c'est quelqu'un d'autre, c'est à lui de prendre les mesures, pas au FAI

Je pense que prendre des mesures pour ÉRADIQUER des zombie est utopique.
Je pense que faire prendre conscience tout les utilisateurs des malwares est
aussi des utopiques.

Les vrai solution sont dans le développement d'antivirus efficace, dans la
promotion de ceux-ci (et oui pourquoi pas par le biais du "kit de
connexion")
A la limite [et c'est encore très limite] dans des règles réseaux sur la
machin box (c'est pas tout a fait à moi, mais au moins c'est chez moi .)

Je ne veut pas que l'on me rajoute le moindre javascript dans les pages que
je consulte, je ne veut pas que l'on me redirige vers d'autre page.
Pour moi internet fonctionne correctement ou ne fonctionne pas, mais je n'ai
pas un semblant d'internet qui à été modifier par mon FAI . (même si c'est
pour rajouter qu'un peu de javascript)

Mon point de vue vous parais peut être radical, mais chez moi, dans mes
canalisation, je fait passer tout ce que je veut et si jamais un jour je les
bouche, c'est à moi de les déboucher, (soit je le fait moi même soi j'apelle
un plombier), pour ici c'est pareil.
Ce n'est pas le FAI qui est responsable du pc du client, si c'est un zombi
ce n'est pas sont problèmes. Sauf en cas d'attaque direct, auquel cas, il
fera comme si c’était le client d'un autre.

Pour finir :
J’héberge personnellement mon site, j'ai donc mis des règles de protection
contre les zombies.
alors oui pour sinon que c'est un petit site (photo familiale), j'ai 10 IPs
bannie par jour. mais c'est mon travail, pas celui du FAI.
--
Stéphane CREMEL


Le 24 février 2011 17:11, Pierre-Henry Muller  a écrit
:

> Je suis assez d'accord sur le fait que si mon fai fait cela je change
> aussi.
> Malgré tout sans entrer dans du dpi, une analyse comportementale du flux
> serait un bon compromis. L'analyse détecte une anomalie et déclenche un
> incident.
>
> Pour remonter l'incident au client, le plugin du navigateur a
> l'inconvénient que tout le monde
> ne l'installera pas, alors que pratiquement tous les opérateurs
> proposent une machinbox, il suffirait alors qu'un bip retentisse pour
> signaler l'incident voir de l'afficher sur la box.
> Ce message inviterait le client a se rapprocher du support.
>
>
>

Re: [FRnOG] Re: [FRnOG] Une idée rigolote pour prévenir les utilisateurs infectés

2011-02-24 Par sujet Pierre-Henry Muller 
Je suis assez d'accord sur le fait que si mon fai fait cela je change aussi.
Malgré tout sans entrer dans du dpi, une analyse comportementale du flux
serait un bon compromis. L'analyse détecte une anomalie et déclenche un
incident.

Pour remonter l'incident au client, le plugin du navigateur a
l'inconvénient que tout le monde
ne l'installera pas, alors que pratiquement tous les opérateurs
proposent une machinbox, il suffirait alors qu'un bip retentisse pour
signaler l'incident voir de l'afficher sur la box.
Ce message inviterait le client a se rapprocher du support.




signature.asc
Description: OpenPGP digital signature

Re: [FRnOG] Une idée rigolote pour prévenir les utilisateurs infectés

2011-02-24 Par sujet Christophe Lohr 

Le 24/02/2011 16:36, Francois Petillon a écrit :


Le 24/02/2011 15:05, Christophe Lohr a écrit :

L'effet final devrait être le même : le client négligent surf lorsque
soudain apparaît un message de son FAI lui demandant de faire le ménage
sur son PC.


Votre proposition revient à demander aux utilisateurs négligents de ne 
pas l'être. Sans vouloir me montrer critique, je crains que cela ne 
soit légèrement inadéquat.



Sur ce point, je crois que ma proposition n'est ni meilleure ni pire que 
celle proposée par le RFC en question.


Ma proposition portait sur la manière de communiquer entre le FAI et son 
client, mais le résultat est le même : un popup qui s'incruste sur des 
pages web consultées. La différence est que techniquement, dans ma 
proposition c'est le client qui l'a cherché, pas le FAI qui vient 
polluer la com de son propre chef.


Mais c'est une vrai question : comment remonter une alerte au client ?
(une fois que l'on a statué sur la légitimité du FAI à chercher des 
anomalies dans le comportement de son client...)
Lorsque le client détecte une anomalie dans le comportement de son FAI, 
il peut téléphoner au service support ou râler sur les forums 
utilisateurs. Mais dans l'autre sens ?



Mais je suis bien d'accord avec vous :  tout ceci revient bien à 
demander à des utilisateurs négligent de ne pas l'être.


Sur la route, l'état a imposé un contrôle technique pour que les gens 
arrêtent de circuler avec des poubelles (et accessoirement de booster 
les ventes des constructeurs).
Sur les "autoroutes de l'information", est-ce qu'il faut imposer un 
contrôle technique ? Et un contrôle technique du PC ou de l'utilisateur 
(i.e. passer le code de la route, passer le B2I ou le C2I, les 
brevets/certificat informatique internet) ?
Ce RFC ne répond pas à cette question (de ce que j'en comprends), mais 
part du constat que les FAI aimeraient bien le faire...


Cordialement
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Une idée rigolote pour prévenir les utilisateurs infectés

2011-02-24 Par sujet Radu-Adrian Feurdean 

On Thu, 24 Feb 2011 15:05 +0100, "Christophe Lohr"
 wrote:

> *  Le FAI, dans son "kit de connexion", fournit une 
> applet/plugin/addon/whatever que le client installe dans son butineur préféré

"kit de connexion" = le fameux CD qu'on mer direct a la poubelle ?
Tant qu'on y est, le FAI peut fournir son propre antivirus ... on en
fonction de la confiance qu'on lui donne on peut appeler ca du malware.

-- 
Radu-Adrian Feurdean
 raf (a) ftml ! net

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: Une idée rigolote pour prévenir les utilisateurs infectés

2011-02-24 Par sujet Radu-Adrian Feurdean 

On Thu, 24 Feb 2011 14:16 +0100, "Stephane Bortzmeyer"
 wrote:

> > tout utilisateur abusant de ses privilèges d'accès au réseau pour
> > nuire au réseau ou à d'autres usagers peut voir ces privilèges
> > révoqués.
> 
> Justement, la décision du Conseil Constitutionnel concernant HADOPI
> était que l'accès à l'Internet n'était pas un privilège mais un droit,
> qui ne pouvait donc être révoqué que par décision judiciaire.

De memoire, le contexte HADOPI n'est pas le meme. Dans le cas HADOPI
c'est une partie qui n'est pas conractante qui initie la coupure de
l'access, alors que dans les cas des FAI c'est une des parties
contractantes qui initie la coupure, pour un raison deja contractualise
auparavant.

-- 
Radu-Adrian Feurdean
 raf (a) ftml ! net

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Une idée rigolote pour prévenir les utilisateurs infectés

2011-02-24 Par sujet Rémi Bouhl 
Le 24/02/2011 16:36, Francois Petillon a écrit :

> Le 24/02/2011 15:05, Christophe Lohr a écrit :
>> L'effet final devrait être le même : le client négligent surf lorsque
>> soudain apparaît un message de son FAI lui demandant de faire le ménage
>> sur son PC.
> 
> Votre proposition revient à demander aux utilisateurs négligents de ne
> pas l'être. Sans vouloir me montrer critique, je crains que cela ne soit
> légèrement inadéquat.
> 

Sauf à prévoir une... "riposte graduée", sur le thème "conformément aux
disposition du contrat de service, nous nous réservons le droit de
suspendre votre accès au réseau si vous ne faites pas cesser, dans un
délai de X jours, l'abus qui vous est reproché."

Ce qui me chiffonne davantage, c'est qu'on n'arrête pas la menace avec
ce système. Autrement dit, l'utilisateur émet du spam ou des attaques,
et on laisse faire tout en le prévenant. Rien que pour ça la solution de
la sandbox paraît préférable.

Rémi.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Une idée rigolote pour prévenir les utilisateurs infectés

2011-02-24 Par sujet Francois Petillon 

Le 24/02/2011 15:05, Christophe Lohr a écrit :

L'effet final devrait être le même : le client négligent surf lorsque
soudain apparaît un message de son FAI lui demandant de faire le ménage
sur son PC.


Votre proposition revient à demander aux utilisateurs négligents de ne 
pas l'être. Sans vouloir me montrer critique, je crains que cela ne soit 
légèrement inadéquat.


François
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [FRnOG] Une idée rigolote pour prévenir les utilisateurs infectés

2011-02-24 Par sujet Rémi Bouhl 
Bonjour,

Le 24/02/2011 15:53, Stephane Cremel a écrit :

> Personnellement ayant regarder beaucoup de conférence de Benjamin Bayart
> et étant souvent en accord avec ces propos, je me demanderai juste si ce
> n'est pas une forme d'intelligence dans le réseaux ?
> 
> Je ne suis pas d'accord pour que mon FAI flique les actions de mon
> ordinateur (que ce soit moi ou un malware.)
> Les antivirus sont la pour ça, facile d'installation, quelques un
> gratuit, j’attends de mon FAI, qu'il me donne la connexion que j'ai
> demander et non pas une analyse antivirus.
> 
> A la limite, juste un antivirus inclus dans le "kit de connexion".
> Si j’apprends que mon FAI fait ce genre de chose, moi je change !


Vous proposez quoi, alors, comme solution qui marche?

"Ne rien faire" n'en est pas une.

Rémi.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [FRnOG] Une idée rigolote pour prévenir les utilisateurs infectés

2011-02-24 Par sujet Stephane Cremel 
Personnellement ayant regarder beaucoup de conférence de Benjamin Bayart et
étant souvent en accord avec ces propos, je me demanderai juste si ce n'est
pas une forme d'intelligence dans le réseaux ?

Je ne suis pas d'accord pour que mon FAI flique les actions de mon
ordinateur (que ce soit moi ou un malware.)
Les antivirus sont la pour ça, facile d'installation, quelques un gratuit,
j’attends de mon FAI, qu'il me donne la connexion que j'ai demander et non
pas une analyse antivirus.

A la limite, juste un antivirus inclus dans le "kit de connexion".
Si j’apprends que mon FAI fait ce genre de chose, moi je change !
--
Stéphane CREMEL


Le 24 février 2011 15:05, Christophe Lohr  a
écrit :

> Personnellement j'aurais bien imaginé un mécanisme un peu différent.
>
> Le voici :
> *  Le FAI, dans son "kit de connexion", fournit une
> applet/plugin/addon/whatever que le client installe dans son butineur
> préféré
> (Je n'épilogue pas sur l'intérêt de le proposer en open-source bien
> documenté pour que chacun puisse l'adapter aux spécificités de son système
> préféré).
>
> *  Le dit plugin garde une websocket (ça c'est pour faire fun 2.0) ouverte
> vers le serveur d'alertes de son FAI
> (les fun 0.1 peuvent faire des trap snmp)
>
> *  Lorsque le FAI a quelque chose à reprocher à son client, un message
> d'alerte est poussée via la websocket vers le plugin du navigateur qui
> l'affiche en surimpression des pages web consultées.
>
>
> Bien évidemment la websocket est chiffrée en ssl avec le certificat du FAI,
> qui a été installé sur le PC du client en même temps que le plugin. Cela
> évite les injection de messages indésirable par des tiers.
>
> L'effet final devrait être le même :  le client négligent surf lorsque
> soudain apparaît un message de son FAI lui demandant de faire le ménage sur
> son PC.
>
> La différence est que cela se fait à l'initiative du client... enfin sur un
> plan purement technique : c'est lui (ou son plugin) qui va consulter le
> serveur d'alertes, et non pas sa connexion qui est détournée/polluée sur
> simple décision du FAI.
> C'est donc désactivable à tout moment, et librement, à volonté par le
> client (mais à ses risques et périls :  il risque de se faire couper la
> ligne s'il fait la sourde oreille)
>
> Pour cette raison cela me semble "moins pire" que le RFC en question.
> Je dis "moins pire"  car on peut se demander si cela ne risque pas de
> dé-responsabiliser l'internaute de ses obligations d'hygiène de son PC...
> Tant que le FAI ne râle pas, il peut laisser les mycoses s'installer sur son
> PC...
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>

Re: [FRnOG] Une idée rigolote pour prévenir les utilisateurs infectés

2011-02-24 Par sujet Christophe Lohr 

Personnellement j'aurais bien imaginé un mécanisme un peu différent.

Le voici :
*  Le FAI, dans son "kit de connexion", fournit une 
applet/plugin/addon/whatever que le client installe dans son butineur 
préféré
(Je n'épilogue pas sur l'intérêt de le proposer en open-source bien 
documenté pour que chacun puisse l'adapter aux spécificités de son 
système préféré).


*  Le dit plugin garde une websocket (ça c'est pour faire fun 2.0) 
ouverte vers le serveur d'alertes de son FAI

(les fun 0.1 peuvent faire des trap snmp)

*  Lorsque le FAI a quelque chose à reprocher à son client, un message 
d'alerte est poussée via la websocket vers le plugin du navigateur qui 
l'affiche en surimpression des pages web consultées.



Bien évidemment la websocket est chiffrée en ssl avec le certificat du 
FAI, qui a été installé sur le PC du client en même temps que le plugin. 
Cela évite les injection de messages indésirable par des tiers.


L'effet final devrait être le même :  le client négligent surf lorsque 
soudain apparaît un message de son FAI lui demandant de faire le ménage 
sur son PC.


La différence est que cela se fait à l'initiative du client... enfin sur 
un plan purement technique : c'est lui (ou son plugin) qui va consulter 
le serveur d'alertes, et non pas sa connexion qui est détournée/polluée 
sur simple décision du FAI.
C'est donc désactivable à tout moment, et librement, à volonté par le 
client (mais à ses risques et périls :  il risque de se faire couper la 
ligne s'il fait la sourde oreille)


Pour cette raison cela me semble "moins pire" que le RFC en question.
Je dis "moins pire"  car on peut se demander si cela ne risque pas de 
dé-responsabiliser l'internaute de ses obligations d'hygiène de son 
PC... Tant que le FAI ne râle pas, il peut laisser les mycoses 
s'installer sur son PC...


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [FRnOG] Re: Une idée rigolote pour prévenir les utilisateurs infectés

2011-02-24 Par sujet Alexandre Archambault 
Le 24 févr. 2011 à 14:16, Stephane Bortzmeyer a écrit :

> Justement, la décision du Conseil Constitutionnel concernant HADOPI
> était que l'accès à l'Internet n'était pas un privilège mais un droit,
> qui ne pouvait donc être révoqué que par décision judiciaire.

Un droit d'accord, mais dont le titulaire peut être amené à y répondre en cas 
d'abus.

Pour une illustration récente, TGI Paris, 15 septembre 2009 :

---
Attendu qu’une telle clause n’est pas abusive, dés lors qu’il appartient au 
fournisseur d'accès de veiller à l’intérêt de la collectivité des abonnés et 
qu’il doit pouvoir faire cesser les agissements susceptibles d’entraver pour 
tous la qualité du service offert ; que les comportements cités sont 
suffisamment précis et graves pour justifier une telle intervention ; qu’il n’y 
a pas lieu de prévoir un préavis, l’urgence liée au trouble apporté à 
l’ensemble des abonnés commandant de ne pas différer l’intervention du 
fournisseur d’accès ; que la clause litigieuse n’est dès lors pas abusive ;
---

Je vais faire mon Philippe, mais de grâce, il vaudrait mieux en rester au 
niveau technique sur FrNOG.

--
Alec,



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: Une idée rigolote pour prévenir les utilisateurs infectés

2011-02-24 Par sujet Rémi Bouhl 
Le 24/02/2011 14:16, Stephane Bortzmeyer a écrit :

> On Thu, Feb 24, 2011 at 02:10:38PM +0100,
>  Jérôme Nicolle  wrote 
>  a message of 37 lines which said:
> 
>> tout utilisateur abusant de ses privilèges d'accès au réseau pour
>> nuire au réseau ou à d'autres usagers peut voir ces privilèges
>> révoqués.
> 
> Justement, la décision du Conseil Constitutionnel concernant HADOPI
> était que l'accès à l'Internet n'était pas un privilège mais un droit,
> qui ne pouvait donc être révoqué que par décision judiciaire.


Pourtant, il est coupé si on cesse de payer. On aurait donc la
hiérarchie suivante:

30€/mois ont plus de valeur que le droit d'avoir un accès à Internet, et
que le droit d'avoir un accès à Internet est supérieur au droit de ne
pas se faire emmerder par un botnet.

Plutôt curieux comme priorités, on en déduit par transitivité que
nettoyer la merde sur Internet a moins de valeur que 30€/mois. Pas
étonnant qu'il y ait autant de botnets :D

Rémi.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: Une idée rigolote pour prévenir les utilisateurs infectés

2011-02-24 Par sujet Stephane Bortzmeyer 
On Thu, Feb 24, 2011 at 02:10:38PM +0100,
 Jérôme Nicolle  wrote 
 a message of 37 lines which said:

> tout utilisateur abusant de ses privilèges d'accès au réseau pour
> nuire au réseau ou à d'autres usagers peut voir ces privilèges
> révoqués.

Justement, la décision du Conseil Constitutionnel concernant HADOPI
était que l'accès à l'Internet n'était pas un privilège mais un droit,
qui ne pouvait donc être révoqué que par décision judiciaire.

> Du coup, le principe de sandboxing

Qui n'est justement pas celui retenu par le RFC 6108 (cf. section 12,
qui discute cette alternative).
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: Une idée rigolote pour prévenir les utilisateurs infectés

2011-02-24 Par sujet Raphaël Jacquot 
On Thu, 2011-02-24 at 14:07 +0100, Stephane Bortzmeyer wrote:
> On Thu, Feb 24, 2011 at 02:00:27PM +0100,
>  Alexandre Dulaunoy  wrote 
>  a message of 40 lines which said:
> 
> > La différence est simplement la finalité et non la technologie utilisée.
> 
> Tout à fait. Les techniques décrites dans le RFC 6108 peuvent très
> facilement être utilisées pour le Bien ou pour le Mal.

En tout état de cause, couper l'acces est un poil bourrin.
apres, l'autre question c'est, "quel est le seuil d'alerte"...


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Une idée rigolote pour prévenir les utilisateurs infectés

2011-02-24 Par sujet Jérôme Nicolle 
Bonjour Stéphane,

Comme indiqué par Rémi, tous les FAI ou presque se réservent un droit de
coupure, ce qui est plus ou moins légitime en regard de la nétiquette :
tout utilisateur abusant de ses privilèges d'accès au réseau pour nuire
au réseau ou à d'autres usagers peut voir ces privilèges révoqués.

Comme la nuisance est involontaire, une mesure coercitive visant à
tendre vers la minimisation voir la résolution du problème est plus
souhaitable qu'une déconnexion.

Du coup, le principe de sandboxing suite à nuisance et pour résolution,
à condition qu'elle puisse être contournée par l'utilisateur s'il est
conscient du problème (ajout d'un bouton "quitter la sandbox à vos
risques et périls", réinitialisé toutes les heures), ne me choque pas
plus que ça.

Sur un projet de FAI sub-local, on envisage un système similaire associé
à un netboot avec une distrib linux pré-configurée et des outils de
désinfection.

Donc globalement : 
- tant qu'on se rappelle que le principe de neutralité vise à la
préservation et au développement du réseau et de ses usages, 
- tant que ça reste interne aux réseaux des FAI
- tant que c'est fait en toute transparence, désactivable par
l'utilisateur et assorti d'information à destination des utilisateurs,
- tant que ce n'est ni obligatoire (pour le fai ou l'usager) ni
règlementé ou standardisé, mais juste permis,

IMHO, ça n'est pas incompatible avec le principe de neutralité des
réseaux, contrairement aux conneries comme le blocage systématique d'un
port précis, qu'il fût désactivable ou pas.

-- 
Jérôme Nicolle
06 19 31 27 14

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: Une idée rigolote pour prévenir les utilisateurs infectés

2011-02-24 Par sujet Stephane Bortzmeyer 
On Thu, Feb 24, 2011 at 02:00:27PM +0100,
 Alexandre Dulaunoy  wrote 
 a message of 40 lines which said:

> La différence est simplement la finalité et non la technologie utilisée.

Tout à fait. Les techniques décrites dans le RFC 6108 peuvent très
facilement être utilisées pour le Bien ou pour le Mal.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: Une idée rigolote pour prévenir les utilisateurs infectés

2011-02-24 Par sujet Stephane Bortzmeyer 
On Thu, Feb 24, 2011 at 12:42:57PM +0100,
 Rémi Bouhl  wrote 
 a message of 52 lines which said:

> Les clauses, chez tous les FAI, qui disent "Si vous faites des
> bêtises on coupe", sont donc illégales et réputées non écrites?

Je pense, oui (IANAL). C'est une grosse différence entre les
zétatzunis (où le contrat a toujours raison, cf. Amazon coupant
Wikileaks) et la France (où la loi protège les contractants).

> Étant donné qu'un zombie sur le réseau d'un FAI peut amener au
> blacklistage d'une partie ou de la totalité des clients, y compris
> "propres", de ce FAI, ne peut-il pas arguer qu'il s'agit d'une
> mesure préventive à caractère urgent, nécessaire pour préserver ses
> autres clients?

On peut certainement argumenter mais je ne sais pas ce que dira un
tribunal.

> En France, en tout cas, il arrive que des FAI décident de couper un
> client en cas d'abus interdit par le contrat: revente de la
> connexion à un nombre importants d'utilisateurs, par exemple..

Des tas de choses illégales arrivent tous les jours. Tant qu'un client
ne fait pas de procès, ça passe. Combien de clients d'Orange se sont
fait avoir et ont fermé leur gueule, avant
 ?

> Ça suppose que les utilisateurs de Noscript ne sont jamais infectés.

Je ne peux pas parler pour Comcast, mais je suppose qu'ils sont
parfaitement conscients qu'aucune solution ne marche à 100 %. En tout
cas, je préfère cette solution à la modification de la page HTML.

D'ailleurs, les gens qui installent Noscript sont probablement plus
avertis que la moyenne et moins susceptibles de se faire oWnÉs.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [FRnOG] [FRnOG] Une idée rigolote pour prévenir les utilisateurs infectés

2011-02-24 Par sujet Alexandre Dulaunoy 
2011/2/24 Thomas Mangin :

> Non, c'est très diffèrent techniquement ... expliquer la différence prendrait 
> bien trop de temps.

En fait, la solution technique est plus ou moins la même (j'ai vu en production
deux variantes) mais la plus grande différence entre la RFC 6108 et Phorm
(ou une autre solution d'insertion de contenu en HTTP) est simplement ceci:

"""
   R3.1.12.  Advertising Replacement or Insertion Must Not Be Performed
 Under ANY Circumstances
 Additional Background: The system must not be used to
 replace any advertising provided by a website, or to insert
 advertising into websites.  This therefore includes cases
 where a web page already has space for advertising, as well
 as cases where a web page does not have any advertising.
 This is a critical area of concern for end users, privacy
 advocates, and other members of the Internet community.
 Therefore, it must be made abundantly clear that this
 system will not be used for such purposes.
"""

La différence est simplement la finalité et non la technologie utilisée.

Bonne journée,

adulau

-- 
--                   Alexandre Dulaunoy (adulau) -- http://www.foo.be/
--                             http://www.foo.be/cgi-bin/wiki.pl/Diary
--         "Knowledge can create problems, it is not through ignorance
--                                that we can solve them" Isaac Asimov
---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [FRnOG] Une idée rigolote pour prévenir les utilisateurs infectés

2011-02-24 Par sujet Thomas Mangin 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> La tentation pourrait être grande de faire passer tout le 80 par un proxy 
> transparent.

Ce n'est pas vraiment possible car beaucoup d'applications utilise le port 80 
car il est toujours ouvert sans vraiment etre de l'HTTP.

Thomas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (Darwin)

iEYEARECAAYFAk1mU8MACgkQA/52wvuLgaHSawCgjDG8Uu0bzyoHlx8v7Yh6dEhI
yvwAn2e3FFCEeqOU3NdI86UMxdA6nW3p
=W1+b
-END PGP SIGNATURE-
---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [FRnOG] Une idée rigolote pour prévenir les utilisateurs infectés

2011-02-24 Par sujet Thomas Mangin 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

>> RFC 6108 : Comcast's Web Notification System Design
> 
> Quelles sont les différences entre le design de Phorm:

Non, c'est très diffèrent techniquement ... expliquer la différence prendrait 
bien trop de temps.

Pour comprendre phorm, commencer ici :
http://www.lightbluetouchpaper.org/2008/04/04/the-phorm-webwise-system/

Ma solution utilise une redirection du traffic web sur les routeurs pour le 
forcer a travers un routeur sous Linux, qui pour certaines sources via 
netfilter (ie: clients) DNAT le traffic web vers une ferme de serveurs squid 
utilisant l'option "redirect program" pour parler a un système propriétaire qui 
répond et redirige certaines requêtes sur un serveur web tournant sur le 
loopback.
http://www.visolve.com/squid/squid24s1/externals.php#redirect_program

Donc trois solutions assez différentes, mais cela fait quelque temps que je 
pense a adapter notre solution pour utiliser ICAP :)

> J'ai le mauvais sentiment que c'est fort proche...

C'est proche dans le sens ou cela touche au traffic web des utilisateurs - sans 
plus.

Thomas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (Darwin)

iEYEARECAAYFAk1mUzsACgkQA/52wvuLgaHXhgCgxI0IjGrYAlxopCytN92k17Gj
JykAnj8it+8J7ytR423luT2wbFano5+r
=m8hV
-END PGP SIGNATURE-
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Une idée rigolote pour prévenir les utilisateurs infectés

2011-02-24 Par sujet guillaume . monnette 
Je pense que c'est une bonne chose... que dans le cas décrit dans l'article.

Je cite  :
" équipement de load-balancing est utilisé pour séparer le trafic HTTP du reste 
(même s'il tourne sur le port 80) et pour n'aiguiller vers le relais Squid que 
les clients listés comme suspects. L"


La tentation pourrait être grande de faire passer tout le 80 par un proxy 
transparent.

De même, il faut faire attention, car ce genre de méthode trompe les gens, qui 
finissent par penser que c'est le fournisseur d'accès Internet qui héberge tout 
le web, un peu comme au temps du minitel. S'ils peuvent modifier les pages, 
alors ils peuvent faire disparaitre les liens torrent (industrie musicale), ils 
peuvent alterer le contenu de wikileaks (gouvernement) etc... Il faut 
absolument conserver le caractère p2p du net, même pour le WEB.

Dans le fond, je serais plus pour un portail captif, dont la page apparait tous 
les "n" clics, gênant l'utilisateur mais ne modifiant pas les pages.

Quand je vois autour de moi le nombre d'ordinateurs qui sont des zoos à virus 
et bots et dont les gens s'en contrefoutent, je me dis qu'il faut agir sans 
tarder. Il faut responsabiliser un minimum les gens concernant la sécurité de 
leurs machines.


- Mail Original -
De: "Rémi Bouhl" 
À: frnog@FRnOG.org
Envoyé: Jeudi 24 Février 2011 12h42:57 GMT +01:00 Amsterdam / Berlin / Berne / 
Rome / Stockholm / Vienne
Objet: Re: [FRnOG] Une idée rigolote pour prévenir les utilisateurs infectés

Bonjour,

Le 24/02/2011 09:43, Stephane Bortzmeyer a écrit :

> 
> Il existe bien sûr d'autres méthodes, comme de couper purement et 
> simplement la connexion Internet dudit client. Cette méthode est 
> régulièrement réclamée par certains éradicateurs. Outre qu'elle n'est 
> pas dans l'intérêt financier du FAI (le client arrêterait de payer s'il 
> était coupé), elle n'est pas envisageable dans un État de droit (en 
> France, le Conseil Constitutionnel avait cassé une version de la loi 
> Hadopi car elle prévoyait une coupure de l'accès Internet sans 
> jugement). 


Ah bon? Les clauses, chez tous les FAI, qui disent "Si vous faites des
bêtises on coupe", sont donc illégales et réputées non écrites?

Étant donné qu'un zombie sur le réseau d'un FAI peut amener au
blacklistage d'une partie ou de la totalité des clients, y compris
"propres", de ce FAI, ne peut-il pas arguer qu'il s'agit d'une mesure
préventive à caractère urgent, nécessaire pour préserver ses autres clients?

En France, en tout cas, il arrive que des FAI décident de couper un
client en cas d'abus interdit par le contrat: revente de la connexion à
un nombre importants d'utilisateurs, par exemple..
C'est vrai que mis en rapport avec la décision du CC, c'est très
questionnable comme riposte.

> 
> L'approche de Comcast est donc de profiter du fait que la plupart des 
> utilisateurs passent beaucoup de temps à regarder des pages Web. Il 
> « suffit » de détourner les pages HTML, d'y insérer le message et 
> bingo ! Le message apparaîtra à l'écran. Voici une copie d'écran de 
> http://www.example.com/, avec l'exemple de modification que donne le 
> RFC en section 8. Cette modification consiste simplement en l'ajout 
> d'un peu de JavaScript


Ça suppose que les utilisateurs de Noscript ne sont jamais infectés.

Et qu'ils ne font pas passer toutes leurs connexions par un VPN à la
mode, comme ça commence à se faire en France, pour échapper à la
surveillance des ayants-droits..

Même si, dans le cas d'un VPN, ce qui infecte le PC passera aussi par le
VPN et ne concerne donc pas le FAI.

Rémi.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Une idée rigolote pour prévenir les utilisateurs infectés

2011-02-24 Par sujet Rémi Bouhl 
Bonjour,

Le 24/02/2011 09:43, Stephane Bortzmeyer a écrit :

> 
> Il existe bien sûr d'autres méthodes, comme de couper purement et 
> simplement la connexion Internet dudit client. Cette méthode est 
> régulièrement réclamée par certains éradicateurs. Outre qu'elle n'est 
> pas dans l'intérêt financier du FAI (le client arrêterait de payer s'il 
> était coupé), elle n'est pas envisageable dans un État de droit (en 
> France, le Conseil Constitutionnel avait cassé une version de la loi 
> Hadopi car elle prévoyait une coupure de l'accès Internet sans 
> jugement). 


Ah bon? Les clauses, chez tous les FAI, qui disent "Si vous faites des
bêtises on coupe", sont donc illégales et réputées non écrites?

Étant donné qu'un zombie sur le réseau d'un FAI peut amener au
blacklistage d'une partie ou de la totalité des clients, y compris
"propres", de ce FAI, ne peut-il pas arguer qu'il s'agit d'une mesure
préventive à caractère urgent, nécessaire pour préserver ses autres clients?

En France, en tout cas, il arrive que des FAI décident de couper un
client en cas d'abus interdit par le contrat: revente de la connexion à
un nombre importants d'utilisateurs, par exemple..
C'est vrai que mis en rapport avec la décision du CC, c'est très
questionnable comme riposte.

> 
> L'approche de Comcast est donc de profiter du fait que la plupart des 
> utilisateurs passent beaucoup de temps à regarder des pages Web. Il 
> « suffit » de détourner les pages HTML, d'y insérer le message et 
> bingo ! Le message apparaîtra à l'écran. Voici une copie d'écran de 
> http://www.example.com/, avec l'exemple de modification que donne le 
> RFC en section 8. Cette modification consiste simplement en l'ajout 
> d'un peu de JavaScript


Ça suppose que les utilisateurs de Noscript ne sont jamais infectés.

Et qu'ils ne font pas passer toutes leurs connexions par un VPN à la
mode, comme ça commence à se faire en France, pour échapper à la
surveillance des ayants-droits..

Même si, dans le cas d'un VPN, ce qui infecte le PC passera aussi par le
VPN et ne concerne donc pas le FAI.

Rémi.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [FRnOG] Une idée rigolote pour prévenir les utilisateurs infectés

2011-02-24 Par sujet Alexandre Dulaunoy 
2011/2/24 Stephane Bortzmeyer :
> Quelqu'un a-t-il déployé un système de ce genre ? (Attention aux
> conséquences juridiques, qui ne sont pas les mêmes de ce côté de
> l'Atlantique.)
>
> RFC 6108 : Comcast's Web Notification System Design

Quelles sont les différences entre le design de Phorm:

http://www.cl.cam.ac.uk/~rnc1/080518-phorm.pdf

et le RFC 6108?

J'ai le mauvais sentiment que c'est fort proche...

adulau

-- 
--                   Alexandre Dulaunoy (adulau) -- http://www.foo.be/
--                             http://www.foo.be/cgi-bin/wiki.pl/Diary
--         "Knowledge can create problems, it is not through ignorance
--                                that we can solve them" Isaac Asimov
---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [FRnOG] Une idée rigolote pour prévenir les utilisateurs infectés

2011-02-24 Par sujet Thomas Mangin 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Reponse courte :
 - oui pour informer les clients que leur compte va etre fermer pour 
non-payment redirection DNAT vers un proxy web ...
 - oui pour intercepter les spammer et les rediriger les connexions pour le 
port 25 vers un proxy mail qui retourne une erreur 4xx pour chaque connexion
 - oui pour notre filtrage d'image pornographique enfantine national (UK)

Reponse plus longue quand j'aurai lu toute la RFC et l'aurai compare a ce que 
l'on fait.

Thomas

Je lirai le document pour une reponse p
On 24 Feb 2011, at 08:43, Stephane Bortzmeyer wrote:

> Quelqu'un a-t-il déployé un système de ce genre ? (Attention aux
> conséquences juridiques, qui ne sont pas les mêmes de ce côté de
> l'Atlantique.)
> 
> RFC 6108 : Comcast's Web Notification System Design
> 
> http://www.bortzmeyer.org/6108.html
> 
> 
> 
> Auteur(s) du RFC: 
> C. Chung (Comcast), A. Kasyanov (Comcast), J. Livingood (tComcast), N. Mody 
> (Comcast), B. Van Lieu
> 
> 
> 
> 
> Soit un FAI avec beaucoup de clients résidentiels. La plupart utilisent 
> une machine sous Windows. Beaucoup de ces machines sont infectées par 
> un des innombrables virus ou vers qui existent pour cette plate-forme. 
> Devenues des zombies, ces machines participent désormais à diverses 
> opérations illégales comme les dDoS ou l'envoi de spam. Si le FAI 
> détecte, par le comportement de ces machines, ou par des rapports qui 
> lui sont envoyés, qu'un de ses clients a été zombifié, comment le 
> prévenir ? Vues les marges financières existantes dans cette industrie, 
> pas question d'envoyer un technicien compétent chez le client pour lui 
> expliquer. Il n'est même pas possible de l'appeler et de passer une 
> heure à répondre à ses questions idiotes, cela mangerait tout le profit 
> retiré de l'abonnement de ce client. Ce RFC décrit le système utilisé 
> par Comcast pour prévenir ses abonnés.
> 
> Il existe bien sûr d'autres méthodes, comme de couper purement et 
> simplement la connexion Internet dudit client. Cette méthode est 
> régulièrement réclamée par certains éradicateurs. Outre qu'elle n'est 
> pas dans l'intérêt financier du FAI (le client arrêterait de payer s'il 
> était coupé), elle n'est pas envisageable dans un État de droit (en 
> France, le Conseil Constitutionnel avait cassé une version de la loi 
> Hadopi car elle prévoyait une coupure de l'accès Internet sans 
> jugement). Même dans un pays de cow-boys, cette mesure est largement 
> jugée comme trop radicale (voir la description de la section 12, plus 
> loin). En outre, l'utilisateur risque de ne pas la comprendre, de 
> croire à une panne et d'embêter le support utilisateur. Comcast a donc 
> choisi une autre approche, celle de la notification à l'utilisateur, 
> dont on espère qu'il réagira et prendra des mesures pour éliminer le 
> "malware" de sa machine.
> 
> Concevoir un tel système de notification n'est pas évident. Il n'existe 
> (heureusement) pas de moyen technique standard permettant à un tiers, 
> le FAI, de faire soudain apparaître des messages sur l'écran de 
> l'utilisateur (un tel mécanisme serait vite détourné par des 
> plaisantins). Envoyer un courrier est simple et automatisable mais rien 
> ne garantit que l'utilisateur les lit (la plupart ne le liraient pas ou 
> bien, peut-être à raison, considéreraient-ils qu'il s'agit de 
> hameçonnage).
> 
> L'approche de Comcast est donc de profiter du fait que la plupart des 
> utilisateurs passent beaucoup de temps à regarder des pages Web. Il 
> « suffit » de détourner les pages HTML, d'y insérer le message et 
> bingo ! Le message apparaîtra à l'écran. Voici une copie d'écran de 
> http://www.example.com/, avec l'exemple de modification que donne le 
> RFC en section 8. Cette modification consiste simplement en l'ajout 
> d'un peu de JavaScript: Image (, 
> http://www.bortzmeyer.org/images/web-notification-example) (On note que 
> la possibilité d'accuser réception, mentionnée plus loin dans le RFC, 
> est absente de cet exemple. Notez aussi le commentaire dans le code CSS 
> qui insiste sur l'importance de ne pas hériter des styles qui seraient 
> déjà présents dans la page.)
> 
> Bref, ce mécanisme est une attaque de l'homme du milieu, réalisée pour 
> la bonne cause. Les auteurs insistent beaucoup sur le fait que leur 
> solution repose sur des normes ouvertes et n'utilise pas de DPI mais 
> cela me semble tout à fait secondaire. Le point important est que le 
> FAI joue un rôle plus actif dans la chasse aux zombies et, pour cela, 
> s'insère dans les communications de son client. Ce n'est pas forcément 
> une mauvaise idée mais c'est une modification sérieuse du modèle 
> traditionnel (où le client était seul maître à bord, même si, la 
> plupart du temps, il ne se rendait pas du tout compte de la 
> responsabilité qu'il avait.) Pour l'instant, il n'existe pas de travail 
> organisé à l'IETF sur ce problème des machines zom

[FRnOG] RE: [FRnOG] Re: [FRnOG] Transit Probléme Orange

2011-02-24 Par sujet Stephane JAUNE 

Oui ils en proposent effectivement entre leurs POPs, mais ils ne le 
mettent pas vraiment en avant.

-Message d'origine-
De : owner-fr...@frnog.org [mailto:owner-fr...@frnog.org] De la part de 
Radu-Adrian Feurdean
Envoyé : mercredi 23 février 2011 18:33
À : Stephane JAUNE; 'frnog@frnog.org'
Objet : RE: [FRnOG] Re: [FRnOG] Transit Probléme Orange


On Wed, 23 Feb 2011 15:45 +, "Stephane JAUNE"
 wrote:
> 
>   On les a reçus il y a peu et questionnés sur cette histoire de prix 
> très bas. Leur réponse ne me semble pas dénuée de sens : ils ne font que du 
> transit internet (à 99%), et donc pas d'infra onéreuse type mpls/vpls/...
> 
>   Du coup ils achètent un seul type de matos, n'investissent que très peu 
> dans la R&D, la formation du/des supports, ... et ca leur donne des coûts 
> très bas qu'ils répercutent sur le prix de vente.
> 
>   Intox ?

Ils ont l'air de vendre aussi du transport L2, et ont l'air bien
prepares pour le faire. Je n'ai pas encore achete ce type de service
chez eux encore, mais je me repete, ils ont l'air bien prepares pour le
faire.

-- 
Radu-Adrian Feurdean
 raf (a) ftml ! net

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Une idée rigolote pour prévenir les utilisateurs infectés

2011-02-24 Par sujet Stephane Bortzmeyer 
Quelqu'un a-t-il déployé un système de ce genre ? (Attention aux
conséquences juridiques, qui ne sont pas les mêmes de ce côté de
l'Atlantique.)

RFC 6108 : Comcast's Web Notification System Design

http://www.bortzmeyer.org/6108.html



Auteur(s) du RFC: 
C. Chung (Comcast), A. Kasyanov (Comcast), J. Livingood (tComcast), N. Mody 
(Comcast), B. Van Lieu




Soit un FAI avec beaucoup de clients résidentiels. La plupart utilisent 
une machine sous Windows. Beaucoup de ces machines sont infectées par 
un des innombrables virus ou vers qui existent pour cette plate-forme. 
Devenues des zombies, ces machines participent désormais à diverses 
opérations illégales comme les dDoS ou l'envoi de spam. Si le FAI 
détecte, par le comportement de ces machines, ou par des rapports qui 
lui sont envoyés, qu'un de ses clients a été zombifié, comment le 
prévenir ? Vues les marges financières existantes dans cette industrie, 
pas question d'envoyer un technicien compétent chez le client pour lui 
expliquer. Il n'est même pas possible de l'appeler et de passer une 
heure à répondre à ses questions idiotes, cela mangerait tout le profit 
retiré de l'abonnement de ce client. Ce RFC décrit le système utilisé 
par Comcast pour prévenir ses abonnés.

Il existe bien sûr d'autres méthodes, comme de couper purement et 
simplement la connexion Internet dudit client. Cette méthode est 
régulièrement réclamée par certains éradicateurs. Outre qu'elle n'est 
pas dans l'intérêt financier du FAI (le client arrêterait de payer s'il 
était coupé), elle n'est pas envisageable dans un État de droit (en 
France, le Conseil Constitutionnel avait cassé une version de la loi 
Hadopi car elle prévoyait une coupure de l'accès Internet sans 
jugement). Même dans un pays de cow-boys, cette mesure est largement 
jugée comme trop radicale (voir la description de la section 12, plus 
loin). En outre, l'utilisateur risque de ne pas la comprendre, de 
croire à une panne et d'embêter le support utilisateur. Comcast a donc 
choisi une autre approche, celle de la notification à l'utilisateur, 
dont on espère qu'il réagira et prendra des mesures pour éliminer le 
"malware" de sa machine.

Concevoir un tel système de notification n'est pas évident. Il n'existe 
(heureusement) pas de moyen technique standard permettant à un tiers, 
le FAI, de faire soudain apparaître des messages sur l'écran de 
l'utilisateur (un tel mécanisme serait vite détourné par des 
plaisantins). Envoyer un courrier est simple et automatisable mais rien 
ne garantit que l'utilisateur les lit (la plupart ne le liraient pas ou 
bien, peut-être à raison, considéreraient-ils qu'il s'agit de 
hameçonnage).

L'approche de Comcast est donc de profiter du fait que la plupart des 
utilisateurs passent beaucoup de temps à regarder des pages Web. Il 
« suffit » de détourner les pages HTML, d'y insérer le message et 
bingo ! Le message apparaîtra à l'écran. Voici une copie d'écran de 
http://www.example.com/, avec l'exemple de modification que donne le 
RFC en section 8. Cette modification consiste simplement en l'ajout 
d'un peu de JavaScript: Image (, 
http://www.bortzmeyer.org/images/web-notification-example) (On note que 
la possibilité d'accuser réception, mentionnée plus loin dans le RFC, 
est absente de cet exemple. Notez aussi le commentaire dans le code CSS 
qui insiste sur l'importance de ne pas hériter des styles qui seraient 
déjà présents dans la page.)

Bref, ce mécanisme est une attaque de l'homme du milieu, réalisée pour 
la bonne cause. Les auteurs insistent beaucoup sur le fait que leur 
solution repose sur des normes ouvertes et n'utilise pas de DPI mais 
cela me semble tout à fait secondaire. Le point important est que le 
FAI joue un rôle plus actif dans la chasse aux zombies et, pour cela, 
s'insère dans les communications de son client. Ce n'est pas forcément 
une mauvaise idée mais c'est une modification sérieuse du modèle 
traditionnel (où le client était seul maître à bord, même si, la 
plupart du temps, il ne se rendait pas du tout compte de la 
responsabilité qu'il avait.) Pour l'instant, il n'existe pas de travail 
organisé à l'IETF sur ce problème des machines zombies et chacun en est 
donc conduit à expérimenter seul (cf. section 13 du RFC).

Les détails pratiques suivent. La solution décrite très en profondeur 
est spécifique à DOCSIS mais pourrait être adaptée assez facilement à 
d'autres types d'accès. Les techniques utilisées sont le protocole ICAP 
(RFC 3507) et HTTP, les logiciels étant Squid et Tomcat.

Voyons d'abord le cahier des charges exact. Il figure en section 3. Je 
ne vais pas répéter tous ses points ici, seulement les plus importants. 
D'abord, les principes généraux :
* N'est utilisé que pour les notifications de problèmes sérieux (comme 
le recrutement dans un "botnet"), pas pour des publicités.
* Tourne sur le port 80, celui de HTTP, car à peu près tous les 
utilisateurs s'en servent. Ne doit