Analisi della robustezza architetturale a livello routing e dns in servizi web di interesse pubblico: studio in varie nazioni

UNIVERSITÀ DEGLI STUDI DI TRIESTE
Dipartimento di Ingegneria e Architettura
Corso di Laurea in Ingegneria Elettronica e Informatica
Curricula Applicazioni Informatiche
Tesi di Laurea Triennale
Analisi della robustezza architetturale a livello routing e DNS in
servizi web di interesse pubblico: Studio in varie nazioni
Relatore:
Chiar.mo Prof. Alberto Bartoli
Laureando:
Marco Brotto
Matricola: IN0500291
Sessione di Laurea Estiva
Appello di luglio
Anno accademico 2018-2019

ii
Introduzione
Tutti i giorni le persone usufruiscono di servizi web legati alla Pubblica Amministrazione (come agenzie fiscali, banche,
università). Lo scopo di questa tesi è studiare facendo opportune analisi la robustezza architetturale a livello routing e dns di tali
servizi web. Il loro corretto funzionamento dipende da molti aspetti della rete. Ad esempio, per ogni sito web che si visita
implicitamente si entra in contatto (in modo diretto o indiretto) con altri nodi della rete quali ad esempio Name Server, Mail
Server e Autonomous System.
L’obbiettivo di questa tesi è, a partire da siti web e domini mail relativi alla Pubblica Amministrazione italiana, tedesca, inglese
e americana, raccogliere tutti i dati necessari per capire come ognuno di essi (siti web e domini mail) interagisce con i nodi della
rete elencati nel paragrafo precedente, e quali sono i punti critici (nodi da cui dipendono altri nodi).
Ad esempio, un name server che gestisce zone di cui fanno parte molti Web Server è un nodo critico per l’infrastruttura che si
vuole costruire in quanto da esso dipende il corretto funzionamento di molti servizi web. Una considerazione analoga si può
fare per gli Autonomous System, autorità amministrative che gestiscono il traffico a livello di rete per un certo numero di nodi
che hanno un determinato indirizzo IP (Autonomous system (Internet), 2019). Un Autonomous System che gestisce il
traffico per molti nodi è anch’esso un punto critico dell’infrastruttura.
Il lavoro è stato svolto nell’Università degli Studi di Trieste, in particolare per gran parte delle ore nel laboratorio informatico
Machine Learning. Le conoscenze acquisite per svolgere questo progetto sono da attribuirsi principalmente al corso Reti di
Calcolatori I (Bartoli A. , 2018).
Il lavoro svolto ha seguito questi passi:
I) Studio della letteratura: è stata fatta un’analisi preliminare per capire quali nodi della rete occorresse conoscere per
realizzare il progetto.
II) Progettazione della raccolta dati: sono stati implementati gli algoritmi per raccogliere i dati necessari. La
progettazione per la raccolta dati è stata divisa in più fasi.
III) Ricerca dei web server e mail domain: questi sono i nodi da cui parte la ricerca, molti di essi sono stati reperiti da
dateset online, altri sono stati prelevati da siti web con una tecnica di web scraping.
IV) Implementazione dei moduli software per realizzare in modo automatizzato la raccolta dati descritta nelle fasi
della progettazione.
V) Raccolta dati: i dati sono stati raccolti e salvati su fogli di calcolo online.
VI) Analisi dei risultati: a partire dai dati raccolti sono state fatte semplici analisi a livello routing e dns.
I moduli software realizzati durante il progetto sono stati scritti in Python (versione 3.7.2.) L’ambiente di sviluppo utilizzato è
stato PyCharm. I dati, una volta raccolti, sono stati salvati su fogli di calcolo Google, in modo da poterli condividere con altri
utenti.
Questa tesi è strutturata nel seguente modo: nella parte di Analisi e progettazione si elencano i nodi che si vogliono conoscere
ai fini di realizzare un grafo (teorico in questa tesi) che evidenzi le dipendenze fra i nodi e i punti critici della rete. Segue la parte
di Raccolta dei Web Server e Mail Domain in cui si reperiscono tali nodi. In realizzazione si descrive come utilizzare i moduli
software progettati (interfaccia) e come funzionano internamente (implementazione). Infine, nella parte conclusiva si riassume
che dati sono stati raccolti e si mostrano dei grafici che esprimono dipendenze e criticità di alcuni nodi dell’infrastruttura
costruita.

iii
Indice
Introduzioneii
Parte I Analisi e Progettazione1
Capitolo 1 Analisi e Requisiti2
1.1 Indice dei nodi del grafo2
1.2 Dipendenze tra i nodi3
1.3 Criticità di un nodo del grafo4
Capitolo 2 Progettazione della raccolta dati6
2.1 Fase 1 - raccolta Web Server e Mail Domain della Pubblica Amministrazione7
2.2 Fase 2.1 - verifica del protocollo http o https7
2.3 Fase 2.2 - da Mail Domain ricavare il Mail Server11
2.4 Fase 3 - raccolta dati a livello DNS: Name Server e Zone12
2.5 Fase 4 - raccolta dati a livello di rete: IP, ASN e Owner ASN17
Parte II Ricerca dei Web Server e Mail Domain20
Capitolo 3 Reperimento dei Web Server e Mail Domain22
3.1 Implementazione degli script in Python23
Parte III Realizzazione: interfaccia e implementazione26
Capitolo 4 Interfaccia per la raccolta dati27
4.1 Interfaccia: Script “requestHttp/https”27
4.2 Interfaccia: Script “fromMDgetMS”28
4.3 Interfaccia: Script “fromHNGetZN&NS”28
4.4 Interfaccia: Script “fromHNGetIP&ASN”28
Capitolo 5 Implementazione della raccolta dati29
5.1 Implementazione: Script “requestHttp/https”29
5.2 Implementazione: Script “fromMDgetMS”30
5.3 Implementazione: Script “fromHNGetZN&NS”31
5.4 Implementazione: Script “fromHNGetIP&ASN”32
5.5 Considerazioni generali33
Parte IV Osservazioni e Conclusioni36
Capitolo 6 Raccolta dati e Risultati raggiunti38

iv
6.1 Riassunto raccolta dati38
6.2 Analisi dei risultati39
Capitolo 7 Prossimamente49
7.1 Sviluppi futuri49
Considerazioni personali51
Bibliografia e strumenti utilizzati1
Ringraziamenti1

Parte I
Analisi e Progettazione

pag. 2
1
Analisi e Requisiti
Questo capitolo parla di quali informazioni si vogliono raccogliere ai fini di questo progetto.
Poiché si vuole analizzare la robustezza architetturale a livello routing e dns in servizi web di interesse
pubblico, è necessario conoscere siti web e domini mail che offrono tali servizi. Lo studio è fatto su servizi
web offerti da quattro nazioni diverse:
 Italia
 Germania
 Inghilterra
 Stati Uniti d’America
Si è scelto di descrivere l’infrastruttura come un grafo. I nodi del grafo sono:
1) Web Server (WS)
2) Mail Domain (MD)
3) Mail Server (MS)
4) Name Server (NS)
5) DNS Zone (ZN)
6) Network Number di lunghezza 24 (IP)
7) Autonomous System (AS)
I diversi nodi sono connessi fra di loro mediante un arco orientato. Il criterio secondo cui un nodo X punta verso
un nodo Y è il seguente: Y è necessario per il corretto funzionamento di X. Ad esempio un nodo di tipo ZN punterà
sempre verso un nodo di tipo NS dal momento che il corretto funzionamento di una zona è direttamente legato
ai name server che la gestiscono.
1.1 Indice dei nodi del grafo
La tabella seguente riporta gli acronimi dei nodi del grafo, specifica come un nodo viene identificato e quali sono
i suoi attributi.
Nodo Identificatore nodo Attributi
Web server (WS) Nome di dominio
Tipo di protocollo applicativo utilizzato per la pagina
web: http/https
Indirizzo IP
Mail Domain (MD) Nome di dominio -
Mail Server (MS) Nome di dominio Indirizzo IP
Name Server (NS) Nome di dominio Indirizzo IP
Zona (ZN) Nome di zona -
Network Number /24
(IP)
Network number/24 -

pag. 3
Autonomous System
(AS)
Autonomous System
Number
Organizzazione che gestisce tale AS
Tabella 1: nodi del grafo
1.2 Dipendenze tra i nodi
I nodi si connettono fra di loro attraverso degli archi orientati come specificato nel paragrafo “Analisi e Requisiti”.
Non tutti i tipi di nodi possono collegarsi direttamente, ad esempio un nodo di tipo ZN non è collegato
direttamente ad un nodo di tipo AS.
La Tabella 2 elenca quali sono le dipendenze che sussistono fra i tipi di nodi. Le seguenti dipendenze si basano sul
tipo di nodo non sui valori che esso assume.
Nodo X Nodo Y
Nodo X - tipo Nodo Y – tipo
WS ZN, IP
MD MS, ZN, IP
MS ZN, IP
NS ZN, IP
ZN NS, ZN
IP AS
AS -
Tabella 2: dipendenza fra i nodi del grafo
Dalla Tabella 2 si possono fare le seguenti osservazioni:
1) I nodi WS e MS non sono influenti sul corretto funzionamento di nessun tipo di nodo;
2) I nodi AS non dipendono da nessun tipo di nodo;
3) L’unico nodo che dipende da un nodo dello stesso tipo è ZN, ad esempio una zona che sul domain tree si
trova al terzo livello dipende direttamente dalla zona soprastante che può essere un Top Level Domain
oppure un Second Level Domain.
Ci sono alcune dipendenze che non si considerano nel progetto:
1) Dipendenza doppia fra due nodi ZN e NS: se un name server gestisce la zona a cui esso appartiene allora
non si considera la dipendenza che ha tale name server dalla zona.
NS
ns1.dnsitalia.it
ZN
dnsitalia.it
Immagine 1: ns1.dnsitalia.it non dipende da dnsitalia.it

