Alla ricerca dell’IP perduto

traceroute

Ieri il mio amico Ludo mi ha fatto notare un interessante articolo di Jan Kneschke, che sul suo blog scrive a proposito di un database da lui ideato anni fa contenente una mappatura tra indirizzi IP e luoghi geografici.

L’idea è carina e Jan ci spiega come ricavare i nostri dati passo dopo passo, effettuando delle semplici prove con ping e traceroute. Dopo qualche minuto di lettura, o di tentativi, ci convinciamo presto che sia davvero possibile crearci un nostro siffatto database, dove scovare in un batter d’occhio la provenienza di qualsiasi utente su Internet e stupire gli amici su IRC!

La realtà purtroppo è ben diversa, e la rete (a torto o a ragione) si è evoluta in questi anni seguendo i due capisaldi della sicurezza informatica casereccia: security through obscurity e firewall come panacea di tutti i mali. Se da un lato quindi gli amministratori hanno pensato bene di rendere i nomi dei core router su Internet incomprensibili, in modo da non svelare la loro posizione geografica, dall’altro i terribili firewall seminati un po’ ovunque hanno come policy di default il blocco totale di qualunque tipo di traffico, anche a costo di violare palesemente gli RFC. Compreso, naturalmente, quel traffico che dovrebbe servire a fare del sano troubleshooting.  Nonostante questo, è ancora possibile (per fortuna) divertirsi un po’ con Internet ed i tool che abbiamo a disposizione. 

Cerchiamo italia.it

Negli ultimi giorni ha fatto scalpore la chiusura di italia.it, evento del quale abbiamo avuto pietà e dedicato solo una vignetta. Potrebbe essere possibile sapere dove sia fisicamente localizzato il server?

$ host italia.it
italia.it has address 195.66.9.142
italia.it mail is handled by 0 italia.it.

Proviamo ad effettuare allora il traceroute:

$ traceroute -w 2 -q 1 -I 195.66.9.142
traceroute to 195.66.9.142 (195.66.9.142), 30 hops max, 40 byte packets
[...]
5 garr.mix-it.net (217.29.66.39) 1.757 ms
6 rt-mi2-rt-rm2.rm2.garr.net (193.206.134.230) 11.566 ms
7 pdc-rtg.rm.garr.net (193.206.131.50) 11.979 ms
8 *
9 *

Nelle reti di grandi dimensione, ed in generale Internet, si utilizza BGP come  protocollo di routing per trasportare le informazioni relative agli indirizzi delle varie sottoreti. BGP è un protocollo molto sofisticato e complesso, dalle tante opzioni, ma il principio di funzionamento di base è molto semplice, non dissimile da un qualsiasi altro protocollo di tipo Distance Vector. Se teniamo in mente questa considerazione, notiamo che per come sono collegati tra di loro i Service Provider (ossia la topologia della rete) è molto difficile che se ne debbano attraversare più di tre, massimo quattro, per raggiungere la destinazione desiderata. È quindi sensato ritenere che al settimo hop del nostro traceroute si sia già arrivati all’ISP di italia.it, e che il server si trovi fisicamente a Roma, come indicato.

Camminiamo con le nostre gambe

Sempre prendendo spunto dalle intenzioni del tutorial di Jan, possiamo provare a divagare leggermente dai nostri scopi, alla ricerca di informazioni più interessanti su una particolare sottorete. Usiamo stavolta un sito differente:

$ host www.alitalia.com
www.alitalia.com has address 80.72.160.111

Ecco come si comporta il nostro traceroute:

$ traceroute -w 2 -q 1 -I 80.72.160.111
traceroute to 80.72.160.111 (80.72.160.111), 30 hops max, 40 byte packets
[...]
6 r-mi265-gw-mi-nap2.opb.interbusiness.it (151.99.98.129) 22.613 ms
7 151.99.75.245 (151.99.75.245) 8.483 ms
8 151.99.98.177 (151.99.98.177) 12.995 ms
9 r-rm212-csr-rm004.opb.interbusiness.it (151.99.99.102) 10.168 ms
10 r-rm268-vl14.opb.interbusiness.it (80.21.4.44) 10.776 ms
11 host78-44-static.190-82-b.business.telecomitalia.it (82.190.44.78) 10.948 ms
12 *
13 *

