Turb(l)o(g)

Crédit photo : etringita (flickr)

C’est dès le départ un faux titre, les IP n’appartiennent (au sens « propriété » du terme) à personne. Elles ne s’achètent pas (du moins pas à leur source, il y a un certain nombre d’entreprise qui les vendent pourtant). Il s’agit d’un bien mondial, probablement d’ailleurs l’un des premier bien mondiaux crée par l’homme (j’ai bien cherché, je trouve pas de contre exemple, help !).

On peut avoir besoin de savoir qui utilise une IP pour deux grandes questions majoritaires : techniques ou légales. Etant donné l’actualité, c’est le coté légal qui intéresse aujourd’hui le plus de monde, la question étant donc de savoir sur qui taper, soit pour identifier un utilisateur, soit pour bloquer un contenu.

La plus simple manière de le savoir, c’est bien sur de demander au dernier maillon de la chaîne qui soit publiquement identifiable, à savoir l’opérateur qui gère le bloc d’adresses qui contient celle qui nous intéresse. Je ne dit volontairement pas « fournisseur d’accès », les acteurs étant à même de fournir des IP étant une famille beaucoup plus large.

Notez que ce billet n’a que peu d’intérêt pratique pour le premier quidam venu. Le fait, pour un opérateur, de révéler à n’importe qui l’identité qui se cache derrière une IP est sévèrement puni par la loi (en France, du moins). Par contre, ça peut satisfaire un peu de curiosité.

Par ailleurs, le fournisseur d’accès ne pourra fournir que les coordonnées de son client. Contrairement à une voiture flashée en plein excès de vitesse, il sera matériellement presque impossible de prouver qui était au commande derrière l’adresse IP, même en récupérant la totalité du flux d’information transmis dans les deux sens, et en tout cas pas sans perquisition poussée avec analyse de contenus de disque dur, etc …

Bon, on sait donc a qui demander. Mais maintenant, comment savoir qui est cet opérateur ?

Les blocs d’adresse IP sont géré, au sommet, par une entité portant le doux nom d’IANA. Elle distribue les blocs à 5 entités mondiales se partageant la planète, les RIR (Regional Internet Registry). Ils sont généralement composés d’opérateurs qui se partagent donc ensuite les blocs attribués par l’IANA. ces opérateurs délèguent enfin une partie des blocs a des clients finaux ou les conservent pour leur usage propre.

Chaque assignation de bloc à un opérateur entraîne théoriquement l’ajout de l’information a un annuaire central géré par le RIR (une base « whois ») qui, entre autres informations, peut donc répondre a la question « quel opérateur gère telle adresse » et aussi, en partie « comment joindre l’opérateur en question ».

Je dis « théoriquement » parce qu’il est tout à fait possible d’utiliser un bloc d’IP sans qu’il ait été attribué ou référencé dans les bases de données, de la même façon qu’on peu tout a fait utiliser le bloc d’IP d’un petit camarade sans lui demander son avis. Nous verrons plus loin qu’il est toute fois possible de retrouver, à posteriori, l’opérateur qui a indûment utilisé un bloc.

Voyons le retour d’une demande whois auprès du RIPE (le RIR européen) concernant une adresse IP prise au hasard. On l’obtient sous n’importe quel OS équipé de la commande whois en tapant « whois -h whois.ripe.net 193.40.32.5 ». Il existe aussi des accès aux serveurs whois via le web :

inetnum: 193.40.32.0 – 193.40.32.255
netname: EC-NET
descr: Eurofaculty
descr: University of Tartu
country: EE
admin-c: OT463-RIPE
tech-c: EK618-RIPE
remarks: rev-srv: kadri.ut.ee madli.ut.ee ns2.eenet.ee
status: ASSIGNED PA
mnt-by: EENET-MNT
remarks: Maintainer RIPE-NCC-NONE-MNT removed and object
remarks: LOCKED by the RIPE NCC due to
remarks: deprecation of the NONE authentication scheme.
remarks: Please visit the following URL to unlock this object
remarks: http://www.ripe.net/db/none-deprecation-042004.html
source: RIPE # Filtered
remarks: rev-srv attribute deprecated by RIPE NCC on 02/09/2009