pag. 4
2) Un nodo ZN che rappresenta un TLD non dipende da alcun nodo; con questa considerazione si può
affermare che un nodo ZN TLD e un AS sono le foglie del grafo.
1.3 Criticità di un nodo del grafo
È stata scelta la struttura del grafo perché rappresenta bene il concetto di criticità di un nodo: poiché l’arco
orientato da un nodo Y verso un nodo X indica che X è strettamente necessario per il corretto funzionamento di Y,
allora se X viene manomesso, sicuramente anche Y ne risentirà e non potrà più funzionare correttamente.
WS
www.difesa.it
ZN
difesa.it
NS
dns1.difesa.it
NS
dns.difesa.it
IP
78.4.240.0/24
AS
BT-ITALIA, IT
Immagine 2
Si supponga che un hacker voglia prendere controllo del sito www.difesa.it. Per quanto visto nella Tabella 2,
l’attaccante potrebbe colpire:
1) Direttamente il WS;
2) I nodi che influenzano direttamente il nodo WS, ossia IP e ZN;
3) I nodi che influenzano direttamente i nodi del punto 2, ossia AS e NS.
In questo particolare caso si osservi che il nodo IP è molto critico, infatti, se un attaccante riuscisse a controllare
tale nodo, avrebbe il controllo praticamente su tutto il grafo.
Immagine 3: il controllo del nodo IP provoca il controllo di quasi tutto il grafo

pag. 5
Dall’Immagine 3 si può osservare che l’attaccante ha controllo:
1) Diretto sul nodo IP in quanto è la fonte dell’attacco;
2) Diretto sui nodi WS, NS (arancioni) in quanto sono direttamente dipendenti dal nodo attaccato;
3) Indiretto sul nodo ZN (in giallo).
Si può concludere che la criticità di un nodo dipende principalmente1 dal numero di archi entranti verso esso.
Ai fini di analizzare la robustezza architetturale a livello routing e dns in servizi web della Pubblica Amministrazione
è necessario raccogliere le informazioni descritte nella “Tabella 1”. Tali dati permettono di studiare la criticità dei
nodi secondo i criteri descritti nella “Tabella 2”.
1 “Principalmente” perché non è l’unica fonte di criticità di un nodo, infatti il nodo AS dell’Immagine
sebbene abbia un solo arco entrante è tanto critico quanto il nodo IP.

pag. 6
2
Progettazione della raccolta dati
In questo capitolo si illustra come devono essere raccolti i dati descritti nella Tabella 1 (pag. 3).
Tale attività è stata divisa in fasi, poiché in alcuni casi per raccogliere certe informazioni è necessario esserne in
possesso di altre.
Immagine 4: fasi della ricerca dei dati2
Per trovare tutte le informazioni volute si deve procedere in ordine seguendo le fasi indicate nell’Immagine 4. Le
frecce uscenti da una fase i ed entranti in una fase j indicano che le informazioni raccolte nella fase i sono
necessarie per il completamento della fase j.
Si osservi che nella fase 3 è presente una freccia ricorsiva, infatti quando si trova un name server che gestisce una
zona di un WS, MS o MD, si vuole conoscere anche la zona a cui esso appartiene e i name server che la gestiscono.
2 Nell’immagine quando si scrive “Trovare MS” si intende trovare l’identificatore del nodo MS, quindi in
questo caso, trovare il suo nome di dominio

pag. 7
2.1 Fase 1 - raccolta Web Server e Mail Domain della Pubblica
Amministrazione
I primi dati che devono essere raccolti sono i siti web di interesse pubblico e i domini mail di tali organizzazioni,
dal momento che a partire da questi si riescono a ricavare tutte le informazioni descritte nella Tabella 1 (pag. 3).
I domini mail sono stati raccolti per le sole organizzazioni della Pubblica Amministrazione italiana, mentre i siti
web per tutti e quattro gli Stati (vedi “Gestione dei dataset online” pag. 39). Inoltre, i servizi web associati ad enti
italiani sono stati categorizzati secondo la loro funzione. In generale in questo progetto si raccolgono dati per
poter fare due analisi parallele:
1) Solo su siti italiani divisi per categoria,
2) Su siti tedeschi, italiani (indistintamente dalla categoria), inglesi e americani.
Germania Italia Inghilterra Stati Uniti d’America
Generale
Agenzie Fiscali
Generale Generale
Agenzie Regioni Lavoro, Agricoltura e Ambiente
Banche
Camere di Commercio
Certification Authorities italiane
Città Metropolitane
Comuni
Fornitori energie elettrica e gas
Istituti di Istruzione Statale di Ogni Ordine e
Grado
Pec Provider
Presidenza Del Consiglio dei ministri
Sanità
Spid Identity Provider
Spid Service Provider
Università
Tabella 3: categorizzazione di servizi web suddivisi per nazioni
Per ogni url o mail domain raccolto si memorizza una breve descrizione.
2.2 Fase 2.1 - verifica del protocollo http o https
In questa fase si vuole studiare una metodologia per sapere se le pagine web relative agli url raccolti in
precedenza utilizzano protocollo applicativo http o https. La scelta di quale protocollo utilizzino non è esclusiva,
infatti possono manifestarsi diversi casi, la pagina web può essere disponibile:
1) Esclusivamente con protocollo http;
2) Esclusivamente con protocollo https;

pag. 8
3) Con entrambi i protocolli in maniera autonoma3;
4) Su https con redirection da http;
5) Su http con redirection da https.
Per conoscere tali informazioni è necessario analizzare la risposta http a fronte di una richiesta per un determinato
url.
Le parti che interessano della risposta http sono essenzialmente due:
1) Lo status code che indica l’esito della risposta,
2) (Se presente) L’header Location che indica dove il sito viene reindirizzato.
In fase di implementazione sono stati utilizzati altri header per agevolare e rendere più efficiente la ricerca (ad
esempio in fase di richiesta l’header User-Agent).
Per avere una conoscenza completa su quale protocollo applicativo utilizzi una certa pagina web, per ogni indirizzo
uri si devono effettuare due richieste diverse:
1) GET HTTP://www.moliselavoro.it
2) GET HTTPS://www.moliselavoro.it
Le risposte che si ricevono a fronte di richieste di tipo 1) e 2) possono avere sostanzialmente 3 esiti diversi (finali,
non considerando le redirection):
1) Indirizzo finale è su http
2) Indirizzo finale è su https
3) Risposta negativa a fronte di una richiesta non valida (ad esempio il sito web è solo su http e la richiesta
è stata fatta su https)
ESEMPIO 1
Si vogliono ricavare le informazioni desiderate dall’indirizzo uri www.moliselavoro.it/.
Immagine 5: 2 transazioni http tra il browser e un web server. La pagina web richiesta viaggia in maniera distinta sia su http che su
https
3 Con il termini “autonoma” si intende che la pagina web esiste in maniera indipendente sia in versione
http che in versione https

pag. 9
La pagina web richiesta ha due indirizzi url distinti che differiscono solo per la prima parte, ossia il protocollo applicativo.
ESEMPIO 2
Si vogliono ricavare le informazioni desiderate dall’indirizzo www.agenziedoganemonopoli.it. Procedendo come
nell’Esempio si ha:
Immagine 6: simulazione di una transazione http tra il browser e due web server, in questo caso si nota una redirection da http a
https
Si possono trarre le seguenti conclusioni:
1) Ci sono state due redirection di cui una (la seconda) coinvolge un nome di dominio diverso da quello originale4
;
2) Il protocollo applicativo su cui viaggiano le informazioni è http e https, in particolare a fronte di una richiesta
http per l’indirizzo url originale si riceve come risposta una redirection verso un indirizzo che ha lo stesso
dominio di quello originale ma protocollo applicativo https (non più http).
4 I domini www.agenziedoganemonopoli.it e www.adm.it sebbene sono diversi potrebbero riferirsi allo
stesso web server fisico, tuttavia per non ledere le generalità si è scelto nell’immagine di trattarli come due server
distinti.

pag. 10
2.2.1 Workflow per la raccolta dati
Descritto quali informazioni si vogliono raccogliere, viene riportato il workflow di come si vuole strutturare
l’attività di ricerca.
INIZIO
Indirizzo uri
Richiesta http/https
Presenti
Redirection?
Sito web
trovato?
No
Risposta http/https = Err
Risposta http/https =
http/https
Sì
Se la pagina web
finale mostra sulla
barra degli indirizzi
http allora la risposta
sarà http
FINE
Seguire tutte le
redirection
Sì
No
Immagine 7: workflow per la ricerca del protocollo http/https di pagine web
Tale organizzazione permette di capire se una pagina web utilizza protocollo http/https; ad esempio se un sito
web ha solo la pagina in versione http, allora si riceveranno le seguenti risposte:
1) Risposta http = http
2) Risposta https = Err

