Re: [FRnOG] L'inria est leet
Chalut ! Le 29/04/2010 14:21, Steven Le Roux a écrit : 2010/4/29 Julien Reveret mailto:shad...@c0a8.org>> A ceux qui pensent que HADOPI sera un échec à cause de seedfuck et compagnie, je tiens à signaler la disponibilité d'un manuscrit de chercheurs de l'INRIA. Ils ont présenté leurs travaux lors du séminaire Large-Scale Exploits and Emergent Threats (LEET) : http://hal.inria.fr/docs/00/47/03/24/PDF/bt_privacy_LEET10.pdf Le principe de seedfuck me semble limité si tu fais une analyse heuristique d'un tracker... Je ne vois pas l'intérêt de seedfuck, à part autotuer le réseau p2p... Je pense pas que seedfuck va tuer quoi que ce soit, par contre pour moi c'est un proof of concept pour montrer que si on ne se fie qu'au tracker, on pourrait y trouver beaucoup de fausses IP. Ils sont sponsorisés par le Ministère de la Culture, vous croyez ? Pierre --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] L'inria est leet
Ce n'est pas vendredi... si ? 2010/4/29 Julien Reveret > Bonjour à tous, > > A ceux qui pensent que HADOPI sera un échec à cause de seedfuck et > compagnie, je tiens à signaler la disponibilité d'un manuscrit de > chercheurs de l'INRIA. Ils ont présenté leurs travaux lors du séminaire > Large-Scale Exploits and Emergent Threats (LEET) : > > http://hal.inria.fr/docs/00/47/03/24/PDF/bt_privacy_LEET10.pdf > Le principe de seedfuck me semble limité si tu fais une analyse heuristique d'un tracker... Je ne vois pas l'intérêt de seedfuck, à part autotuer le réseau p2p... > > En utilisant plusieurs sources d'information, les chercheurs seraient > arrivés à trouver les "content providers", même si ces derniers se cachent > derrière le réseau Tor. On notera que les trackers peuvent être très > bavards quand on sait poser les bonnes questions ! > > Pour d'autres papiers sur le même sujet, se rendre sur la page : > http://www-sop.inria.fr/members/Arnaud.Legout/Projects/bluebear.html > > Qui a dit que la recherche fondamentale n'apportait rien à l'industrie ? :) > > > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > > -- Steven Le Roux Jabber-ID : ste...@jabber.fr 0x39494CCB 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB
[FRnOG] L'inria est leet
Bonjour à tous, A ceux qui pensent que HADOPI sera un échec à cause de seedfuck et compagnie, je tiens à signaler la disponibilité d'un manuscrit de chercheurs de l'INRIA. Ils ont présenté leurs travaux lors du séminaire Large-Scale Exploits and Emergent Threats (LEET) : http://hal.inria.fr/docs/00/47/03/24/PDF/bt_privacy_LEET10.pdf En utilisant plusieurs sources d'information, les chercheurs seraient arrivés à trouver les "content providers", même si ces derniers se cachent derrière le réseau Tor. On notera que les trackers peuvent être très bavards quand on sait poser les bonnes questions ! Pour d'autres papiers sur le même sujet, se rendre sur la page : http://www-sop.inria.fr/members/Arnaud.Legout/Projects/bluebear.html Qui a dit que la recherche fondamentale n'apportait rien à l'industrie ? :) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: Ip publiques (was Re: [FRnOG] Pb OVH)
Xavier Nicollet wrote: Le 29 avril 2010 à 11:28, Antoine Versini a écrit: Disons que tu peux avoir communication si un routeur est amenné à proposer une fragmentation à l'éméteur du paquet qu'il détruit. Communication unidirectionnelle, certes, mais communication tout de même. Le routeur prend-il l'ip de la loopback pour émettre l'icmp ? Il me semblerait plus logique qu'il utilise l'ip de l'interface de sortie. Le comportement standard est bien d'utiliser l'adresse IP (principale pour un certain vendeur ;) ) de l'interface par laquelle s'est présenté le paquet détruit. PS: je ne pensais pas particulièrement aux loopbacks quand j'ai posté. Ok. -- Antoine Versini Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: Ip publiques (was Re: [FRnOG] Pb OVH)
Le 29 avril 2010 à 11:28, Antoine Versini a écrit: > Disons que tu peux avoir communication si un routeur est amenné à > proposer une fragmentation à l'éméteur du paquet qu'il détruit. > Communication unidirectionnelle, certes, mais communication tout de même. Le routeur prend-il l'ip de la loopback pour émettre l'icmp ? Il me semblerait plus logique qu'il utilise l'ip de l'interface de sortie. PS: je ne pensais pas particulièrement aux loopbacks quand j'ai posté. -- Xavier Nicollet --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: Ip publiques (was Re: [FRnOG] Pb OVH)
Tout cela dépend d'une politique d'annonce et de stratégie de sécurité on peut très bien adresser tout son backbone en privé ou décider d'utiliser des blocs publique qui seront Null routé sur les routeurs de bordures et les routeurs servant de gateway au clients. Pour vivre heureux vivons caché ;-) Michaël Villar -Message d'origine- De : nicol...@jeru.org [mailto:owner-fr...@frnog.org] De la part de Xavier Nicollet Envoyé : jeudi 29 avril 2010 10:23 À : frnog@FRnOG.org Objet : Ip publiques (was Re: [FRnOG] Pb OVH) Le 28 avril 2010 à 19:04, Radu-Adrian Feurdean a écrit: > Le pire que j'ai vu c'est des IP publiques utilises dans le core mais > pas annonces dans la table globale Des IP publiques peuvent être annoncées à des peers sans pour autant se retrouver dans la table globale. Ca me semble un fonctionnement certes inhabituel, mais normal en IPv4. -- Xavier Nicollet --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: Ip publiques (was Re: [FRnOG] Pb OVH)
Clement Cavadore wrote: Ce fonctionnement là ne me choque pas. Si on a un subnet alloué pour le backbone, il faut bien qu'il soit public (ie: non RFC1918), mais si la communication avec l'extérieur du réseau n'est pas nécessaire (ce qui est généralement le cas avec les IPs d'interco interne au réseau, ou les loopbacks), alors pourquoi l'annoncer ? Disons que tu peux avoir communication si un routeur est amenné à proposer une fragmentation à l'éméteur du paquet qu'il détruit. Communication unidirectionnelle, certes, mais communication tout de même. Sur 5410 j'avais totalement filtré en entrant les classes servant à la numération des loopbacks et des /30 d'interco sur tout l'edge du réseau. C'est encore la moins pire des protections. Pour les probes venant de l'intérieur (les abonnés), une policy-map sur le control-plane est suffisante. Bref, on en revient à l'origine de la discussion, filtrer ICMP vers l'ensemble de ses blocs est inepte sachant que n'importe quel mioche peut trouver le switch UDP ou TCP de son botnet. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: Ip publiques (was Re: [FRnOG] Pb OVH)
On Thu, 29 Apr 2010 10:22:56 +0200, "Xavier Nicollet" said: > Des IP publiques peuvent être annoncées à des peers sans pour autant se > retrouver dans la table globale. > Ca me semble un fonctionnement certes inhabituel, mais normal en IPv4. En occurence pas visible en tant que client, pas visible via leur transit, tres probablement pas visible du tout. ... cretainement tres efficace pour proteger des equipements de backbone ... -- Radu-Adrian Feurdean raf (a) ftml ! net --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Perte liaison SFR sur en Auvergne
"Romain LE DISEZ" Ecrivait: > > Le 28 avr. 2010 à 22:18, Rault Alexandre a écrit : > >> On me signale dans l'oreillette (par SMS surtout) que des abonnés privés chez >> SFR en banlieue de Clermont-Ferrand et à Montluçon n'ont plus d'accès au net. >> >> Des infos...? (je trouve ni tickets publiques ni weathermap chez eux :s ) > > A la grande époque, il y avait ça : > http://assistance.neuf.fr/neuf/support/etatreseau.do > > Mais j'ai un doute, je ne suis pas sûr que ce soit toujours maintenu... > > -- > Romain LE DISEZ > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > > Je n'ai pas eut d'autre feedback.. à priori c'est revenu à la normale. Le http://assistance.neuf.fr/neuf/support/etatreseau.do ne semble pas aboutir, ou du moins, pas à des infos exploitables (mais bon, là je suis sur un lan "bizarrement filtré", il faudra que je regarde depuis ailleurs). Merci. -- Rault Alexandre Blue Networks Technologies SARL au capital de 2000 euros RCS : 509 072 500 9 rue Pasteur - 63510 Aulnat 06.23.42.03.02 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: Ip publiques (was Re: [FRnOG] Pb OVH)
Hello, On Thu, 2010-04-29 at 10:22 +0200, Xavier Nicollet wrote: > Le 28 avril 2010 à 19:04, Radu-Adrian Feurdean a écrit: > > Le pire que j'ai vu c'est des IP publiques utilises dans le core mais > > pas annonces dans la table globale > > Des IP publiques peuvent être annoncées à des peers sans pour autant se > retrouver dans la table globale. > Ca me semble un fonctionnement certes inhabituel, mais normal en IPv4. Ce fonctionnement là ne me choque pas. Si on a un subnet alloué pour le backbone, il faut bien qu'il soit public (ie: non RFC1918), mais si la communication avec l'extérieur du réseau n'est pas nécessaire (ce qui est généralement le cas avec les IPs d'interco interne au réseau, ou les loopbacks), alors pourquoi l'annoncer ? C'est, IMHO, moins choquant que d'utiliser des IPs publiques dans un LAN NATé vers Internet... Egalement, dans les réseaux financiers (coucou a qui se reconnaîtra :)), ils utilisent des IPs publiques sur un "internet parallèle". Même si ca me choque un peu personnellement, ca reste compliant avec les usages du RIPE (peut être des autres RIR), semble-t-il. L'allocation de ressources se fait, il me semble, sans que le RIR n'aie quoi que ce soit à dire quant à l'annonce (partielle ou totale) sur Internet desdites ressources. -- Clément Cavadore --- Liste de diffusion du FRnOG http://www.frnog.org/
Ip publiques (was Re: [FRnOG] Pb OVH)
Le 28 avril 2010 à 19:04, Radu-Adrian Feurdean a écrit: > Le pire que j'ai vu c'est des IP publiques utilises dans le core mais > pas annonces dans la table globale Des IP publiques peuvent être annoncées à des peers sans pour autant se retrouver dans la table globale. Ca me semble un fonctionnement certes inhabituel, mais normal en IPv4. -- Xavier Nicollet --- Liste de diffusion du FRnOG http://www.frnog.org/
