Re: [FRnOG] [TECH] Reverse DNS à la charge du provider de l'IP ou du nom de domaine
Bsr Frnog, Je réagis juste pour ne pas laisser trop de fausse idées se propager. 1 - Oleane = OBS puisque l'histoire veut que cette belle pme est été intégrée à Transpac devenu OBS depuis 2 - OBS gère bien les reverses DNS des ranges IP dont il est le owner. C'est classique, c'est bien normal et c'est une activité quotidienne des équipes opérationnelles et c'est bien gratuit ! :) 3 - par défaut OBS sur le périmètre France, OBS gère ces zones reverse sur les serveurs DNS primaires et secondaires ns*.oleane.net ou bow.rain.fr / proof.rain.fr 4 - dans le cas du range en question : 185.14.179.0/24, le bloc a été effectivement alloué par un autre ISP qui a gentiment délégué la gestion technique des reverses chez OBS en informant les serveurs root via un update du whois ripe de la zone : 179.14.185.in-addr.arpa 5 - deux solutions d'offrent donc : 1 : OBS fait la mise à jour souhaité, 2 : le mt-by fait une mise à jour nserver pour pointer ailleurs domain: 179.14.185.in-addr.arpa descr: Reverse Delegation for CHR ORLEANS admin-c:YG1186-RIPE tech-c: AQ497-RIPE zone-c: AQ497-RIPE nserver:ns6.oleane.net nserver:ns7.oleane.net mnt-by: FWDNS-MNT source: RIPE # Filtered Je propose donc à Vincent G. qu'il me passe un coup de fil histoire que je le mette en relation avec les bonnes personnes pour que cette affaire de quelques secondes soient réglées. Cyril H. Le 26 août 2014 à 14:32, Vincent Galiano vincent.gali...@gmail.com a écrit : Un grand merci pour tous ces éléments. Avec ces éléments je vais recontacter les deux partis pour identifier lequel est le plus enclin à réaliser l'action attendue... « La vie n’est pas un long fleuve tranquille, c’est une montagne à gravir. (Charles Regimbeau) » Cordialement, Vincent GALIANO Le 26 août 2014 13:44, Anthony Bourguignon contact+ml.fr...@toniob.net a écrit : Le mardi 26 août 2014 à 12:36 +0200, Leslie-Alexandre DENIS a écrit : Le 26/08/2014 12:21, Thomas Lecomte a écrit : On Tue, Aug 26, 2014 at 12:17:27PM +0200, David Ponzone wrote: Ton fournisseur IP dit n'importe quoi. +1. Notre fournisseur d'IP s'occupe de nos entrées PTR, et ce indépendamment de notre registrar. Il peut mettre ce qu'il veut. Oui les PTR sont gérés par le détenteur du bloc IP, ici FirstWan, qui doit maintenir au minimum deux serveurs de noms gérant ces mêmes PTR. L'information doit au final être publique et dans la base du Ripe sous la forme d'entité 'NS' ou nameserver. En un mot c'est bien le fournisseur de transit/LIR qui gère cela. Mais rien ne l'empêche de déléguer les NS à quelqu'un d'autre pour une plage d'adresses. Et si les noms de domaines sont gérés par OBS, ça me semble plus logique qu'ils se chargent aussi des reverses. Ils peuvent le faire. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Reverse DNS à la charge du provider de l'IP ou du nom de domaine
Tu réagis beaucoup :) David Ponzone Le 2 sept. 2014 à 08:33, Cyril H h...@internetown.eu a écrit : Bsr Frnog, Je réagis juste pour ne pas laisser trop de fausse idées se propager. 1 - Oleane = OBS puisque l'histoire veut que cette belle pme est été intégrée à Transpac devenu OBS depuis 2 - OBS gère bien les reverses DNS des ranges IP dont il est le owner. C'est classique, c'est bien normal et c'est une activité quotidienne des équipes opérationnelles et c'est bien gratuit ! :) 3 - par défaut OBS sur le périmètre France, OBS gère ces zones reverse sur les serveurs DNS primaires et secondaires ns*.oleane.net ou bow.rain.fr / proof.rain.fr 4 - dans le cas du range en question : 185.14.179.0/24, le bloc a été effectivement alloué par un autre ISP qui a gentiment délégué la gestion technique des reverses chez OBS en informant les serveurs root via un update du whois ripe de la zone : 179.14.185.in-addr.arpa 5 - deux solutions d'offrent donc : 1 : OBS fait la mise à jour souhaité, 2 : le mt-by fait une mise à jour nserver pour pointer ailleurs domain: 179.14.185.in-addr.arpa descr: Reverse Delegation for CHR ORLEANS admin-c:YG1186-RIPE tech-c: AQ497-RIPE zone-c: AQ497-RIPE nserver:ns6.oleane.net nserver:ns7.oleane.net mnt-by: FWDNS-MNT source: RIPE # Filtered Je propose donc à Vincent G. qu'il me passe un coup de fil histoire que je le mette en relation avec les bonnes personnes pour que cette affaire de quelques secondes soient réglées. Cyril H. Le 26 août 2014 à 14:32, Vincent Galiano vincent.gali...@gmail.com a écrit : Un grand merci pour tous ces éléments. Avec ces éléments je vais recontacter les deux partis pour identifier lequel est le plus enclin à réaliser l'action attendue... « La vie n’est pas un long fleuve tranquille, c’est une montagne à gravir. (Charles Regimbeau) » Cordialement, Vincent GALIANO Le 26 août 2014 13:44, Anthony Bourguignon contact+ml.fr...@toniob.net a écrit : Le mardi 26 août 2014 à 12:36 +0200, Leslie-Alexandre DENIS a écrit : Le 26/08/2014 12:21, Thomas Lecomte a écrit : On Tue, Aug 26, 2014 at 12:17:27PM +0200, David Ponzone wrote: Ton fournisseur IP dit n'importe quoi. +1. Notre fournisseur d'IP s'occupe de nos entrées PTR, et ce indépendamment de notre registrar. Il peut mettre ce qu'il veut. Oui les PTR sont gérés par le détenteur du bloc IP, ici FirstWan, qui doit maintenir au minimum deux serveurs de noms gérant ces mêmes PTR. L'information doit au final être publique et dans la base du Ripe sous la forme d'entité 'NS' ou nameserver. En un mot c'est bien le fournisseur de transit/LIR qui gère cela. Mais rien ne l'empêche de déléguer les NS à quelqu'un d'autre pour une plage d'adresses. Et si les noms de domaines sont gérés par OBS, ça me semble plus logique qu'ils se chargent aussi des reverses. Ils peuvent le faire. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Config SFR Voix en IP publiques ?
Intéressant... :) Personnellement, les polycoms que j'ai manipulé ne savait pas géré le NAT (il y a 3 à 4 ans) peut-être est-ce pour ne pas avoir à monter un réseau privé pour faire marcher leur centrex :) Après, vu le nombre de postes déployés, je penche plus pour l'idée d'Aurélien effectivement.. J'ai justement des téléphones SFR business team à appeler et si je peux les joindre directement en IP, ca serait sympa :) Cordialement, Le 1 septembre 2014 15:35, Aurélien footp...@gmail.com a écrit : 2014-09-01 15:30 GMT+02:00 David Ponzone david.ponz...@gmail.com: Bonjour, En jouant avec la configuration VoIP d’un client à nous qui était chez SFR pour Data et VoIP, j’ai découvert que les téléphones IP Polycom étaient adressés avec des IP publiques (93.20.94.6/XX gw 93.20.94.1). Je n’ai pas eu le temps d’analyser plus, donc je ne sais pas si les postes sont quand même derrière du NAT (et donc ils utilisent un petit/moyen/grand range public comme du privé) ou s’ils sont juste routés/filtrés. Dans le meilleur des cas, si le préfixe que SFR utilise pour cette numérotation est large, c’est encore un préfixe public qui est gâché. Si quelqu’un connait la config précise (idéalement un collaborateur de SFR) pour nous éclairer sur ce choix technique et la raison technique qui est derrière, cela serait intéressant. Bonjour, Je ne connais pas du tout le contexte, mais peut-être sont-ce des IPs publiques de SFR qui sont utilisées comme des RFC1918, mais locales à chaque site, afin d'uniformiser la configuration entre les sites clients, et de minimiser les collisions possibles avec le routage client ? Cordialement, -- Aurélien Guillaume --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] RFC 7353: Security Requirements for BGP Path Validation
Une nouvelle étape vers BGPsec, la validation du chemin d'AS entier dans l'annonce BGP : http://www.bortzmeyer.org/7353.html Auteur(s) du RFC: S. Bellovin (Columbia University), R. Bush (Internet Initiative Japan), D. Ward (Cisco Systems) La sécurité du routage BGP est un sujet de préoccupation sur l'Internet depuis de nombreuses années. Ce protocole ne dispose en effet par défaut d'aucune sécurité, n'importe quel opérateur (ou craqueur ayant piraté les routeurs d'un opérateur) pouvant annoncer une route vers n'importe quel préfixe, détournant, par exemple le trafic d'un service vital http://www.bortzmeyer.org/pakistan-pirate-youtube.html. Ce manque de sécurité ne vient pas d'une confiance naïve dans la nature humaine, mais plutôt de la nature même de l'Internet : il n'y a pas (heureusement !) de Haute Autorité Supérieure de l'Internet qui connaitrait tous les opérateurs et pourrait les autoriser et les surveiller. Un opérateur ne connait (et encore, pas toujours très bien) que ses voisins immédiats, et ne sait pas quelle confiance accorder aux autres. Dans ces conditions, la sécurisation de BGP est forcément un projet à long terme. La première grande étape avait été la normalisation et le déploiement de RPKI et ROA http://www.bortzmeyer.org/securite-routage-bgp-rpki-roa.html. L'étape suivante est la sécurisation du chemin entier (et pas uniquement de l'origine), dont ce nouveau RFC est la cahier des charges. En route donc vers *BGPsec* ! (Le nom PATHsec ne semble plus utilisé.) Rappelons en effet qu'une annonce BGP (RFC 4271) comprend un *chemin*, la liste des AS par lesquels l'annonce est passée (et, dans la plupart des cas, celle, en sens inverse, dans lequel un paquet IP émis par le récepteur de l'annonce voyagera s'il veut atteindre l'AS d'origine). Voici un telle annonce, extraite du service de looking glass d'Hurricane Electric : Prefix: 2001:678:c::/48, Status: E, Age: 31d9h14m31s NEXT_HOP: 2001:7fa:0:1::ca28:a116, Metric: 0, Learned from Peer: 2001:7fa:0:1::ca28:a116 (1273) LOCAL_PREF: 100, MED: 1, ORIGIN: igp, Weight: 0 AS_PATH: 1273 2200 2484 Le chemin comprend trois AS, et l'*origine*, l'AS émetteur de l'annonce, est 2484 (oui, tout à droite : un chemin d'AS se lit de droite à gauche). Avec les certificats de la RPKI (RFC 6480) et avec le système des ROA (Route Origin Authorization, RFC 6482), on peut désormais (RFC 6811) valider l'origine d'une annonce. Cela protège contre les détournements accidentels (comme celui de YouTube par Pakistan Telecom cité plus tôt), où l'AS d'origine est en général celle du détourneur. Mais lors d'une attaque délibérée, l'attaquant peut tricher sur le chemin et envoyer une annonce avec un chemin d'AS qui semble correct, avec la bonne origine. RPKI+ROA ne protègent pas contre cet attaquant compétent. (Les RFC 4593 et RFC 7132 décrivent en détail les vulnérabilités de BGP.) Maintenant, place aux exigences que devra satisfaire la nouvelle solution de sécurisation. La section 3 du RFC liste les exigences générales et la section 4 celles spécifiques au traitement effectué lors de la réception d'une annonce BGP. Les exigences générales d'abord, numérotées de 3.1 à... 3.23 (oui, une longue liste). D'abord, 3.1 et 3.2, qui résument le projet complet : le routeur BGP qui reçoit une annonce doit pouvoir déterminer, avec un bon niveau de confiance, que l'origine dans l'annonce (exigence 3.1), et le chemin des AS (AS Path) dans l'annonce (exigence 3.2) sont authentiques. On veut être sûr que l'AS d'origine avait bien le droit d'annoncer ce préfixe, et que le chemin d'AS dans l'annonce reflète bien le chemin suivi par l'annonce (dans l'exemple ci-dessus, que 2484 avait bien le droit d'annoncer le préfixe 2001:678:c::/48, et qu'il a bien transmis l'annonce à 2200, qui l'a lui-même bien transmis à 1273). Attention, il ne s'agit pas uniquement de montrer que le chemin d'AS est possible (ces AS sont bien des pairs...) mais que c'est bien celui qui a effectivement été utilisé. Les autres attributs de l'annonce (comme le MED dans l'exemple ci-dessus) ne sont *pas* protégés (exigence 3.3) car ils ne sont utilisés que dans un AS ou ses voisins immédiats. (Voir aussi l'exigence 3.10.) Comme toute technologie nouvelle, BGPsec aura des difficultés de déploiement, dans un Internet très ossifié, et la nouvelle solution devra donc être déployable de manière incrémentale (exigences 3.4 et 3.5) : les routeurs BGPsec devront pouvoir travailler avec les routeurs actuels (exigence 3.13 ; la section 5 reconnait que cette exigence ouvre la voie aux attaques par repli, où un attaquant réussit à faire croire qu'un pair ne gère pas BGPsec et qu'il faut donc se replier sur un protocole non sécurisé). Au début, les routeurs BGPsec auront sans doute des pairs BGPsec et d'autres en BGP non sécurisé et BGPsec doit donc pouvoir être configuré
RE: [FRnOG] [TECH] Config SFR Voix en IP publiques ?
Régis M a écrit : Personnellement, les polycoms que j'ai manipulé ne savait pas géré le NAT (il y a 3 à 4 ans) Ce n'est pas que les Polycoms. SIP est un protocole qui a été conçu pour ne pas traverser NAT, toutes les marques sont dans le même bateau. Faut être fou pour faire du SIP à travers NAT, c'est des emmerdes à n'en plus finir. Donc tout le monde fait un VLAN pour les téléphones SIP qui ne traverse pas NAT. peut-être est-ce pour ne pas avoir à monter un réseau privé pour faire marcher leur centrex :) Après, vu le nombre de postes déployés, je penche plus pour l'idée d'Aurélien effectivement.. troll Ils pourraient utiliser le 30.net, comme tout le monde. /troll Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