pag. 11
2.3 Fase 2.2 - da Mail Domain ricavare il Mail Server
A partire da un mail domain (trovato in “”) si vogliono trovare i rispettivi Mail Server. Una strategia possibile per
compiere tale attività è quella di interrogare il dns effettuando delle richieste di tipo MX.
ESEMPIO 3
Si vuole trovare il mail server del dominio emarche.it.
Immagine 8: richiesta e risposta al dns di tipo MX
Il workflow per questa fase è semplicemente: dato un mail domain effettuare una richiesta al dns di tipo MX per
ricavare i rispettivi mail server.

pag. 12
2.4 Fase 3 - raccolta dati a livello DNS: Name Server e Zone
Per ogni host name (Web Server, Mail Domain e Mail Server) trovato nella (pag. 7) e nella (pag. 11) si vuole
ricavare:
1) La zona a cui tale nome di dominio appartiene;
2) I nomi dei name server che gestiscono tale zona;
3) Le zone dei name server trovati al punto 2;
a. Per ogni zona del punto 3, se è ancora inesplorata5
, trovare i name server che la gestiscono;
b. Zone dei name server del punto 3.a.
Infine, si vuole analizzare anche le zone (“ancora inesplorate”) che sono soprastanti a zone già analizzate, ma non
sono Top Level Domain (vedi pag. 3 “dipendenza diretta tra due zone”).
La ricerca si conclude quando si trovano:
1) name server che gestiscono zone che sono già state trovate in precedenza e quindi già analizzate, oppure
2) zone che sono gestite da name server già analizzati.
Per ogni zona si vuole trovare in maniera distinta il name server primario da quelli secondari.
2.4.1 Strategia per la raccolta dati
La strategia adottata per completare questa attività è quella di interrogare il dns effettuando richieste di tipo NS
(e SOA per trovare il name server primario). Le risposte che si possono ricevere a fronte di tali richieste sono 2:
1) Risposta nulla se il nome di dominio specificato nella richiesta non è un nome di zona;
2) Insieme di Resource Record di tipo NS.
Una risposta del secondo tipo permette di:
a) Capire che il nome di dominio richiesto è un nome di zona;
b) Trovare i name server di tale dominio.
5 Con zona inesplorata si intende una zona che non è stata ancora analizzata, in termini di quali name
server la gestiscono

pag. 13
ESEMPIO 4
Si vogliono conoscere i name server che gestiscono la zona del dominio www.adm.gov.it (Agenzia delle Dogane e dei
Monopoli).
Immagine 9
A priori non si conosce la zona del dominio dunque facendo una richiesta al dns di tipo NS per il dominio
www.adm.gov.it non si ottiene alcuna risposta in quanto la richiesta è fatta su un nome che non è una zona.
 www.adm.gov.it NS ?
 None
Si riprova ad interrogare il dns modificando opportunamente l’host name:
 adm.gov.it NS ?
 adm.gov.it NS ammi1.finanze.it
 adm.gov.it NS ammi2.finanze.it

pag. 14
2.4.2 Workflow della raccolta dati
Viene riportato di seguito il workflow della ricerca per un dominio di tipo WS.
Inizio
WS: Web Server
Trova zona ZN di WS
Name Server NS1 di
ZN
Name Server NS2 di
ZN
Name Server NS3 di
ZN
Name Server NS4 di
ZN
Zona ZN1 di NS1 Zona ZN2 di NS2 Zona ZN3 di NS3 Zona ZN4 di NS4
La zona ZNi è già stata
analizzata?
No, zona ancora inesplorata:
ZN  ZNi
Sì
FINE
La zona soprastante a ZNi è
un TLD O è già stata
analizzata
Sì
No, zona ancora inesplorata:
ZN  UpZone(Zni)
Immagine 10: workflow delle ricerca di zone e name server a partire da un host name
Tale strategia si può adottare per qualsiasi tipo di dominio: web server, mail domain, mail server, name server e
zona.

pag. 15
ESEMPIO 5
Si vogliono trovare zone e name server a partire dal dominio mx.cert.legalmail.it. (tale nome rappresenta un mail
server MS).
Immagine 11
mx.cert.legalmail.it.
MS
legalmail.it
ZN
dns01.infocert.it
NS
dns02.infocert.it
NS
infocert.it
ZN
FINE
I name server di questa zona
sono dns01.infocert.it e
dns02.infocert.it dunque la
ricerca si può fermare

pag. 16
ESEMPIO 6
Si vogliono trovare zone e i name server a partire dal dominio www.regionesardegna.it (tale nome rappresenta un
web server).
Immagine 12
Le frecce nere indicano le dipendenze “nate” a causa della dipendenza fra zone (tra dns.tiscali.it e tiscali.it).
www.regione.sardegna.it
WS
regione.sardegna.it
ZN
protone.dns.tiscali.it
NS
dns02.infocert.it
NS
dns.tiscali.it
ZN
elettrone.dns.tiscali.it
NS
murdock.dns.tiscali.it
NS
barakus.dns.tiscali.it
NS
hannibal.dns.tiscali.it
NS
FINE
tiscali.it
ZN

pag. 17
2.5 Fase 4 - raccolta dati a livello di rete: IP, ASN e Owner ASN
A partire da un Web Server, Mail Server o Name Server si vogliono raccogliere le seguenti informazioni:
1) Indirizzo IP del nodo,
2) Network Number/24 associato all’indirizzo IP trovato,
3) Autonomous System Number,
4) Organizzazione proprietaria dell’Autonomous System.
I dati ai punti 2,3 e 4 non sono reperibili se prima non è stato trovato l’indirizzo (IP).
A partire da un dominio (di tipo WS/MS/NS) per ricavare il suo indirizzo IP si utilizza la strategia di interrogare il
dns effettuando delle richieste di tipo A. Ad esempio:
Immagine 13: interrogazione al dns di tipo A per un mail server
Alle volte, un host name non è associato direttamente a un indirizzo IP, ma è associato ad un altro nome di
dominio. A quest’ultimo, a sua volta, può corrispondere un indirizzo IP oppure un altro host name.
Solo per i Web Server si è deciso di memorizzare ed analizzare (a livello dns6) i nomi di dominio equivalenti, in
particolare solo quelli a cui è associato direttamente l’indirizzo IP.
6 A livello di rete non ha senso distinguere un nome equivalente dall’host name originale poiché fanno
riferimento entrambi allo stesso indirizzo IP.

pag. 18
ESEMPIO 7
Si vuole trovare l’indirizzo IP del dominio www.banca5.com.
Immagine 14: transazioni con due name server per ricavare l’indirizzo IP di www.banca5.com
Si può affermare con certezza che i due domini (www.banca5.com e name1) non appartengono alla stessa zona. I
rispettivi name server potrebbero essere gli stessi, ma in linea di massima non lo si può affermare. Un possibile
scenario potrebbe essere quello esposto nell’ Immagine 15.
Immagine 15: possibile scenario dell’Esempio 7

pag. 19
Si deve analizzare l’host name name1 con la stessa metodologia descritta nel paragrafo “Fase 3 - raccolta dati a
livello DNS: Name Server e Zone”, ossia a partire da questo, si devono ricavare zone e name server.
Il network number di lunghezza 24 si pone a partire dall’indirizzo IP appena trovato. Ad esempio, se si trova
l’indirizzo IP 199.212.0.5 allora il network number associato è 199.212.0.0/247.
Per trovare gli ASN e le organizzazioni proprietarie di tali AS è necessario uno strumento che dato un indirizzo IP
restituisca le informazioni volute.
7
È importante specificare la lunghezza del network number altrimenti si corre il rischio di fornire dati
ambigui. In questo caso infatti se non fosse stata specificata la lunghezza del network number non si poteva più
determinare la sua lunghezza.

pag. 20
2.5.1 Workflow per la raccolta dati
Il workflow seguito per trovare queste informazioni è il seguente.
Immagine 16: workflow della ricerca di IP-address, IP net. number, ASN, Owner-ASN
Host Name
HN
(Se presente)
Indirizzo IP di HN
Network Number 24
dell’indirizzo IP
Preso l’indirizzo IP, si pone il
network number di lunghezza
24
Autonomous System
Number che
gestisce indirizzo IP
ASN
Owner ASN
FINE

pag. 21
Parte II
Ricerca dei Web Server e Mail
Domain

pag. 22
1
Reperimento dei Web Server e Mail Domain
È stato evidenziato nel paragrafo “” (pag. 7) che il primo passo della ricerca per la costruzione del grafo è quello
di trovare i Web Server e Mail Domain.
In questo capitolo si illustra brevemente cosa è stato trovato, dove e come.
Web Server e Mail Domain sono stati ricavati con le stesse metodologie. Esse sono essenzialmente due:
1) Fogli di calcolo già strutturati trovati in Internet;
2) Web Scraping su opportune pagine web.
Vengono riportate due tabelle che riassumono quanti url/uri/host name e mail domain sono stati raccolti, la
fonte dell’origine dati e la metodologia di prelievo.
CATEGORIA LINK ORIGINE DATI METODOLOGIA # WS8 # MD9
Agenzie Fiscali https://www.indicepa.gov.it/documentale/n-
opendata.php
Foglio csv 4 4
Agenzie Regioni Lavoro,
Agricoltura e Ambiente
https://www.indicepa.gov.it/documentale/n-
opendata.php
Foglio csv 51 51
Banche https://www.tuttitalia.it/banche/elenco/ Web Scraping 268 178
Camere di Commercio https://www.indicepa.gov.it/documentale/n-
opendata.php
Foglio csv 111 118
Certification Authorities
italiane
https://webgate.ec.europa.eu/tl-browser/#/tl/IT Web Scraping 34 26
Città Metropolitane https://www.indicepa.gov.it/documentale/n-
opendata.php
Foglio csv 14 14
Comuni https://www.indicepa.gov.it/documentale/n-
opendata.php
Foglio csv 7.792 7.877
Fornitori energie elettrica e
gas
https://www.prezzoenergia.it/portaleOfferte/it/open-
data.page
Foglio xml 298 0
Istituti di Istruzione Statale
di Ogni Ordine e Grado
opendata.php
Foglio csv 7.071 8.608
Pec Provider https://www.indicepa.gov.it/documentale/n-
opendata.php
Foglio csv 19 0
Presidenza Del Consiglio dei
Ministri
opendata.php
Foglio csv 24 23
Sanità https://www.indicepa.gov.it/documentale/n-
opendata.php
Foglio csv 225 225
Spid Identity Provider https://www.spid.gov.it/richiedi-spid A mano 9 0
Spid Service Provider https://www.spid.gov.it/servizi Web Scraping 3.655 0
Università https://www.indicepa.gov.it/documentale/n-
opendata.php
Foglio csv 58 58
TOTALE - - 19.366 17182
8
Con # WS si intende il numero di web server, uri e url.
9 Con # MD si intende il numero di domini mail a partire da un indirizzo mail; i domini mail distinti sono in
numero inferiore