Andiamo male: un firewall sta bloccando i nostri pacchetti ICMP. Potremmo provare ad utilizzare pacchetti UDP, come è di default per traceroute su Unix, ma a questo punto è forse più utile usare tcptraceroute. Il trucco sta nell’effettuare un traceroute con pacchetti TCP destinati alla porta 80, che è sicuramente aperta (perché il sito è navigabile) e difficilmente sarà bloccata da qualche firewall nel mezzo. Ecco infatti il risultato da un altro punto di partenza:

$ sudo tcptraceroute -p 80 80.72.160.111
Tracing the path to 80.72.160.111 on TCP port 80 (www), 30 hops max
[...]
12 tr2-G7-0.RM2.albacom.net (213.255.9.66) 95.053 ms 93.926 ms 95.061 ms
13 ac1-G1-0.RM2.albacom.net (213.255.9.69) 95.928 ms 94.175 ms 93.808 ms
14 217.220.74.22 98.066 ms 97.959 ms 95.934 ms
15 mrhide02.alitalia.it (80.72.160.52) 95.179 ms 95.046 ms *
16 80.72.160.111 [open] 100.912 ms * *

Gli ultimi due hop ci fanno immaginare che 80.72.160.x sia una intera sottorete appartenente ad un unico amministratore. Possiamo verificarlo con un semplice whois:

$ whois 80.72.160.52
[...]
inetnum: 80.72.160.0 - 80.72.160.255
netname: ALITALIA
descr: Alitalia Linee Aeree Italiane S.p.A.
Italian national airline
[...]

Abbiamo fatto centro. L’ultimo hop prima di entrare nella rete Alitalia appartiene a:

$ whois 217.220.74.22
[...]
route: 217.220.0.0/15
descr: BT Italia (formerly Albacom)
[...]

Che è sicuramente il provider. Ecco però una cosa interessante:

$ whois 217.220.74.22
[...]
inetnum: 217.220.74.20 - 217.220.74.23
netname: ABCU2
descr: ALITALIA SERVIZI S.P.A.
[...]

Il range di indirizzi 217.220.74.20-23 è stato dedicato da Albacom espressamente al cliente Alitalia. Incidentalmente notiamo che 217.220.74.20/30 è una subnetwork contenente solo 2 indirizzi usabili, motivo per il quale viene di solito usata per i collegamenti punto-punto. Questo ci fa supporre che la rete 217.220.74.x sia usata da Albacom per i link di routing interno. Vediamo di provare questa teoria: 212.220.74.221 dovrebbe a questo punto essere l’interfaccia di uscita del router all’hop 13, ossia ac1-G1-0.RM2.albacom.net:

$ sudo traceroute -n -w 15 -q 3 217.220.74.21
traceroute to 217.220.74.21 (217.220.74.21), 30 hops max, 40 byte packets
[...]
12 213.242.65.138 125.699 ms * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 213.255.9.5 98.003 ms * *

Il router che ci ha fornito l’ultima risposta dovrebbe quindi essere quello cercato. Controlliamo con una semplice query al DNS:

$ host 213.255.9.5
5.9.255.213.in-addr.arpa domain name pointer ac1-G10-0.RM2.albacom.net.

Bingo! Abbiamo fatto centro! A questo punto possiamo disegnare un rozzo diagramma di rete ed avere una visione più chiara di quello che è successo.

rete alitalia

Quando un router risponde ai ping o, come nel caso di traceroute, genera un pacchetto ICMP di tipo TTL expired, l’indirizzo IP sorgente è generalmente quello dell’interfaccia di uscita. Quando tentiamo di raggiungere direttamente la rete Alitalia, come nel primo traceroute, il routing interno Albacom ci indirizza verso l’interfaccia con IP 213.255.9.69; nel secondo caso invece ha avuto un instradamento diverso. Si spiega così il diverso risultato che abbiamo ottenuto nei due trace. Per fortuna è bastata una query al DNS per riconoscere nei due differenti indirizzi IP lo stesso router.