person: Otto Teller
address: Departement of Information Technology
address: Tartu University
address: Ylikooli 18a
address: 50090 Tartu
address: Estonia
phone: +3727375438
fax-no: +3727375460
e-mail: ott[…]t.ee
nic-hdl: OT463-RIPE
source: RIPE # Filtered

person: Erkki Kukk
address: Department of Information Technology Services
address: Tartu University
address: Ylikooli 18a
address: 50090 Tartu
address: Estonia
phone: +372 7 375459
fax-no: +372 7 375460
e-mail: erk[…]t.ee
nic-hdl: EK618-RIPE
source: RIPE # Filtered

% Information related to ‘193.40.0.0/16AS3221’

route: 193.40.0.0/16
descr: EENET aggregate
origin: AS3221
mnt-by: AS3221-MNT
source: RIPE # Filtered

Que nous apprend ce résultat ?

• Que l’IP sur laquelle nous avons jeté notre dévolu fait partie d’un bloc de 256 adresses qui a été attribué à l’université de Tartu en Estonie.
• Que la personne en charge des aspects administratifs de la gestion de ce bloc d’adresse porte l’identifiant OT463. Cet identifiant est détaillé plus loin avec le nom, l’adresse postale et email de la personne
• Que la personne en charge des aspects techniques est Ek618 (détaillé, de même, plus loin)
• Que les serveurs DNS à qui sont délégués la gestion des reverses des adresses du bloc sont kadri.ut.ee, madli.ut.ee et ns2.eenet.ee
• Que ce bloc à été assigné à un opérateur membre du RIR (ASSIGNED-PA)
• Suit un avertissement du RIR sans grand intérêt pour ce que nous cherchons
• Suivent les détails des deux contacts mentionnés ci-dessus (il peut y en avoir qu’un seul ou beaucoup plus)
• Et, pour clore le résultat, nous apprenons que ce bloc fait partie d’un bloc plus gros (193.40.0.0/16) qui doit théoriquement être annoncé par le système autonome 3221 qui porte pour doux nom EENET.

Il est capital de se souvenir que ces informations sont présentent dans cette base de donnée parce que les responsable des IP concernées les y ont mis. Ils ne sont soumis, en pratique, à aucun contrôle de la part de qui que ce soit. Il existe donc une probabilité non négligeable que les informations soient incomplètes, erronées, périmées, voir carrément fausses (coucou HADOPI .. Vous comptiez vous baser la dessus pour envoyer les réquisitions aux FAI ? C’est raté ! Mais lisez la suite, je vous sauve plus loin)

Une seconde requête whois sur le système autonome censé annoncer ce bloc donne ceci (j’ai fais un peu de nettoyage pour réduire la taille) :

aut-num: AS3221
as-name: UNSPECIFIED
descr: EENet Autonomous System
descr: Estonian Educational and Research Network
descr: EE
import: from AS1741
action pref=100;
accept ANY
import: from AS2380
action pref=100;
accept AS2380
import: from AS3327
action pref=100;
accept AS3327
export: to AS1741
announce AS3221
export: to AS2380
announce AS3221
export: to AS3327
announce AS3221
default: to AS1741
action pref=100;
networks ANY
admin-c: MIKK1-RIPE
tech-c: PIKK1-RIPE
mnt-by: AS3221-MNT
source: RIPE # Filtered

person: Mihkel Kraav
address: Raekoja plats 14
address: 51004 Tartu
address: Estonia
phone: +372 7 302110
fax-no: +372 7 302111
nic-hdl: MIKK1-RIPE
source: RIPE # Filtered

person: Urmas Lett
address: EENet
address: Raekoja plats 14
address: Tartu 51004
address: Estonia
phone: +372 7 302 110
fax-no: +372 7 302 111
nic-hdl: PIKK1-RIPE
source: RIPE # Filtered

Cette requête nous apprend :

• Que ce système autonome est celui du réseau de l’éducation et de la recherche de l’Estonie (EENET)
• Qu’il est interconnecté avec l’AS174 (Cogent) qui lui fourni du transit (import: accept ANY et export: AS3221)
• Qu’il est aussi interconnecté (probablement en peering) avec AS2380 et AS3327
• Que l’administrateur système qui a renseigné ces informations a fait une typo en tapant « AS1741 » au lieu de « AS174 » dans l’un des champ
• Que les responsables administratifs et techniques sont respectivement MIKK1 et PIKK1 (avec le détail des moyens pour les joindre juste après)