pag. 23
Tabella 4: categorizzazione url della Pubblica Amministrazione italiana
STATO LINK ORIGINE DATI METODOLOGIA # WS Errore. Il
segnalibro non è
definito.
Germania https://github.com/robbi5/german-gov-domains Foglio csv 8.581
Italia Tabella 4 Misto 19.366
Regno Unito https://www.gov.uk/government/organisations Foglio csv 2.692
Stati Uniti d’America https://home.dotgov.gov/data/ Foglio csv 5.104
TOTALE - - 35.743
Tabella 5: categorizzazione url in base ai Paesi
Gli indirizzi url e mail domain che si trovavano su foglio csv già strutturati sono stati semplicemente copiati in un
foglio di calcolo.
Per effettuare il Web Scraping per prelevare url e mail domain presenti in siti web sono stati scritti programmi
script nel linguaggio di programmazione Python.
1.1 Implementazione degli script in Python
Vengono riportati dei frammenti di codice che indicano com’è stato implementato il programma che preleva le
informazioni volute da una certa pagina web.
1. import urllib.request
2. from bs4 import BeautifulSoup
3.
4.
5. ...
6. Url = "https://www.tuttitalia.it/banche/20-aareal-bank-ag/"
7. response = urllib.request.urlopen(Url)
8.
9. pageHTML = BeautifulSoup(response, "html.parser")
Alla righe 1 e 2 sono specificati i moduli necessari (per i nostri scopi) per effettuare la richiesta http (urrlib.request
- (Reitz, 2019)) ed ottenere la pagina html (bs4 - (Richardson, 2019)) .

pag. 24
Immagine 17: esempio di pagina web dove si vuole prelevare informazioni utili (cerchi rossi)
Sito: https://www.tuttitalia.it/banche/20-aareal-bank-ag/
Per prelevare solo ciò che interessa (cerchi rossi), occorre specificare il tag html dove si trova l’informazione voluta
(quadrati rossi).
1. for data in pageHTML.findAll('h1', class_='ev'):
2. descrizioneURL = data.text
3. print(descrizioneURL)
4.
5. >>> Aareal Bank AG
6.
7. for link in data.findAll('a' , class_='bp'):
8. URL_Banca = link.get('href')
9. print(URL_Banca)
10.
11. >>> http://www.aarel-bank.com
Tale approccio di prelievo dati è molto rapido tuttavia presenta per certe pagine web un problema: alcuni
contenuti html possono essere caricati da script Javascript dunque non è possibile visualizzarli nella pagina html
restituita con i comandi sopra riportati.
In certi casi i contenuti di interesse (link e descrizioni) fanno parte della pagina html “originale”, dunque il
problema può essere ignorato; quando non è così, ossia i contenuti di interessi sono caricati da Javascript la
soluzione è quella di utilizzare un browser headless, ossia un browser senza interfaccia grafica utente che tuttavia
permette di caricare le pagine html su cui è stato già eseguito codice Javascript (Selenium WebDriver, 2019)
(Python language bindings for Selenium WebDriver, 2019).

pag. 25
1. from selenium import webdriver
2. ...
3. driver = webdriver.Chrome()
4. driver.get("https://webgate.ec.europa.eu/tl-browser/#/tl/IT/2")
Immagine 18: un altro esempio di pagina web dove si vuole prelevare informazioni utili (cerchi rossi).
Sito: https://webgate.ec.europa.eu/tl-browser/#/tl/IT/2
1. Tag<a> = driver.find_elements_by_xpath("//a[@class = 'a-link-custom ng-binding ng
scope']")
2. Link = Tag<a>.get_attribute('href'))
3. Print(Link)
4.
5.
6. >>> Link = https://portal.actalis.it/Info/qcsp-english
A differenza dell’approccio utilizzato in precedenza, questa volta si possono prelevare le pagine html in versione
“completa”, tuttavia la velocità di prelievo è inferiore quindi i tempi della ricerca aumentano.

pag. 26
Parte III
Realizzazione: interfaccia e
implementazione

pag. 27
1
Interfaccia per la raccolta dati
In questo capitolo si illustrano le interfacce dei principali10 moduli Software implementati durante il progetto
(come si utilizzano).
I Web Server e i mail domain inizialmente raccolti (si veda “Reperimento dei Web Server e Mail Domain” pag. 22)
sono oggetto di un’analisi suddivisa in più fasi come descritto nel capitolo “Progettazione della raccolta dati”
(pag. 6).
Tali domini sono stati inizialmente salvati su fogli di calcolo (con estensione csv)11. Per raccogliere informazioni
quali mail server, name server, zone, ip address, ASN e Owner ASN sono stati scritti dei programmi script.
1.1 Interfaccia: Script “requestHttp/https”
Il programma riceve come input un file12 di testo con un elenco di url/uri/host name.
Ogni riga viene scansionata ed opportunamente analizzata. Il programma fornisce come output un file di testo (di
nome <fileDiInput> + “http”) che associa ad ogni url/uri/host name della lista un particolare attributo; viene
riportato di seguito l’elenco di questi attributi con il loro significato:
1) OP  il sito web è solo su http;
2) PTS  il sito web è su https; se si richiede la stessa pagina con protocollo http, si viene
reindirizzati su https;
3) PS  il sito web esiste in modo distinto sia su http che su https;
4) OS  il sito web è solo su https;
5) STP  il sito web è su http; se si richiede la stessa pagina con protocollo https, si viene
reindirizzati su http;
6) NF  non è stato possibile analizzare il sito web.
10 I programmi script che si sono creati durante il progetto sono molteplici, qua vengono illustrati solo i
principali: quelli che permettono in via definitiva di raccogliere le informazioni volute (dns, IP, zone…).
11
È stato necessario utilizzare più di un foglio di calcolo in quanto gestire tutti i dati (WS e MD) in uno solo
sarebbe diventato troppo confusionario.
12 All’interno del programma va specificato il nome del file.

pag. 28
1.2 Interfaccia: Script “fromMDgetMS”
Il programma riceve in input un file di testoErrore. Il segnalibro non è definito. con l’elenco dei domini mail.
Ogni riga del file viene scansionata, quando termina, il programma restituisce un file di nome <fileDiInput> +
“respMS” che ha associato per ogni dominio mail un elenco di mail server (da uno fino a un massimo di quattro).
1.3 Interfaccia: Script “fromHNGetZN&NS”
Il programma riceve in input un file di testoErrore. Il segnalibro non è definito. con l’elenco di host name (ad
esempio WS, MD e MS).
Ogni riga del file viene scansionata, quando termina il programma, vengono restituiti tre file:
i. <fileDiInput> + “respHN”: file che associa ad ogni host name trovato nel file originale il nome della zona;
ii. <fileDiInput> + “respZN”: file che associa ad ogni zona trovata i name server che la gestiscono.
iii. <fileDiInput> + “respNS”: file che associa ad ogni name server trovato la rispettiva zona di appartenenza.
Osservazione
Il file <fileDiInput> + “respZN” contiene tutte le zone, quelle di: Web Server, Mail Server, Mail Domain, Name Server e
quelle non ancora analizzate soprastanti a zone già esplorate.
1.4 Interfaccia: Script “fromHNGetIP&ASN”
Il programma riceve in input un file di testoErrore. Il segnalibro non è definito. con l’elenco di host name (solo
quelli a cui può essere associato un indirizzo IP: WS, NS e MS).
Ogni riga del file viene scansionata, quando termina il programma vengono restituiti due file:
i. <fileDiInput> + “respIP”: file che associa ad ogni host name trovato nel file originale il rispettivo indirizzo
IP, nome di dominio equivalente (se presente), network number/24, ASN e Owner ASN;
ii. <fileDiInput> + “respASN”: file che associa ad ogni network number il rispettivo ASN.