Possiamo dire ormai di conoscere abbastanza bene l’infrastruttura di rete che ci ha portati ad Alitalia. Se abbiamo ragione quindi, le altre sottoreti di quel range dovrebbero appartenere ad altri clienti Albacom. Il trucco è semplice, basta procedere a gruppi di 4 (poiché /30 ci lascia con 2 bit per il campo host, e 2^2=4). Otterremo 217.220.74.0/30, 217.220.74.4/30, 217.220.74.8/30 e così via. Siamo fortunati al sesto tentativo:

$ whois 217.220.74.29
[...]
inetnum: 217.220.74.28 - 217.220.74.31
netname: AFOP
descr: FOX INTERNATIONAL CHANNELS ITALIA
[...]

che ci svela il nome di un altro cliente Albacom. Lascio ai lettori il piacere di scoprirne altri.

Uno sguardo dentro Internet

Per concludere, ecco un altro metodo per reperire informazioni su una certa rete, ancora più emozionante: daremo direttamente uno sguardo alla tabella di routing di Internet stessa. Colleghiamoci via telnet a route-views.routeviews.org e digitiamo:

route-views.oregon-ix.net>sh ip bgp 80.72.160.111
BGP routing table entry for 80.72.160.0/20, version 12941712
Paths: (40 available, best #32, table Default-IP-Routing-Table)
Not advertised to any peer
3333 6762 3269 20819
193.0.0.56 from 193.0.0.56 (193.0.0.56)
Origin IGP, localpref 100, valid, external
[...]

Le informazioni fornite sono molte: in particolare il percorso n.32 è quello che fornisce la migliore rotta verso la destinazione: 

  3356 8968 20819
4.68.1.166 from 4.68.1.166 (4.68.1.166)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: 3356:2 3356:22 3356:100 3356:123 3356:505 3356:2074

I primi tre numeri rappresentano l’AS-PATH, l’attributo BGP che indica gli AS da attraversare per raggiungere la rete in questione. Significa che, partendo dalla rete appartenente a routeviews.org, attraverseremo altri 2 provider prima di raggiungere la destinazione. La lista di AS è da leggersi da destra verso sinistra, con il primo numero che rappresenta l’AS di partenza e l’ultimo l’AS di arrivo. Interrogando il database ARIN o RIPE dovremmo poter risalire al nome dei provider: ad esempio, senza nessuna sorpresa l’AS number 20819 è assegnato ad Alitalia. L’AS number 3356 appartiene invece a Level3 negli Stati Uniti, nostro punto di partenza. La rete nel mezzo, AS 8968, è invece senza soprese Albacom. Come vediamo, Level3 è collegato direttamente con Albacom Italia, nonostante si tratti di un link intercontinentale; questa è una pratica frequente per i grossi Service Provider, che tentano di creare il maggior numero possibile di adiacenze per minimizzare l’attraversamento del traffico all’interno delle proprie infrastrutture. Ciò rafforza anche la nostra convinzione di quanto dicevamo prima, ossia che è raro impiegare più di tre o quattro AS-HOP per raggiungere una destinazione, anche a distanze internazionali.

Comments

  1. Wow, alla faccia dell’oscuramento delle informazioni…

    Mi piacciono sempre di più i vostri articoli, è un misto di cultura informatica e cultura geek che mi affascina.

  2. unwiredbrain says:

    maelstrom +1

  3. vai cosi.. hardcore! troppo rilassante leggervi 🙂 e quando siete squisitamente tecnici apro anch’io la mia shell.. saluti dall islanda!

  4. Per chi usa Mac OS X, tcptraceroute può essere installato tramite macports:

    sudo port install tcptraceroute

  5. Grazie dell’articolo!

  6. Niente da dire, siete “appassionanti”!

  7. spettacolo! gran bell’articolo!

  8. Luca Russo says:

    Ehehe ottimo articolo, come sempre!!
    Ho gia’ distribuito il link a questo sito a un po’ di persone 🙂

    Complimenti!!!

Policy per i commenti: Apprezzo moltissimo i vostri commenti, critiche incluse. Per evitare spam e troll, e far rimanere il discorso civile, i commenti sono moderati e prontamente approvati poco dopo il loro invio.