La encore, je souligne que ces informations sont à titre indicatif et non vérifiées (la preuve en est, il y a une typo dedans et ça ne semble émouvoir personne)

Voila donc le résumé de la situation, notre IP d’exemple est gérée (au plus haut qu’on puisse remonter pour taper sur quelqu’un) par l’équivalent en Estonie de notre Renater national, que plus précisément elle est utilisée dans l’université de Tartu et que nous avons les informations de contact d’au moins 4 personnes qui vont pouvoir nous aider si jamais l’IP en question pose un problème technique ou légal.

On peut se dire que l’information « université de Tartu » permet de circonscrire un périmètre géographique très restreint, ce n’est pas forcément vrai dans la mesure ou :

• Si l’opérateur EENET a mal fait son travail, le bloc en question peut très bien être utilisé n’importe ou ailleurs et pas par l’université de Tartu
• Quand bien même le bloc serait bien utilisé par cette université, rien n’empêcherai quelqu’un la bas d’installer un serveur VPN pour propager une ou plusieurs IP n’importe ou ailleurs sur la planète, y compris sur un terminal mobile de la taille d’un paquet de cigarette sur une île paumée au fin fond du pacifique sud.

Comment affiner un peu nos informations ? « traceroute » est notre ami. C’est un outil qui, encore une fois, n’a rien de magique. Il se contente de lister tous les routeurs qui veulent bien se faire connaitre entre la machine ou on le lance et une IP quelconque (notez que traceroute fourni également les temps de parcours jusqu’à chaque routeur mais que je les ai supprimé pour que ça prenne moins de place. Il affiche également les IP et les noms correspondants. Comme pour whois, vous trouverez des versions web de cet outil sans trop de difficultés) :

4 global-crossing-xe-level3.paris1.level3.net (4.68.127.98)
5 DANTE.TenGigabitEthernet7-3.ar1.FRA4.gblx.net (207.138.144.46)
6 so-6-0-0.rt2.cop.dk.geant2.net (62.40.112.50)
7 so-0-0-0.rt1.tal.ee.geant2.net (62.40.112.122)
8 eenet-bckp-gw.rt2.tal.ee.geant2.net (62.40.124.50)
9 trt-fe.bb.eenet.ee (193.40.133.6)
10 ut-gw1.bb.eenet.ee (193.40.133.210)
11 sein.ut.ee (193.40.12.10)
12 ak-gw.ut.ee (193.40.12.14)
13 video.ut.ee (193.40.32.5)

Qu’a-t-on appris ?

• Que l’administrateur qui a rempli la base whois du RIPE a, en plus d’avoir fait une typo, menti, ou plus probablement oublié de mettre à jour ses informations, puisque les paquets sautent directement de l’IP 62.50.124.50 appartenant à GEANT2, AS20965 (le réseau européen de la recherche) à l’IP 193.40.133.6 appartenant à EENET et que ça n’a pas été déclaré au RIPE.
• Que EENET s’alimente en transit international via le réseau GEANT2 puisque notre traceroute, parti de mon petit réseau, a traversé 3 systèmes autonomes avant d’arriver à GEANT2.
• Que les deux derniers routeurs avant notre cible sont déclarés eux aussi comme étant sous la houlette de l’université de Tartu
• Qu’étant donné le supplément de latence entre le dernier routeur et notre cible (de l’ordre de 0.2 millisecondes), il est peu probable que l’IP soit au bout d’un VPN ou alors ce bout n’est pas bien loin du dernier routeur traversé (vous n’avez pas les valeurs de temps de trajet sur mon extrait, il faudra me croire sur parole)

On peut donc valablement supposer que l’IP cible est bien sous la gestion technique de l’université de Tartu. Il conviendra quand même de vérifier en contactant les responsable du réseau EENET si on a réellement besoin de certitude avant, par exemple, de déclencher un raid massif.

Voyons à présent comment partir à la chasse d’IP fantômes qui n’existent pas dans les bases publiques. C’est un peu plus poilu que ce qui précède.