pag. 29
2
Implementazione della raccolta dati
In questo capitolo si descrive brevemente come funzionano internamente i programmi script descritti nel capitolo
“
” (pag. 27).
Tutti gli script descritti sono stati implementati in Python e hanno fatto uso di vari moduli, nei frammenti di codice
successivi vengono riportati solo i passaggi chiave della ricerca.
2.1 Implementazione: Script “requestHttp/https”
Il programma apre il file di input e per ogni riga ricava l’indirizzo uri13
. La ricerca viene fatta costruendo l’url con
parte inziale http e https. (Halley, 2019)
1. import urllib3
2. http = urllib3.PoolManager(cert_reqs='CERT_REQUIRED', ca_certs = 'cacert.pem')
3.
4. pagedata = http.request("GET", "http://www.arpalazio.it/", retries=True,
5. headers= headersHTTP, timeout=8.0, redirect=False)
6. print(pagedata.status)
7.
8. >>> 200
9. # La pagina web è stata trovata ed è su http
Tali comandi permettono di richiedere la pagina web http://www.arpalazio.it/. Se la richiesta è fatta su https
allora, grazie all’istruzione alla riga 2 deve essere restituita una pagina su protocollo https (a meno di un’esplicita
redirection su http).
Come specificato in precedenza, bisogna anche fare una richiesta https verso la medesima pagina web:
1. pagedata = http.request("GET", "httpS://www.arpalazio.it/", retries=True,
3.
4. ...
5.
6. except urllib3.exceptions.MaxRetryError as err:
7. print("No connection")
8.
9.
10. # pagedata.status ≠ 200
11. >>> No connection
13 Se si tratta già di un uri o di un host name allora il programma non fa nulla, altrimenti se si tratta di un
url viene tagliata la prima parte di questo.

pag. 30
Poiché il sito in esame non ha la pagina su https, allora possono verificarsi situazioni diverse che si riassumono in
questi due casi:
1) Il sito risponde con uno status code negativo, ad esempio 404;
2) La connessione termina perché non si riesce a trovare la pagina web richiesta in quanto l’indirizzo url è
inesistente.
Il caso appena analizzato raffigura un sito web che non subisce alcun genere di redirection ma che esiste solo su
http (il WS verrà classificato come OP).
Per sapere se ci sono state redirection allora devono essere rispettate le seguenti condizioni:
1) Lo status code della risposta http non è 200;
2) Nella risposta è presente l’header http Location.
1. pagedata = http.request("GET","httpS://www.ati3umbria.it/", retries=True,
4.
5. >>> 302
6. # pagedata.status ≠ 200
7.
8. headerDict = pagedata.headers.keys()
9. if ('location' in headerDict):
10. URL_redirection = pagedata.headers['location']
11. print(URL_redirection)
12.
13. >>> URL_redirection = http://www.ati3umbria.it/ati3/
14.
15. pagedata = http.request("GET, URL_redirection, retries=True,
18.
19.
20. >>> pagedata.status = 200
21. # La pagina web richiesta in origine non esiste su httpS e la richiesta viene
22. # reindirizzata sulla stessa pagina versione http
L’istruzione alla riga 8 crea un data dictionary con la seguente struttura
response header : value of response header
Quest’ultimo caso rappresenta una pagina web che si trova su http; tutte le richieste verso tale sito che hanno
come prima parte dell’url il protocollo https, vengono reindirizzate sulla pagina http (il WS verrà classificato con
l’attributo STP).
2.2 Implementazione: Script “fromMDgetMS”
Il programma apre il file di input e per ogni riga, che corrisponde ad un mail domain, ricava il mail server.
Vengono riportati di seguito frammenti di codice che illustrano come si sono ricavate tali informazioni.
1. import dns.resolver # libreria necessaria per effettuare le richieste al dns di qualsiasi
2. # tipo

pag. 31
3.
4. ...
5.
6. my_resolver = dns.resolver.Resolver()
7. my_resolver.nameservers = ['8.8.8.8'] #8.8.8.8 IP del server dns di Google
8. response = my_resolver.query("emarche.it", "MX", raise_on_no_answer=False)
9.
10. print(response.rrset)
11.
12. >>> emarche.it. 18506 IN MX 0 tmailpr4.emarche.it.
Alla riga 7 del codice l’istruzione scritta è equivalente a una richiesta al dns del seguente tipo:
 emarche.it MX ?
2.3 Implementazione: Script “fromHNGetZN&NS”
Vengono riportati frammenti di codice che illustrano i principali passaggi per ricavare a partire da un host name,
la zona e i rispettivi name server.
1. import dns.resolver
2.
3. ...
4.
6. my_resolver.nameservers = ['8.8.8.8'] #8.8.8.8 IP del server dns di Google
7.
8.
9. response = my_resolver.query("www.quirinale.it", 'NS', raise_on_no_answer=False)
10.
12.
13. >>> None
L’istruzione alla riga 9 è equivalente ad una richiesta al dns del seguente tipo:
 www.quirinale.it NS ?
La risposta che si riceve è None perché il dominio specificato nella richiesta non corrisponde ad un nome di zona.
Elaborando opportunamente la stringa che rappresenta il nome di dominio, si riformula la richiesta al dns e si
riceve la risposta desiderata.
1. response = my_resolver.query("quirinale.it", 'NS', raise_on_no_answer=False)
3.
4.
5. >>> quirinale.it. 2743 IN NS ns2.quirinale.it.
6. >>> quirinale.it. 2743 IN NS ns.quirinale.it.

pag. 32
7. >>> quirinale.it. 2743 IN NS ns3.quirinale.it.
8. >>> quirinale.it. 2743 IN NS dns11.interbusiness.it.
9. >>> quirinale.it. 2743 IN NS dns3.interbusiness.it.
Osservazione:
Per ogni name server trovato bisogna effettuare una richiesta di tipo NS per trovare la zona di questi. Nel codice si può
osservare che per i NS colorati in nero la ricerca finirà subito in quanto appartengono ad una zona già esplorata, mentre
per i NS colorati in blu la ricerca proseguirà perché non appartengono alla zona quirinale.it.
Volendo ora trovare il name server primario si procede allo stesso modo, con la sola differenza che si deve
effettuare una richiesta di tipo SOA.
1. response = my_resolver.query("quirinale.it", 'SOA', raise_on_no_answer=False)
3.
4. >>> quirinale.it. 3599 IN SOA ns.quirinale.it.
5. >>> postmaster.quirinale.it.
6. >>> 4017111305 86400 18001382400
7. >>> 3600
Il name server primario è specificato nel primo campo della RR ritornato come risposta.
2.4 Implementazione: Script “fromHNGetIP&ASN”
Per effettuare la richiesta al dns di tipo A per un certo indirizzo IP si utilizza lo stesso modulo (dns.resolver)
utilizzato nel paragrafo “Implementazione: Script “fromHNGetZN&NS”Implementazione: ”.
1. response = my_resolver.query("www.alianzbank.it")
3.
4. >>> www.allianzbank.it. 18828 IN A 194.127.23.180
L’istruzione alla riga 1 è equivalente a
response = my_resolver.query("www.alianzbank.it", 'A', raise_on_no_answer=False)
Entrambe esprimono una richiesta al dns di tipo A per il dominio www.alianzbak.it.
In questo caso si osservi che la risposta che il name server restituisce esprime che il dominio richiesto è
direttamente associato all’indirizzo IP.
Se si volesse trovare l’indirizzo IP del dominio dell’Esempio 7 (www.banca5.com) allora si dovrebbe fare una
richiesta analoga a prima.
1. response = my_resolver.query("www.banca5.com")
3.

pag. 33
4. >>> 5a6e5ccf-ab7b-49b7-bf40-f59874a82527.cloudapp.net. 59 IN A 13.93.118.76
Questa volta si osservi che il RR ritornato dal name server si riferisce ad un nome di dominio diverso da quello
richiesto in origine, per cui il dominio www.banca5.com è equivalente a quello ritornato dal name server.
Per trovare ASN e organizzazione proprietaria di tale AS è stato utilizzato il modulo “cymruwhois” (Azoff, 2019).
Si riportano di seguito i frammenti di codice che illustrano come da un indirizzo IP si ricavano le informazioni
volute.
1. from cymruwhois import Client
2.
3. ...
4.
5. c = Client()
6. r = c.lookup('13.93.118.76')
7. print("ASN: " + str(r.asn) + "tOWNER AS: " + str(r.owner))
8.
9. >>> ASN: 8075 OWNER AS: MICROSOFT-CORP-MSN-AS-BLOCK - Microsoft Corporation, US
2.5 Considerazioni generali
In tutti gli script sono state gestite alcune eccezioni per evitare che lo script si interrompesse. Ciò è molto
importante in quanto l’esecuzione di uno script è lunga (“requestHttp/https” può durare anche più di un giorno)
e se ci fosse qualche problema (ad esempio legato alla connessione, oppure il sito cui ci si sta collegando è
inesistente) si vuole gestirlo e proseguire con la ricerca evitando che tutto il lavoro svolto fino a quel punto vada
perso.

pag. 34
3 Librerie utilizzate in Python e semplice manuale d’uso
Le librerie utilizzate in questa tesi possono avere sostanzialmente tre scopi diversi:
1) Effettuare richieste http,
2) Interrogare il dns,
3) Analizzare un indirizzo IP risalendo a certe sue caratteristiche (ad esempio ASN e Owner ASN)
3.1 Librerie per effettuare richieste http
Per effettuare una semplice richiesta http si usa la libreria urlib.request (Reitz, 2019).
1. import urllib.request
2. Url = "https://www.difesa.it"
3. response = urllib.request.urlopen(Url)
4.
5. print(response.headers)
>>> Content-Type: text/html; charset=utf-8
>>> request-id: 51f9ea9e-257b-0026-64f0-b3d12d071ca6
>>> Date: Fri, 28 Jun 2019 09:26:22 GMT
>>> Strict-Transport-Security: max-age=157680000
>>> Server: Difesa Security Servers
>>> Set-Cookie: NSC_WJQ_EJGFTB_OFX=ffffffff09121d4d45525d5f4f58455e445a4a423660
In ingresso si specifica l’Url (riga 2) che si vuole prelevare e alla riga 5 si stampano gli header della risposta http14.
Per analizzare la pagina html restituita nella risposta http si utilizza la libreria BeautifulSoup (Richardson, 2019).
7. pageHTML = BeautifulSoup(response, "html.parser")
8. print(pageHTML)
Questa libreria (BeautifulSoup) permette l’utilizzo di certe funzioni su pagine html prelevate mediante una
richiesta http. Alla riga 7, utilizzando come parametro la risposta http ricevuta in precedenza (riga 3) si estrapola
il codice html della pagina con url “https://www.difesa.it”, che alla riga successiva viene stampato.
9. tagTarget = 'title' #ma poteva essere anche 'a', 'div', 'h1' e così via
10. for tag in pageHTML.findAll(tagTarget):
11. print(tag.text)
>>> Ministero della Difesa
Alla riga 10 si presenta un modo per prelevare solo certe informazioni dalla pagina html ricavata in precedenza.
In questo caso il tag html di interesse è <title> (riga 9).
14 Nelle porzioni di codice le righe precedute da “>>>” indicano l’output stampato sul terminale.

