Analisi dell'architettura WEB del sito www.facebook.com - Caruso, Flamini, Giammusso, Rossi
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Analisi dell'architettura WEB
del sito www.facebook.com
Caruso, Flamini, Giammusso, Rossi
Strumenti Uso dello strumento whois per analizzare il range di indirizzi ip pubblici utilizzati e l'autonomous system di appartenenza. Cattura e studio dei pacchetti scambiati tra client e server(s) attraverso lo sniffer Wireshark. • Uso dei servizi del sito www.robtex.com per apprendere informazioni sull'autonomous system. Uso dei servizi del sito www.ip2location.com per localizzare i server CDN del sito. Uso dello strumento dig (Domain Information Groper) per interrogare i name servers e per reperire informazioni circa la distribuzione del sito. Analisi dei cookies. Uso di alcuni addons per Firefox per facilitare l'analisi (pulizia e disabilitazione della cache, visualizzazione cookies, ecc.), per testare il sito con diverse impostazioni Locale e per visualizzare le richieste HTTP. Addons di Firefox: FireBug + FireCookie; ShowIp; Web Developer; Live HTTP HEADERS; Quick Locale Switcher.
Whois facebook? Le presentazioni sono sempre il primo passo. Whois facebook.com? Utilizzando lo strumento whois è stato possibile reperire utili ed interessanti informazioni, rappresentate qui a lato. Oltre le informazioni che esulano dall'analisi tecnica, quali la localizzazione fisica dell'organizzazione Thefacebook.com, ce ne sono altre due che riscuotono un elevato grado d'interesse: Possiamo vedere subito il range di ip pubblici utilizzati da facebook, sintetizzati nel prefisso 69.63.176.0/20 attraverso la tecnica CIDR. L'autonomous system di appartenenza risulta essere l'AS32934. Facendo un'ulteriore analisi e utilizzando i servizi offerti da www.robtex.com, possiamo affermare che l'insieme delle macchine targate facebook operino in un autonomous system tutto loro.
Wireshark → HTTP REDIRECTION
Il secondo passo dell'analisi è
stato quello di catturare i
pacchetti scambiati tra il
client e il server, utilizzando
Wireshark. A questo scopo è
stato utile disabilitare la fase
di caching per riuscire a
catturare tutte le richieste
DNS. Lo screenshot qui a lato
mostra i primi pacchetti
ricevuti. Si noti la presenza di
una HTTP REDIRECT.
Pacchetti 1-6: richiesta DNS per il nome www.facebook.com (risposta: 69.63.184.11).
Pacchetti 7-9: Primo HIT sull'ip 69.63.184.11 → apertura connessione TCP.
Pacchetto 12: HTTP REDIRECT ↔ HTTP/1.1 302 Found.
Il campo Location mostra dove verrà effettuato il redirect.
In questo caso viene utilizzato l'alias it-it.facebook.com per il CNAME www.facebook.com.
Analisi dei GET HTTP →
Utilità della Http Redirect
Analizzando più approfonditamente questo aspetto, ci
si accorge di come il redirect http venga utilizzato per
l'internazionalizzazione del sito. Per dimostrare
questa ipotesi è stato eseguito il seguente test che ha
portato ai risultati rappresentati qui a fianco:
GET HTTP da telnet. Senza informazioni addizionali. I. Reset dei cookies.
II. Impostazione Locale settata a it-IT.
III. Richiesta di www.facebook.com.
IV. Reset dei cookies.
V. Impostazione Locale settata su de-DE.
VI. Richiesta di www.facebook.com.
VII. GET HTTP utilizzando telnet.
Impostazione Locale del Browser:
I risultati dimostrano che, durante il primo GET, la
logica del sito viene a conoscenza dell'impostazione
Locale e dipendentemente da questa, definisce una
redirect http impostando nel campo Location la giusta
URL necessaria per la corretta traduzione del sito.
Dopo, attraverso il server Akamai (prossima
diapositiva) static.ak.fbcdn.net, verrà scaricato il
Impostazione Locale del Browser:
dizionario delle frasi corrispondente alla lingua
impostata.
Wireshark → CDN
Procedendo con l'analisi dei pacchetti catturati, è stata notata la comunicazione con delle macchine
aventi indirizzi ip non appartenenti al prefisso 69.63.176.0/20 di facebook. Qui di seguito viene
riportata una sintesi delle richieste DNS per tali macchine:
Query Query Response
static.ak.fbcdn.net CNAME static.ak.facebook.com.edgesuite.net CNAME a749.g.akamai.net A 79.140.80.24 [...]
profile.ak.fbcdn.net CNAME profile.ak.facebook.com.edgesuite.net CNAME a1725.l.akamai.net A 63.217.8.136 [...]
photos-c.ak.fbcdn.net Standard query response CNAME photos-c.ak.facebook.com.edgesuite.net CNAME
a997.mm1.akamai.net A 62.41.85.90 [...]
photos-b.ll.facebook.com Standard query response CNAME facebook.vo.llnwd.net A 208.111.128.6 [...]
vthumb.ak.facebook.com CNAME vthumb.facebook.com.edgesuite.net CNAME a591.da2.akamai.net A 77.67.2.74 [...]
creative.ak.facebook.com CNAME creative.ak.facebook.com.edgesuite.net CNAME a75.g.akamai.net A 79.140.80.48 [...]
Altre queries con pattern: Risposte con pattern:
*.ak.fbcdn.net *.facebook.com.edgesuite.net
*.ak.facebook.com Ogni risposta differisce per i numeri ip e per il numero cliente AKAMAI.
I risultati dimostrano come facebook faccia un largo uso di server CDN per la gestione della reperibilità dei
contenuti. I contenuti reperibili attraverso server CDN sono di vario di tipo: foto, thumbs, e script (ad
esempio da static.ak.fbcdn.net vengono scaricati gli script per l'internazionalizzazione del sito). Con
un'analisi un po' più accurata è stato possibile definire quali società CDN offrissero il proprio servizio a
facebook: Akamai e Limelight Networks. La prossima diapositiva invece, ha lo scopo di mostrare la
locazione fisica dei server CDN, riguardo sempre ai pacchetti sniffati presi in analisi.
NB: le scritte in rosso fanno riferimento ai codici che Akamai utilizza per identificare i clienti.
Ip2location.com Allo scopo di avere una maggiore chiarezza sulla disposizione dei server CDN utilizzati, si è scelto di utilizzare i servizi offerti dal sito www.ip2location.com. Di seguito sono riportati i risultati ottenuti. N.B.: Le locazioni sono relativa ad una session proveniente dall'Italia. creative.ak.fbcdn.net static.ak.fbcdn.net profile.ak.fbcdn.net photos-c.ak.fbcdn.net photos-b.ll.facebook.com vthumb.ak.facebook.com
Esempio CDN → a749.g.akamai.net
IP Location
144.135.8.184 AUSTRALIA
148.243.241.230 MESSICO
196.33.166.201 SUD AFRICA
72.247.242.88 USA
Questo esempio mostra varie interrogazioni DNS per a749.g.akamai.net, effettuate a
name server in diverse località. I risultati mostrano come le risposte contengano
indirizzi ip appartenenti alla nazione del name server e non al dominio di
facebook.com. I risultati sono stati ottenuti grazie allo strumento DIG e ai servizi di
www.ip2location.com.
DIG → Distribuzione Globale
Nella terza fase dell'analisi si è usato dig per investigare sulla
distribuzione del sito. Qui a fianco è rappresentata la funzione
principale dello script bash servito per automatizzare il processo
di 10 queries dns distanziate di un minuto, eseguite su 6 name
servers diversi, ciascuno dei quali posizionato in una nazione
diversa. La seconda immagine mostra l'output dello script per
soli due name servers, visto che vegono riscontrati solamente
questi due comportamenti in tutto il processo.
Risultati Deduzioni
Presenza di più ip nella risoluzione dns Distribuzione
dell'hostname. Globale
Le richieste dns provenienti da Presenza di un
Australia, Afghanistan e USA hanno primo livello di
come risposta degli ip compresi in scheduling
69.63.176.0/24 oppure compresi in DNS basato
69.63.180.0/24. sulla nazione di
Le richieste dns provenienti da Brasile, provenienza
Sud Africa, Messico, Italia, Germania e della richiesta.
Colombia, hanno come risposta degli ip
compresi in 69.63.184.0/24.Analisi dei Cookies →
WEB Cluster Distribuiti
La quarta e ultima fase dell'investigazione è stata volta
all'analisi dei cookies. Questo step è stato di fondamentale
importanza per riuscire a comprendere il tipo di
distribuzione globale e, in caso di cluster distribuiti, la
presenza di web switch e il livello di questi.
Tra i vari cookies analizzati, ne esiste uno di particolare rilevanza: BIGipServer[poolname] (in figura sopra).
BIGipServer[poolname] è un cookie che prova la presenza di prodotti della famiglia BIG-IP appartenenti
all'azienda f5 (http://www.f5.com). Questi prodotti sono utilizzati per praticare web switching basati su vari tipi
di scheduling, in particolare, l'uso di questo cookie viene spesso utilizzato quando si utilizza il product module
LTM (Local Transfer Manager) di f5.
Obiettivo di LTM → Load Balancing in un web cluster.
Risultati Deduzioni
Presenza di LTM ed esistenza di vari Architettura WEB basata su web cluster
ip (diapositive precedenti). distribuiti.
Presenza di BigipServer[poolname] Presenza di un web switch content-aware
nei cookies. di livello 7.Riepilogo
facebook.com
HTTP
69.63.176.0/20 Internazionalizzazione
REDIRECTION
AS32934
CDN DNS Scheduling
Distribuzione Akamai Nazione
Globale LimeLight Networks di provenienza
F5 BIG-IP
Web Cluster Cookies
LTM
Distribuiti L7 Web Switches
Load BalancingPuoi anche leggere