Commençons par le cas ou le bloc en question est toujours annoncé sur internet (par exemple, l’IP cible répond au ping). Il suffit de se rendre sur n’importe quel looking glass (accès direct aux routeurs du réseau, par exemple celui proposé par le RIPE), de taper l’IP dans un appel « show ip bgp », et on obtient, parmi les informations retournée, le numéro de système autonome qui publie, à l’instant même ou on fait la demande, cette IP sur le réseau.

Par exemple, pour l’IP de tout à l’heure (193.40.32.5), on obtient tout un tas de groupes de 4 lignes correspondant aux divers chemins que le routeur que nous avons interrogé connait pour aller joindre l’IP demandée (nous n’en décortiquerons qu’un seul) :

  2895 3058 50139 20965 3221
    193.232.244.36 from 193.232.244.36 (147.45.0.7)
      Origin IGP, localpref 100, valid, external
      Last update: Thu Sep  9

• La première est la liste des systèmes autonomes à traverser pour joindre celui (à la fin) qui annonce cette IP. Nous avons donc bien confirmation que dans la réalité technique, c’est bien l’AS d’EENET qui annonce le bloc comme indiqué au RIPE.
• La seconde donne des indications interne de la route à suivre par les paquets dans le routeur que nous avons questionné.
• La troisième nous informe que ce routeur a appris cette route depuis un autre routeur à l’intérieur du même réseau et qu’elle est externe à ce réseau.
• La dernière nous informe de la date de dernière modification de l’entrée dans la base de donnée du routeur interrogé.

Prenons maintenant un exemple d’un bloc d’IP non autorisé mais présent quand même sur le réseau. Par exemple, à l’heure ou j’écris ces lignes, le bloc 198.51.100.0/24 qui n’est pas censé exister sur internet (c’est un bloc de test) est annoncé par l’AS16953 (Ascent Media Group).

Nous n’obtiendront aucun contact administratif ou technique en demandant aux bases whois, la seule information présente étant « c’est un bloc de test ». Les seuls à pouvoir nous renseigner sont chez l’opérateur en question.

Mais si, après la publication de mon billet, l’opérateur s’aperçoit de la bourde et la corrige (fort peu probable), le bloc disparaîtra instantanément du réseau mondial et il sera impossible de remonter jusqu’à eux en questionnant les routeurs via des looking glass.

Heureusement, des personnes qui s’ennuient au RIPE ont crée un outil fort sympathique prénommé REX qui permet d’obtenir un historique de qui a annoncé quoi et quand sur le réseau sur une période assez impressionnante.

En l’occurrence, REX nous apprends qu’en 2007, un autre opérateur à commis la même bourde sur un préfixe largement plus gros (198.0.0.0/7) qui contient lui-même 198.51.100.0/24, bourde qui a immédiatement été corrigée, alors que celle d’Ascent dure depuis le 4 juin 2010. A se demander d’ailleurs si c’est réellement une bourde ou pas, d’autant qu’une IP du bloc (198.51.100.138) répond au ping.

On peut aussi, via cet outil, trouver les petits malins, par exemple ceux qui ont voulu accéder Saint Graal de tout geek qui se respecte, avoir l’IP 42.42.42.42 (qui fait partie du bloc 42/8, l’un des dernier laissé en réserve actuellement). Les gagnants sont Level3 le 25 mars 2004, Telefonica Espagne le 23 aout 2007, EuroTel Bratislava le 23 janvier 2008, le NOC du département de la défense américain le 27 février 2008 et enfin Telianet qui a fait *la* bourde en voulant annoncer la moitié d’internet en un seul morceau (0.0.0.0/1) le 15 mai 2008. Toutes ces bourdes ont été corrigées le jour même.

Vous voila armé pour briller dans votre prochain diner mondain. Et, si par malchance vous tombez dessus, vous devriez pouvoir être en mesure de trouver un contact technique chez un opérateur qui aurait du contenu que votre morale et que la loi répriment, information que vous pourrez transmettre à qui de droit.

Je me rends compte, à la relecture, que la notation des blocs d’IP (198.51.100.0/24 par exemple) va en dérouter plus d’un. Promis, je ferais vite vite un article la dessus.