pag. 35
Se la pagina html ha alcuni tag che vengono caricati da script Javascript allora è necessario utilizzare un'altra
libreria, ossia Selenium.webdriver (Selenium WebDriver, 2019).
1. from selenium import webdriver
2. url = 'https://www.agenziadoganemonopoli.gov.it/'
3. driver = webdriver.Chrome()
4. driver.get(url)
5. print(driver.current_url)
>>> https://www.adm.gov.it/portale/
7. pageHTML = BeautifulSoup(driver.page_source,'html.parser')
Alla riga 3 si specifica l’url che si vuole prelevare e alla riga 6 si stampa l’url che si visualizza nella barra degli
indirizzi quando la pagina è caricata completamente. Per gestire la pagina html come in precedenza si può
nuovamente utilizzare la libreria BeautifulSoup (Richardson, 2019).
3.2 Libreria per effettuare richieste al dns
Per interrogare il dns si utilizza la libreria dns.resolver (Halley, 2019).
1. import dns.resolver
2. IPdns = '8.8.8.8'
3.
5. my_resolver.nameservers = [IPdns]
6.
7. hostName = 'difesa.it'
8. response1 = my_resolver.query(hostName, 'NS', raise_on_no_answer=False)
9.
10. print(response1.rrset)
>>> difesa.it. 579 IN NS dns.difesa.it.
>>> difesa.it. 579 IN NS ns2a.btitalia.it.
>>> difesa.it. 579 IN NS dns1.difesa.it.
L’indirizzo IP del dns può essere liberamente impostato (in questo caso corrisponde all’indirizzo IP dei dns server
di Google – riga 2 e 5).
L’istruzione alla riga 8 permette di effettuare qualsiasi tipo di richiesta al dns (in questo caso è specificata una
richiesta di tipo NS) per un determinato host name specificato come parametro.
Supponendo si volesse richiedere l’indirizzo IP del sito www.difesa.it ai name server che gestiscono la zona cui
tale sito appartiene, allora si potrebbe procedere nel seguente modo.
1. for nameServer in response1:
2. response2 = my_resolver.query(nameServer, 'A', raise_on_no_answer=False)
3. IPdnsDifesa= response2[0] #IPdnsDifesa = 78.4.240.2
4. break #in precedenza sono stati trovatati tre name server
per la zona difesa.it, mi basta un indirizzo IP
di un name server trovato
5. my_resolver.nameservers = [IPdnsDifesa]
6. response3 = my_resolver.query('www.difesa.it', 'A', raise_on_no_answer=False)
7. print(response3.rrset)
>>> www.difesa.it. 3600 IN A 78.4.240.30

pag. 36
3.3 Libreria per analizzare un indirizzo IP
Per analizzare un indirizzo IP si utilizza la libreria “cymruwhois” (Azoff, 2019)
1. from cymruwhois import Client
2. IpAddress = '74.4.240.30' #è l’indirizzo IP del Ministero della Difesa
3. c = Client()
4. r = c.lookup(IpAddress)
L’istruzione alla riga 4 crea una struttura dati che memorizza alcune proprietà dell’indirizzo IP:
1. print(r.ip) >>> 74.4.240.30
2. print(r.asn) >>> 209
3. print(r.owner) >>> CENTURYLINK-US-LEGACY-QWEST - CenturyLink Communications, LLC
4. print(r.cc) >>> US
Si osservi che l’indirizzo IP del sito del Ministero della Difesa italiana è sotto l’amministrazione di un Autonomous
System americano.

pag. 37
Parte V
Osservazioni e Conclusioni

pag. 38
1
Raccolta dati e Risultati raggiunti
1.1 Riassunto raccolta dati
Si riportano di seguito tabelle/grafici che riassumo i risultati della raccolta dati.
Categoria # OP PTS PS OS STP NF
Agenzie Fiscali 4 25,00% 75,00% 0,00% 0,00% 0,00% 0,00%
Agenzie Regioni Lavoro, Agricoltura e Ambiente 51 56,86% 17,65% 25,49% 0,00% 0,00% 0,00%
Banche 268 33,21% 61,94% 4,10% 0,00% 0,75% 0,00%
Camere di Commercio 112 63,39% 22,32% 13,39% 0,00% 0,89% 0,00%
Certification Authorities italiane 34 20,59% 50,00% 26,47% 0,00% 2,94% 0,00%
Città Metropolitane 14 28,57% 57,14% 14,29% 0,00% 0,00% 0,00%
Comuni 7.792 71,21% 20,84% 6,58% 0,01% 0,35% 1,00%
Fornitori energie elettrica e gas 298 35,57% 53,36% 9,40% 0,00% 1,01% 0,67%
Istituti di Istruzione Statale di Ogni Ordine e
Grado
7.071 50,56% 34,71% 9,50% 0,06% 2,01% 3,17%
Pec Provider 19 15,79% 57,89% 21,05% 0,00% 5,26% 0,00%
Presidenza Del Consiglio dei Ministri e Org. Cost. 24 25,00% 45,83% 16,67% 0,00% 4,17% 8,33%
Sanità 225 49,33% 31,56% 15,11% 0,44% 1,33% 2,22%
Spid Identity Provider 9 0,00% 100,00% 0,00% 0,00% 0,00% 0,00%
Spid Service Provider 3.655 0,25% 7,58% 84,46% 0,44% 0,33% 6,89%
Università 58 12,07% 72,41% 13,79% 0,00% 1,72% 0,00%
Tabella 6: riassunto dei siti web raccolti della Pubblica Amministrazione italiana suddivisi per categorie e protocollo applicativo
usato
Stato # OP PTS PS OS STP NF
Germania 8.581 25,00% 66,00% 4,00% 0,00% 1,00% 3,00%
Italia 19.366 49,40% 25,23% 22,72% 0,11% 1,00% 2,91%
Regno Unito 2.692 30,00% 54,00% 7,00% 0,00% 1,00% 8,00%
Stati Uniti d'America 5.104 17,00% 51,00% 11,00% 1,00% 1,00% 18,00%
Tabella 7: riassunto dei siti web raccolti della Pubblica Amministrazione italiana, tedesca, inglese e americana suddivisi per
protocollo applicativo usato
Legenda Tabella 6 e Tabella 7
 OP, sito web solo su http,
 PTS, sito web su https e con redirection da http a https,
 PS, sito web con esistenza autonoma su http e su https,
 OS, sito web solo su https,
 STP, sito web su http e con redirection da https a http,
 NF, sito web non analizzato, fuori dal conteggio dei calcoli statistici.

pag. 39
Mail Domain Mail Server
3.053 245
Tabella 8: riassunto mail server e mail domain raccolti
Il grafico seguente illustra il numero delle zone che sono state analizzate15 suddividendole per livello (ad esempio
1°
livello equivale ad un Top Level Domain).
Grafico 1: distribuzione delle zone rispetto ai livelli del domain tree
1.2 Gestione dei dataset online
I dati raccolti sono stati salvati in dataset su Google Drive; sono stati creati 7 file:
1) ListaCategorizzata – Italia: contiene indirizzi url/host name/uri relativi a siti di interesse pubblico italiano
suddivisi per categoria (Tabella 4: categorizzazione url della Pubblica Amministrazione italiana). Per ciascuno sito
web è memorizzata una descrizione dell’ente istituzionale, host name e descrizione del protocollo
applicativo utilizzato secondo i criteri visti nel paragrafo “Interfaccia: Script “requestHttp/https””;
2) DominiMailPerCategorie – Italia: contiene indirizzi mail e mail domain relativi a enti della Pubblica
Amministrazione Italiana suddivisi per categoria;
15 Per zona analizzata si intende una zona di cui sono stati trovati i name server che la gestiscono e la zona
soprastante (se non è TLD)
0
21910
9418
6863 820 4
39015
1 LIVELLO 2 LIVELLO 3 LIVELLO 4 LIVELLO 5 LIVELLO 6 LIVELLO TOTALE
Distribuzione delle zone analizzate

pag. 40
3) Informazioni IP/DNS – Italia: il file è suddiviso per categorie, per ogni host name presente in
ListaCategorizzata – Italia sono memorizzate le seguenti informazioni: indirizzo IP, network number 24
dell’indirizzo IP, ASN, organizzazione proprietaria dell’ASN (Owner ASN), Paese dell’organizzazione
proprietaria (Country ASN), nome della zona dell’host name, nome di dominio equivalente (se presente)
e la sua zona;
4) Informazioni IP/DNS Paesi Esteri: il file è diviso in tre fogli ognuno dei quali memorizza informazioni per
Siti web di interesse pubblico tedesco, inglese e americano; le informazioni memorizzate sono le stesse
dei file descritti al punto 1 e 3, con la sola differenza che vengono analizzati a livello di rete (indirizzo IP,
ASN e Owner ASN) e dns (nome zona) anche gli host name relativi all’url dell’ultima redirection prima di
visualizzare la pagina;16
5) Informazioni MD&MS: il file ha due fogli distinti
a. Mail Domain: contiene per ogni dominio mail (tutti distinti fra di loro) il nome della relativa zona
ed al massimo quattro mail server responsabili per quel dominio mail,
b. Mail Server: contiene per ogni mail server il nome della relativa zona, indirizzo IP, network
number di lunghezza 24 (relativo all’indirizzo IP trovato), ASN, organizzazione proprietaria
dell’ASN (Owner ASN) e Paese dell’organizzazione proprietaria (Country ASN);
6) Informazioni NS&ZN: il file ha due fogli distinti
a. zoneInfo: contiene per ogni zona trovata (e memorizzata negli altri file) il name server primario e
al massimo altri quattro name server secondari;
b. NSInfo: contiene per ogni name server trovato la zona a cui esso appartiene, l’indirizzo IP,
network number di lunghezza 24 (relativo all’indirizzo IP trovato), ASN, organizzazione
proprietaria dell’ASN (Owner ASN) e Paese dell’organizzazione proprietaria (Country ASN);
7) ASN&NetworkNumber 24: il file contiene per ogni network number di lunghezza 24 le informazioni del
rispettivo Autonomous System responsabile per quella serie di indirizzi IP (ASN, Owner ASN e Country
ASN).
16 Per i siti web italiani di interesse pubblico non sono stati analizzati gli host name dopo un eventuale
redirection.

pag. 41
1.3 Analisi dei risultati
Vengono riportate di seguito alcune analisi fatte sui dati raccolti.
1.3.1 Distribuzione dei Web Server tra gli Autonomous System
I grafici illustrano la distribuzione dei web server tra gli Autonomous System, in particolare per ogni nodo AS si
mostra il numero di WS che dipendono indirettamente17
da esso (colonna blu) e quanti di questi utilizzano solo il
protocollo http18 (colonna arancione). Sull’asse delle x sono scritti gli ASN in ordine decrescente rispetto al
numero di WS controllati (riportato sull’asse delle y).
Vengono mostrati solo i primi 50 AS.
Grafico 2: distribuzione dei WS italiani tra gli AS
La tabella seguente descrive i 5 Autonomous System che sono responsabili per la maggior parte dei Web Server
italiani. Nella colonna “Numero di WS controllati” si indica tra parentesi il numero di WSche sono stati categorizzati
come OP o STP (vedi ).
ASN Organizzazione dell’ASN Numero di WS
controllati
Numero di WS controllati in
percentuale
31034 ARUBA-ASN, IT 5.533 (3.385) 28%
8075 MICROSOFT-CORP-MSN-AS-BLOCK - Microsoft
Corporation, US 3.791 (39) 19%
16276 OVH, FR 1225 (513) 6%
5396 AS-IRIDEOS-MC, IT 965 (907) 5%
20746 ASN-IDC T.NO.OM.I.NC, IT 847 (564) 4%
17 Un nodo WS dipende direttamente da un nodo di tipo IP che a sua volta dipende direttamente da un
AS.
18
I siti web che utilizzano solo il protocollo http sono classificati nel dataset come OP oppure STP.

pag. 42
Tabella 9: primi 5 AS responsabili per la maggior parte di siti web italiani
Viene fatto un lavoro analogo per i siti web tedeschi, inglesi e americani19.
Grafico 3: distribuzione dei WS tedeschi tra gli AS
controllati
Numero di WS controllati in
percentuale
24940 HETZNER-AS, DE 1.609 (341)
19%
8560 ONEANDONE-AS Brauerstrasse 48, DE 998 (414) 12%
6724 STRATO STRATO AG, DE 707 (235) 8%
8972 GD-EMEA-DC-SXB1, DE 487 (88) 6%
15817 MITTWALD-AS Mittwald CM Service GmbH und Co.
KG, DE
376 (60) 4%
Tabella 10: primi 5 AS responsabili per la maggior parte di siti web tedeschi
19 L’analisi sui nodi WS e AS tedeschi e inglesi è stata effettuata considerando gli host name (e i rispettivi
AS) prima della redirection.

pag. 43
Grafico 4: distribuzione dei WS tedeschi tra gli AS
ASN Organizzazione dell’ASN Numero di WS controllati Numero di WS controllati in
percentuale
15395 RACKSPACE-LON, GB 396 (179) 15%
16509 AMAZON-02 - Amazon.com, Inc., US 140 (12) 5%
1273 CW Vodafone Group PLC, GB 99 (7) 4%
786 JANET Jisc Services Limited, GB 95 (21) 4%
8560 ONEANDONE-AS Brauerstrasse 48, DE 94 (57) 3%
Tabella 11: primi 5 AS responsabili per la maggior parte di siti web tedeschi
Grafico 5: distribuzione dei WS americani tra gli AS
0
100
200
300
400
500
600
36489
14618
13335
36473
16509
25694
32244
13506
7018
701
209
54113
22284
19551
4152
30449
29873
14061
55002
394417
22611
16552
31815
26810
7922
22773
USA: distribuzione dei WS americani tra gli AS
USA: distribuzione dei WS americani tra gli AS USA: numeero di WS amereicaniper AS
USA: distribuzione dei WS americani tra gli AS USA: numero di WS americani OP o STP per AS

pag. 44
controllati
Numero di WS controllati
in percentuale
36489
NETSOLUS-NETWORKS -
Netsolus.com Inc., US 491(64) 10%
26496
AS-26496-GO-DADDY-COM-LLC -
GoDaddy.com, LLC, US 284 (111) 6%
14618 AMAZON-AES - Amazon.com, Inc., US 251 (31) 5%
19994 RACKSPACE - Rackspace Hosting, US 231 (80) 5%
13335
CLOUDFLARENET - Cloudflare, Inc.,
US 166 (13) 3%
Tabella 12: primi 5 AS responsabili per la maggior parte di siti web americani
La criticità di un nodo varia a seconda da quanti nodi dipendono da esso. Gli Autonomous System che controllano
il traffico a livello di rete di un numero elevato di nodi con determinati indirizzi IP sono critici in quanto da essi
dipende il corretto funzionamento di molti Web Server, Mail Server, Name Server…
In Italia l’Autonomous System ARUBA-ASN controlla quasi un terzo del traffico a livello di rete relativo a indirizzi IP
di siti web di interesse pubblico nazionale20.
Viene riportata di seguito una tabella riassuntiva per ogni nazione che espone mediana, media, varianza rispetto
al numero di siti web in ogni AS, e percentili21
.
Stato Mediana Media Varianza 10<=Percentile<20 20<=Percentile<30
Italia 2 52,9 131.699 1 1
Germania 2 26,8 14.726 2 0
Inghilterra 2 12,1 8 1 0
USA 1 8,00 114 1 0
20 Ci si riferisce esclusivamente ai siti web raccolti.
21
Il percentile compreso fra 10 e 20 corrisponde al numero di ASN che gestiscono una percentuale di
indirizzi IP (relativi a WS) tra il 10% e il 20% rispetto al totale dei siti web; analogo per il percentile compreso tra
20 e 30.

pag. 45
1.3.2 Distribuzione dei Web Server tra le zone del domain tree
La figura seguente illustra la distribuzione dei Web Server tra i nodi ZN. Ad ogni zona è associato il numero di web
server che si trova in quella particolare zona. Il grafico mostra esclusivamente le zone per cui sono stati trovati
almeno 3 WS.
Grafico 6: numero di WS (almeno 3) per ZN
Zona Numero di WS controllati Percentuale di WS
controllati
gov.it. 217 2,54%
municipiumapp.it. 125 1,47%
halleyweb.com. 62 0,73%
comune.roma.it. 42 0,49%
regione.sardegna.it. 27 0,32%
Tabella 13: distribuzione di WS italiani tra nodi ZN
Il nodo gov.it (ZN) è critico in quanto all’interno di questa zona ci sono 217 siti di interesse pubblico nazionale.
Anche in questo caso, l’analisi sui nodi WS e ZN tedeschi, inglesi e americani è stata effettuata considerando gli
host name (e le rispettive zone) prima della redirection.
I siti raccolti relativi alla Pubblica amministrazione tedesca hanno una distribuzione sulle zone del domain tree
molto eterogenea. Sono state trovate solamente due zone che presentano una concentrazione più alta rispetto le
altre zone di siti web di interesse pubblico tedesco: bund.de. (24 WS) e rhoen-saale.net. (9 WS).
controllati
bund.de. 24 0,28%
rhoen-saale.net. 9 0,11%
bundeswehr.de. 4 0,05%
einfachteilhaben.de. 2 0,02%
amt-miltzow.de. 2 0,02%
bad-sobernheim.de. 2 0,02%
bad-woerishofen.de. 2 0,02%

pag. 46
darss-fischland.de. 2 0,02%
city-map.de. 2 0,02%
kaisersesch.de. 2 0,02%
pfronten.de. 2 0,02%
kusel.de. 2 0,02%
verwaltungsportal.de. 2 0,02%
Tabella 14: distribuzione di WS tedesche tra nodi ZN
Le zone relative ai siti di interesse pubblico inglese non presentano una concentrazione elevata di WS.
controllati
yeoviltonparishcouncil.gov.uk. 2 0,07%
yeovilwithoutparishcouncil.gov.uk. 2 0,07%
yetminsterparishes.gov.uk. 2 0,07%
ygwasanaethpensiwn.gov.uk. 2 0,07%
yjani.gov.uk. 2 0,07%
yjb.gov.uk. 2 0,07%
ynysmon.gov.uk. 2 0,07%
yorkconsort.gov.uk. 2 0,07%
york.gov.uk. 2 0,07%
yorkshirelca.gov.uk. 2 0,07%
yourpension.gov.uk. 2 0,07%
youthjusticeagencyni.gov.uk. 2 0,07%
zennorparishcouncil.gov.uk. 2 0,07%
Tabella 15: distribuzione di WS inglesi tra nodi ZN
I siti web di interesse pubblico americano si trovano tutti in zone diverse.
controllati
aberdeenmd.gov. 1 0,02%
aberdeenwa.gov. 1 0,02%
abilenetx.gov. 1 0,02%
… … …
yorksc.gov. 1 0,02%
zeroinwisconsin.gov. 1 0,02%
Tabella 16: distribuzione dei WS americani tra nodi ZN

pag. 47
Viene riportata di seguito una tabella riassuntiva per ogni nazione che espone mediana, media e varianza
rispetto al numero di siti web per ogni zona.
Stato Mediana Media Varianza
Italia 1 1,08 8,16
Germania 1 1,01 0,07
Inghilterra 1 1,00 0,01
USA 1 1 0
Tabella 17: riassunto della distribuzione di WS tra i nodi ZN per nazione

pag. 48
1.3.3 Distribuzione dei Mail Domain tra i nodi ZN
Il grafico seguente mostra la dipendenza che hanno i nodi MD dai nodi ZN. Sull’asse x sono riportate le zone a cui
appartengono almeno due mail domain, mentre sull’asse y il numero di MD.
Grafico 7: numero di MD (almeno due) per ZN
Il grafico evidenzia 212 domini mail, i restanti 2.839 si trovano tutti in zone diverse.
Le zone legalmail.camcom.it. e legalmail.it. sono critiche in quanto in esse sono presenti rispettivamente 79 e 72
domini mail distinti.

pag. 49
2
Prossimamente
2.1 Sviluppi futuri
Il lavoro descritto in questa tesi non si conclude con questo capitolo. I dati raccolti permettono di effettuare molte
altre analisi e studiare altre dipendenze che hanno fra di loro i nodi del grafo.
2.1.1 Dipendenze dirette e indirette fra zone
Un’analisi sulle dipendenze tra i nodi che non è stata affrontata in questa tesi ma che può risultare molto
interessante è la seguente.
Esistono due diversi tipi di dipendenze fra zone che sono state definite nel grafo:
4) Dipendenza diretta fra due zone: una zona 𝑍𝑁 dipende direttamente da un’altra zona 𝑍𝑁 se
quest’ultima non è un Top Level Domain ed è la zona immediatamente soprastante (nel domain tree) a
𝑍𝑁 ;
5) Dipendenza indiretta fra due zone: una zona 𝑍𝑁 dipende indirettamente da 𝑍𝑁 se è rispettata almeno
una delle seguenti condizioni:
i. Esiste un name server che gestisce la zona 𝑍𝑁 che si trova in 𝑍𝑁 , oppure
ii. Esiste una zona 𝑍𝑁 per cui 𝑍𝑁 dipende direttamente (punto 1), e 𝑍𝑁 dipende
direttamente (o indirettamente secondo questi principi) da 𝑍𝑁 .
ESEMPIO 8
Si vuole sapere il numero di zone per cui la zona blog.tiscali.it dipende direttamente e indirettamente.
ZN
blog.tiscali.it
NS
hannibal.dns
.tiscali.it
NS
murdock.dn
s.tiscali.it
NS
barakus.dns.
tiscali.it
ZN
blog.tiscali.it
ZN
tiscali.it
Immagine 19: dipendenza da zona di blog.tiscali.it

pag. 50
In questo caso la zona blog.tiscali.it dipende:
1) Direttamente da 1 zona (tiscali.it),
2) Indirettamente da 1 zona (dns.tiscali.it).
Tale analisi ha lo scopo di trovare per ogni zona il numero di dipendenze dirette e indirette che ha da altre zone.
Esistono altri lavori futuri che possono prendere spunto da questa tesi e soprattutto facendo uso dei dati raccolti,
ad esempio:
1) Costruzione completa del grafo attraverso un graph database oppure un RDBS22;
2) Analisi in base alla posizione geografica dei nodi raccolti quali web server, name server e mail server.
3) Analisi approfondita sugli Autonomous System raccolti:
i. Trovare gli AS neighbours di ogni AS individuato classificandoli in base alla loro locazione geografica
(ad esempio interni o esterni all’Unione Europea)
ii. Determinare gli instradamenti tra AS che hanno il primo step esterno all’Unione Europea.
22 I nodi possono essere espressi come delle entità (ad esempio WS può essere visto come un’entità i cui
attributi sono: Nazione, http/https, IP…) e le dipendenze come delle relazioni.

pag. 51
3 Considerazioni personali
Il lavoro svolto in questa tesi è stato impegnativo ma al contempo molto interessante e soddisfacente. Le ricerche
effettuate hanno permesso di studiare in campo pratico argomenti trattati nel corso di “Reti di Calcolatori I”.
Inoltre, per effettuare le ricerche è stato utilizzato nella maggior parte dei casi il linguaggio di programmazione
Python che prima di questa esperienza non era mai stato trattato in nessun corso della triennale di Ingegneria
Elettronica Informatica.
Il lavoro di questa tesi è orientato al campo della ricerca, campo in cui personalmente non avevo mai lavorato.
Considero l’esperienza svolta assolutamente positiva.

Bibliografia e strumenti utilizzati
Autonomous system (Internet). (2019). Tratto da https://en.wikipedia.org/wiki/Autonomous_system_(Internet)
Azoff, J. (2019). cymruwhois library: Perform lookups by ip address and return ASN, Country Code, and Netblock
Owner. Tratto da https://pypi.org/project/cymruwhois/
Bartoli, A. (2018). Reti di Calcolatori I.
Bartoli, A. a. (2018). A Security-Oriented Analysis of Web Inclusions in the Italian Public Administration.
Cybernetics and Information Technologies, 18(4), 94--110.
Halley, B. (2019). dnspython – a DNS toolkit for Python. Tratto da https://pypi.org/project/dnspython/
Pandas, data structures for data analysis in python. (2019). Tratto da https://pypi.org/project/pandas/
Petrov, A. (2019). urllib3 Library. Tratto da https://pypi.org/project/urllib3/
Python language bindings for Selenium WebDriver. (2019). Tratto da https://pypi.org/project/selenium/
Python Software Foundation. (2019). Python for beginners. Tratto da
https://www.python.org/about/gettingstarted/
Reitz, K. (2019). Requests: HTTP for Humans. Tratto da https://pypi.org/project/requests/
Richardson, L. (2019). beautifulsoup4 · PyPI. Tratto da https://pypi.org/project/beautifulsoup4/
Selenium WebDriver. (2019). Tratto da http://www.seleniumhq.org/docs/03_webdriver.jsp

Ringraziamenti
La prima persona che vorrei ringraziare per l’esperienza e il lavoro svolto in questa tesi è il mio relatore Chiar.mo
Prof. Alberto Bartoli che, oltre ad avermi dato la possibilità di affrontare in modo pratico e diretto argomenti
trattati nel suo corso Reti di Calcolatori I, mi ha seguito molto da vicino dandomi consigli, motivazioni e stimoli per
fare sempre di più.
Ringrazio successivamente la mia famiglia, mia mamma, mio papà e i miei nonni; un ringraziamento particolare lo
faccio a Marina, mia sorella, che per me è una guida e una fonte di ispirazione.
Ringrazio i mie amici Alessia, Giacomo, Simone, Erik e tutti quelli che mi sono stati vicini in questi tre anni di lavoro
che sono riusciti a “sopportarmi” e nel mentre a darmi sempre la forza per andare avanti.
Ringrazio tutti i miei compagni di corso, in particolare Max, Matteo e Giovanni che sono stati fondamentali per il
mio percorso, facendomi capire quanto sia importante ed efficace il lavoro di gruppo.
Ringrazio l’Università di Trieste, eccezionale ed unica dal punto di vista didattico e dei servizi offerti.
Sono stati tre anni di sfide ed ostacoli da superare, ma le soddisfazioni ricevute hanno ripagato tutti i sacrifici fatti.
Ringrazio di nuovo tutti per questo bellissimo viaggio.
Con affetto,
Marco

Analisi della robustezza architetturale a livello routing e dns in servizi web di interesse pubblico: studio in varie nazioni

Recommended

Recommended

More Related Content

Similar to Analisi della robustezza architetturale a livello routing e dns in servizi web di interesse pubblico: studio in varie nazioni

Similar to Analisi della robustezza architetturale a livello routing e dns in servizi web di interesse pubblico: studio in varie nazioni (20)

Analisi della robustezza architetturale a livello routing e dns in servizi web di interesse pubblico: studio in varie nazioni