Thesis written by Lorenzo Fabbio, student of Università di Trieste.

1. Progetto e realizzazione di uno
strumento per la raccolta di dipendenze
architetturali nei servizi Internet
Laureando: Lorenzo Fabbio
Relatore: Alberto Bartoli
Tesi di Laurea Magistrale
Dipartimento di Ingegneria ed Architettura
Università di Trieste
7 marzo 2022

3. Indice
1 Introduzione 1
2 Progettazione 3
2.1 Definizione delle dipendenze architetturali . . . . . . . . . . . . . . . 3
2.2 Strumenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Realizzazione 9
3.1 Utilizzo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Architettura interna . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4 Database 15
4.1 Struttura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Gestione del database . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3 Interrogazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4 Persistenza degli errori . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5 Analisi 29
5.1 Dataset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.3 Risultati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
i

5. Elenco delle figure
3.1 Diagramma di flusso preambolo . . . . . . . . . . . . . . . . . . . . . 14
3.2 Diagramma di flusso parte centrale . . . . . . . . . . . . . . . . . . . 14
3.3 Diagramma di flusso epilogo . . . . . . . . . . . . . . . . . . . . . . . 14
4.1 Schema ER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1 Ridondanza nella name resolution per mail domain: #Nameserver
vs #Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.2 Ridondanza nella name resolution per mail domain: #Network vs
#AS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.3 Ridondanza nella name resolution per mail domain: #Nameserver
vs #Network solo da zone dirette . . . . . . . . . . . . . . . . . . . . 34
5.4 Ridondanza nella name resolution per mail domain: #Network vs
#AS solo da zone dirette . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.5 Dipendenze nella name resolution per mail domain: dagli AS (solo
zone dirette) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.6 Ridondanza nell’access path per mail domain: #Mailserver vs
#Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.7 Ridondanza nell’access path per mail domain: #Network vs #AS . 38
5.8 Dipendenze nell’access path per mail domain: dagli AS (solo zone
dirette) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.9 Dipendenze nell’access path per mail domain: dalle Network (solo
zone dirette) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.10 Ridondanza nella name resolution per IdP: #Nameserver vs #Net-
work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.11 Ridondanza nella name resolution per IdP: #Network vs #AS . . . 41
5.12 Ridondanza nell’access path per IdP: #Webserver vs #Network . . 42
5.13 Ridondanza nell’access path per IdP: #Network vs #AS . . . . . . 42
iii

7. Capitolo 1
Introduzione
Considerata la crescente integrazione dei servizi web nella sfera legale di un qualunque
cittadino, diventa sempre più importante analizzare la gravità di un potenziale attacco
ai servizi web governativi offerti da una nazione intera. La sicurezza di questi servizi
passa attraverso varie tecnologie ed infrastrutture, tra cui la risoluzione dei nomi (name
resolution) ed il percorso di accesso (access path) le quali introducono dei legami verso
agenti esterni alle entità per permetterne il funzionamento corretto. Diventa quindi molto
importante conoscere quali siano le dipendenze da questi agenti esterni per definire il
perimetro di sicurezza da difendere. Un eventuale attacco Man-In-The-Middle (MITM)
alla risoluzione dei nomi od alla risoluzione del percorso di accesso di una certa entità
governativa può compromettere il funzionamento dei servizi istituzionali per un numero
molto grande di cittadini, non solo nel semplice funzionamento (attacchi DoS Denial-
of-Service) ma anche nel furto di dati e nella possibilità di impersonare un cittadino in
maniera fraudolenta. In questo lavoro si è sviluppato uno strumento per la raccolta delle
dipendenze architetturali nei servizi web, per poi analizzare tali dipendenze di un insieme
di entità governative derivanti da 4 nazioni differenti. Tale analisi non si preoccupa di
dare un giudizio sulla sicurezza della casistica analizzata, ma piuttosto di evidenzarne
i possibili punti critici prendendo come modello di attacco un attaccante il quale riesca
a prendere il controllo di una o più componenti delle entità da cui dipendono i servizi
istituzionali.
Il framework per la definizione delle dipendenze architetturali ed il software per la
raccolta di tali dipendenze sono basati su attività svolte in precedenza presso l’Università
di Trieste che saranno evidenziate nel resto del documento. Il contributo principale di
questa tesi consta di un’applicazione scritta utilizzando Python eseguibile in ambiente
Windows.
Nella trattazione sarà prima affrontata la progettazione logica per poi passare agli
strumenti effettivamente utilizzati nell’implementazione. Il focus poi passerà sulla parte
realizzativa, in particolare sulle istruzioni per far funzionare l’applicazione e su quali
siano le strutture base dei moduli sviluppati così da comprenderne il comportamento.
1

8. 1| Introduzione
Componente fondamentale è il database quindi un capitolo sarà dedicato interamente ad
esso focalizzandosi sulla struttura, le relative interrogazioni con l’aggiunta di esempi per
fare da guida sul suo utilizzo. Infine, sarà trattata l’analisi dei dati svolti partendo dai
dataset, poi la metodologia per la presentazione dei risultati e per ultime le conclusioni
tratte.
2

9. Capitolo 2
Progettazione
2.1 Definizione delle dipendenze architetturali
Il problema della definizione delle entità di interesse e delle corrispondenti dipendenze
architetturali è stato affrontato in un lavoro svolto in precedenza dal relatore di questa
tesi (prof. Bartoli [1]). Una prima versione del software per raccogliere materialmente tali
dipendenze è stata realizzata in una tesi di laurea magistrale svolta nell’a.a. 2020/20211
.
In questa tesi è stato esteso il modello delle entità di interesse e delle dipendenze tra
loro. Se prima la raccolta di dipendenze trattava solo website, ora considera anche i mail
domain. Inoltre, è stata introdotta la dipendenza dei website dagli script:
• website: URL con/senza protocollo
• mail domain: nomi di dominio email (definiti nel DNS con un resource record di
tipo MX)
L’applicazione prenderà in input una lista di website ed una lista di mail domain per
raccoglierne le dipendenze architetturali nel contesto di:
• name resolution: traduzione di un nome di dominio in indirizzo IP
• access path: procedura di accesso all’entità interessata una volta conclusa la
traduzione del nome in indirizzo IP
Oltre alle due entità principali vengono trattate altre entità di interesse:
• webserver: server relativo ad un website
• mailserver: server relativo ad un mail domain
• scriptsite: website il cui URL indica uno script
1
"Analisi delle dipendenze architetturali dei servizi di autenticazione SPID" sviluppata da Simonini
Leonardo
3

10. 2| Progettazione
• scriptserver: server relativo ad un scriptsite
• zona: ovvero zona DNS
• nameserver di una zona
• network: range IPv4 /24
• autonomous system
Di seguito sono riportate le regole che stabiliscono in cosa consistono le già menzionate
dipendenze:
Definizione dipendenze Sia u l’URL di un website. Prelevando tale URL su HTTP
o HTTPS il website risponderà con zero o più HTTP redirection fino a raggiungere una
landing page. Sia u’ l’url di tale landing page (è probabile che u = u’). Si definisce
landing scheme il protocollo di u’ e si definisce landing name la seconda componente di
u’.
• un landing name dipende da:
– zona di appartenenza
– una network (se il landing name è mappato con un resource record di tipo A),
oppure un altro landing name (se invece è mappato con un resource record di
tipo CNAME)
• una zona dipende da:
– i suoi nameserver
– la zona gerarchicamente superiore nel DNS Tree
– le zone dei nomi dei suoi nameserver ad eccezioni di sé stessa
• una network dipende dall’autonomous system responsabile del range di indirizzi
IP in cui si trova tale network
• un autonomous system non ha dipendenze
Di seguito sono riportate le differenze delle dipendenze raccolte tra le entità principali:
Dipendenze website
• i website dipendono da 1 o 2 landing name in base all’utilizzo del protocollo HTTP
e HTTPS. Essi corrispondono ai web server.
4

11. 2| Progettazione
• un website dipende da zero o più scriptsite: tecnicamente questa dipendenza viene
definita nella seguente maniera:
– un website dipende da script caricati da un sito web diverso dal website; il
caricamento viene effettuato dall’iframe che contiene la pagina principale del
website.
– non vengono considerati gli script in linea
– per ogni script si estrae il corrispondente scriptsite estraendo dall’URL dello
script la seconda componente
Dipendenze mail domain
• i mail domain dipendono da 1 o più mailserver.
• i mailserver sono modellati come i landing name
Dipendenze scriptsite
• gli scriptsite dipendono da 1 o più scripserver.
• gli scripserver sono modellati come i landing name
Tra le dipendenze dalle zone è molto importante sottolinearne un tipo in particolare:
le dipendenze dalle zone dirette. Queste dipendenze giocano un ruolo più importante
rispetto le altre: la traduzione di un nome di dominio in indirizzo IP può coinvolgere la
zona in cui è presente il nome di dominio, la root zone e potenzialmente tutte le zone
tra esse. Le dipendenze dalle zone dirette sono più rilevanti perchè la probabilità di
interagire con un nameserver della zona diretta è più alta rispetto a quella delle altre
zone che legano la zona diretta alla root zone. Perciò l’impatto potenziale di un attacco
ad una componente di una zona diretta è più alto.
Per ogni indirizzo IP si determina l’autonomous system (AS) da cui dipende e per
tale AS è possibile effettuare l’elaborazione ROA 2
[2]: essa consiste nell’andare a scoprire
quali sono i ROA (Route Origin Authorizations) associati ad un AS e controllare, per ogni
prefisso, se l’indirzzo IP fa parte di una delle network annunciate (con autorizzazione) da
tale AS. Tali informazioni non sono accessibili attraverso una API ma sono esposte in una
pagina web, pertanto è necessario estrarle dal DOM corrispondente con una procedura
di web scraping la quale richiede alcune decine di secondi per eseguire. A causa di ciò
si è scelto di permettere di eseguire l’elaborazione ROA solo dopo aver settato un flag
apposito.
Tutte le dipendenze raccolte vengono poi inserite in un database il quale sarà il
risultato dell’esecuzione, in modo da poter essere interrogato poi in futuro.
2
https://en.wikipedia.org/wiki/Resource_Public_Key_Infrastructure
5

12. 2| Progettazione
Data la natura dei vari meccanismi coinvolti nella raccolta delle dipendenze, è possi-
bile che in una esecuzione non sia possibile identificare e raccogliere tutte le dipendenze
associate alle liste di domini specificate in input. Anzi, l’idea di base di utilizzo del-
l’applicativo è proprio quello di farlo eseguire più volte per riuscire a cogliere tutte le
dipendenze che verrebbero potenzialmente perse durante una singola esecuzione. Questa
modalità di utilizzo implica le seguenti considerazioni:
• quando accade un errore nella raccolta, questo, come i dati normalmente salvati,
deve persistere all’interno del database per poter essere risolto in futuro; l’applica-
zione quindi presenta al proprio interno una sorta di semplice protocollo per capire
cosa non è stato possibile raccogliere nell’elaborazione
• a causa degli errori accaduti durante una elaborazione, il database risultante sarà
quindi incompleto
• grazie al protocollo con la quale sono stati salvati gli errori, l’applicazione può pren-
dere in input il database di una qualsiasi esecuzione precedente e tentare di com-
pletarlo. A tale scopo l’applicazione prevede un flag il quale indica se l’esecuzione
deve iniziare con il completamento del database o meno.
Ovviamente se l’errore che si è verificato non è un errore transitorio, (ad esempio il DNS
dovrebbe contenere un resource record con un certo nome ed un certo tipo ma tale record
in realtà non esiste) allora si manifesterà anche nelle esecuzioni successive. In questo caso
deve essere l’utente a decidere quando considerare la raccolta delle dipendenze completa.
Un aspetto che nell’analisi potrebbe avere poco peso è quello di considerare come
dipendenza nella name resolution i TLD (Top-Level Domains), questo perché dati tutti
i servizi offerti all’interno di una nazione, analizzare le dipendenze anche in termini di
TLD non è particolarmente significativo. Proprio per questo la raccolta delle dipendenze
dai TLD è stata resa opzionale.
Il nucleo dell’applicazione consiste in un insieme di classi che si possono definire
Resolver; esse sono state sviluppate per attuare la raccolta di uno specifico tipo di
dipendenze delle entità che si mettono in input. Inoltre per ogni resolver si è definita
una classe rappresentante il risultato di un’elaborazione di tale resolver. L’esecuzione
del programma consiste di una sequenza di invocazioni sui resolver che rappresentano le
dipendenze da raccogliere.
Come già accennato prima, il risultato finale di una esecuzione del sistema risulta
in un database, per questo motivo si è scelto di effettuare l’inserimento di tutti i dati
raccolti come passo finale dell’elaborazione.
6

13. 2| Progettazione
2.2 Strumenti
Per poter lavorare con il DOM delle pagine con cui facciamo richieste, l’applicazione
necessita di un’istanza di un headless browser, specificatamente è necessario aver instal-
lato Mozilla Firefox3
all’interno del proprio computer Windows ed inoltre è necessario
provvedere il file eseguibile di geckodriver4
in input all’applicazione. Per la persistenza
dei dati è stato scelto di utilizzare il DBMS SQLite assieme all’Object-Relational Map-
ping (ORM) peewee. L’ORM necessita dei suoi pacchetti per funzionare, i quali saranno
esplicitati nel prossimo capitolo assieme agli altri pacchetti necessari. Da notare che
utilizzando un ORM, l’applicativo non è strettamente vincolato al solo utilizzo di ta-
le DBMS specifico, perciò con una piccola modifica ci si può collegare anche ad altre
istanze di DBMS differenti 5
.
3
https://www.mozilla.org/it/firefox/windows/
4
https://github.com/mozilla/geckodriver/releases
5
si veda la trattazione relativa al file /persistence/BaseModel.py nel cap. 5
7

14. 2| Progettazione
8

15. Capitolo 3
Realizzazione
3.1 Utilizzo
Essendo l’applicazione scritta in Python, banalmente è necessario un interprete Python
per farla eseguire. In questo lavoro è stato utilizzato Anaconda Navigator1
, con il quale
si è creata un’installazione senza nessuna modifica ai pacchetti base di Python versione
3.8. Per installare i pacchetti si è utilizzato il gestore di pacchetti pip versione 21.2.2. I
comandi per installare tali pacchetti con le loro relative versioni sono:
• pip install dnspython==2.1.0
• pip install selenium==4.1.0
• pip install selenium-wire==4.5.5
• pip install peewee==3.14.8
La macchina su cui si fa eseguire il programma deve presentare come OS Windows
ed un’installazione di Mozilla Firefox 2
.
L’applicazione presenta 2 cartelle cruciali nel percorso principale del progetto: input
ed output. La funzione della cartella input è quella di ricevere i file necessari per far
funzionare l’applicazione, ovvero:
• geckodriver.exe : il file eseguibile di geckodriver 3
• web_pages.txt : un file di testo contente tutti i website le cui dipendenze si vuole
collezionare
• mail_domains.txt : un file di testo contente tutti i mail domain le cui dipendenze
si vuole collezionare
1
https://docs.anaconda.com/anaconda/install/
2
https://github.com/mozilla/geckodriver/releases
3
https://github.com/mozilla/geckodriver/releases
9

16. 3| Realizzazione
• (OPZIONALE) *.tsv : il file database pubblico4
che associa le IP route agli
autonomous system (AS). Il file scaricabile dal sito viene aggiornato ogni ora. È
opzionale inserirlo nella cartella poiché l’applicazione in automatico lo scarica se
non è presente o se non è aggiornato.
Se i file di testo sono mancanti, l’applicazione utilizzerà dei valori di default:
• come website:
– google.it/doodles
– www.youtube.it/feed/explore
• come mail domain:
– gmail.com
– outlook.com
La funzione della cartella output invece è quella di contenere tutti i file risultanti
dall’elaborazione, ovvero:
• results.sqlite : il database con tutte le dipendenze raccolte al proprio interno
• dns_cache.csv : un file contenente tutta la cache del resolver DNS
• error_logs.csv : un file contenente tutti i log di errore incontrati durante
l’elaborazione
Da notare che il database non deve essere spostato se lo si vuole utilizzare come
input in una esecuzione successiva. L’applicazione andrà a cercarlo automaticamente
nella cartella output.
L’applicazione si lancia eseguendo il file main.py nel percorso principale del progetto. I
flag sono settabili da linea di comando per personalizzare l’esecuzione del programma.
Sono definiti nel seguente modo:
• -continue setta il flag al valore True attivando il completamento delle entità non
risolte all’interno database. Il valore di default è False
• -tlds setta il flag al valore True attivando la considerazione dei TLD nelle name
resolution. Il valore di default è False.
• -rov setta il flag al valore True attivando l’elaborazione ROA. Il valore di default
è False
4
https://iptoasn.com/
10

17. 3| Realizzazione
Il progetto è disponibile online al repository offerto da GitHub: https://github.
com/LemmeeD/Lavoro-Tesi.
Se durante l’esecuzione del programma dovesse essere lanciata un’eccezione non ge-
stita, allora verrà attivato un particolare meccanismo che crea una istantanea dello stato
iniziale dell’intera applicazione al suo avvio per poter riprodurre l’errore e tentare di ri-
solverlo. Questo meccanismo lavora in una sua propria cartella del progetto, chiamata
SNAPSHOTS; essa presenta un file di script e dei file temporanei che vengono scritti ad
ogni avvio di una nuova esecuzione. Il suo funzionamento prevede che una volta acca-
duta una eccezione non gestita, si venga a creare una cartella in cui sono presenti tutti
i parametri iniziali dell’applicazione ed ovviamente la descrizione dell’errore avvenuto.
Specificatamente essa conterrà 5 file:
1. web_sites.txt : contenente tutti i website messi in input all’applicazione
2. mail_domains.txt : contenente tutti i mail domain messi in input all’applicazione
3. starting_cache.csv : contenente tutta la cache del resolver DNS all’avvio
dell’applicazione
4. error.txt : contenente 3 informazioni scritte relative all’eccezione:
• il tipo
• il messaggio
• la rappresentazione in stringa dell’oggetto Traceback
La cartella avrà come nome il timestamp relativo alla sua creazione.
Esempio: 17022022_105055 ⇒ successo il 17/02/2022 alle 10:50:55
3.2 Architettura interna
Come descritto nella sezione 2.1 il nucleo dell’applicazione consiste in un insieme di classi
Resolver ognuna specializzata per raccogliere dipendenze di un certo tipo. L’esecuzione
del programma consiste di una sequenza di invocazioni sui resolver che rappresentano le
dipendenze da raccogliere. I resolver che sono stati definiti sono 5:
1. DnsResolver: classe rappresentante un resolver DNS la quale presenta metodi già
pronti per la raccolta delle dipendenze. Al suo utilizzo è legata anche la classe
LocalDnsResolverCache:
• rappresenta una cache per salvare i resource record risultanti dalle interroga-
zioni al DNS. In tal modo si evita di fare interrogazioni duplicate e si evitano
anche eventuali errori transitori.
11

18. 3| Realizzazione
• la classe è inserita nel pacchetto /entities
2. IpAsDatabase: contenente tutto il database IP route-AS reperibile online 5
. Una
istanza di questo resolver rifletterà al proprio interno il formato specificato nel sito
da cui si scarica.
3. LandingResolver: per risolvere tutti i tipi di landing necessari all’applicazione
• landing di un website
• landing di uno scriptsite
4. ScriptDependenciesResolver: per scoprire da quali script dipende una certa
pagina
5. ROVPageScraper: per scoprire quali sono i ROA associati ad un AS e lo stato ROV
per ogni prefisso annunciato da tale AS. Informazioni reperibili online6
La definizione dei resolver è stata inserita nel pacchetto /entities/resolvers, men-
tre gli oggetti definiti per rappresentare i risultati di tali resolver sono stati posti
nel pacchetto /entities/resolvers/results. La creazione delle istanze dei resol-
ver, la loro concatenazione logica e la definizione dell’input iniziale è svolta dall’oggetto
ApplicationResolversWrapper. Questo oggetto funge sia da contenitore di tutti i re-
solver dell’applicazione, sia da entry point per invocare l’esecuzione di ognuno di loro.
Avere un oggetto unico in cui concentrare tutte le funzionalità offerte dai resolver è anche
comodo per settare i flag dell’applicazione ed i vari risultati dei resolver come attribu-
ti di tale oggetto. In maniera simile alla classe ApplicationResolversWrapper è stata
definita la classe DatabaseEntitiesCompleter la cui istanza esegue un sottoinsieme
delle funzioni di ApplicationResolversWrapper, in particolare deve eseguire elabora-
zioni molto più mirate rispetto all’altro poiché, come dice il nome stesso, è l’entità che
si prende carico di completare le risoluzioni incomplete di una elaborazione precedente.
L’intero svolgimento di un’esecuzione dell’applicativo può essere schematizzato in
uno schema di flusso diviso, per semplicità, in 3 parti:
1. Preambolo
• fare riferimento alla figura 3.1 per chiarezza
• dopo aver letto le liste date in input, per i website si ha l’esecuzione del
codeLandingResolver così da conoscere i landing name, mentre per i mail do-
main si ha che il DnsResolver determinerà i mailserver corrispondenti. Que-
ste due operazioni avvengono concettualmente in parallelo, ma nell’effettiva
esecuzione del programma si avrà prima l’elaborazione relativa ai website
5
https://iptoasn.com/
6
all’URL: https://stats.labs.apnic.net/roa/ASXXX?c=IT&l=1&v=4&t=thist&d=thisd nel quale
si sostituiscono le 3 XXX con il numero dell’AS desiderato
12

19. 3| Realizzazione
• dai risultati di entrambi si mettono assieme tutti i nomi di dominio estratti.
2. Parte centrale
• fare riferimento alla figura 3.2 per chiarezza
• dai nomi di dominio usciti dal preambolo si ha il DnsResolver che ricava le
dipendenze dalle zone di ognuno di essi
• sempre dai nomi di dominio si considerano solo i server e si risolve ogni indi-
rizzo IP in un AS utilizzando il database scaricato come indicato in sezione
3.1
• il passo successivo considera ogni landing page (sia partendo da HTTP che
HTTPS) per ogni website e risolve le dipendenze dagli script
• da ogni script si estrae lo scriptsite e per ognuno di essi, mediante il
LandingResolver, si risolve lo script server
• il passo finale consiste di nuovo nell’estrazione dei nomi di dominio dai risultati
del LandingResolver
3. Epilogo
• fare riferimento alla figura 3.3 per chiarezza
• dai nomi di dominio usciti dalla parte centrale si raccolgono le dipendenze
dalle zone
• sempre dai nomi di dominio si considerano solo i server e si risolve ogni
indirizzo IP in un AS
• a questo punto, prendendo i risultati totali salvati nell’oggetto ApplicationResolvers
Wrapper, si esegue l’elaborazione ROA
• come ultimo passo del programma, tutti i risultati vengono inseriti nel
database
13

20. 3| Realizzazione
Figura 3.1: Diagramma di flusso preambolo
Figura 3.2: Diagramma di flusso parte centrale
Figura 3.3: Diagramma di flusso epilogo
14

21. Capitolo 4
Database
4.1 Struttura
Nonostante la moltitudine di entità definite nel contesto applicativo, molte condividono
la natura dell’informazione caratterizzante che rappresentano. Quindi per ogni entità si
può individuare una relazione fondamentale rispetto un’altra entità che si può definire
più basilare. In particolare queste entità base si possono classificare come:
• Nome di dominio:
– mail domain
– mailserver
– nameserver
– webserver
– scriptserver
– zona: caso speciale gestito diversamente
• URL:
– website
– scriptsite
• Indirizzo IP
• Network IP
• Autonomous System
• ROV
15

22. 4| Database
In base a queste considerazioni si è quindi deciso prima di definire le entità base e
poi, come entità dipendenti, le effettive entità citate durante il lavoro svolto. C’è stata
una sola eccezione, ovvero l’entità zone la quale è rappresentata totalmente a parte
considerata la rilevanza nella raccolta delle dipendenze.
Come anticipato nella sezione 2.1, per far persistere le informazioni mancanti dovute ad
una generica risoluzione incompleta si possono avere dei valori null in alcuni punti dello
schema. Essi sono indicati con una linea tratteggiata nello schema ER, in figura 4.1.
Figura 4.1: Schema ER
La gestione dei RR di tipo CNAME ha introdotto alcune complicazioni nella pro-
gettazione dello schema e nella realizzazione delle query. Guardando allo schema, se un
utente volesse conoscere da quali indirizzi IP si accede ad un webserver, non è sufficiente
interrogare la relazione access in quanto questa non contiene le informazioni relative ai
CNAME, le quali invece sono descritte nella relazione alias. Il corretto funzionamento
della risoluzione di un access path quindi consiste nel ciclare ricorsivamente tutti i nomi
di dominio facenti parte di tutti i RR CNAME necessari prima di arrivare all’ultimo, il
quale presenterà finalmente la risoluzione (e quindi delle righe nella relazione access).
16

23. 4| Database
Esempio Supponiamo di aver eseguito un’elaborazione contenente la risoluzione (an-
data a buon fine) dell’access path del web server www.youtube.com. Supponiamo di
volere estrarre dal database l’access path di questo web server. Se si interrogasse subi-
to la relazione access path non si troverebbe alcuna riga corrispondente al web server
ricercato. Questo perché il RR di tipo A per www.youtube.com prevede prima il RR:
www.youtube.com CNAME youtube-ui.l.google.com.
Poi:
youtube-ui.l.google.com. A 142.250.184.110, 142.250.184.78, ...
Perciò nel database bisogna prima cercare, sempre attraverso la relazione alias, tutti
gli alias della catena di RR CNAME precedenti alla risoluzione.
Ovviamente nella sezione relativa alle interrogazioni, ne verrà presentata una che
implementa proprio questa funzione.
Esiste un altro caso in cui il meccanismo appena presentato viene declinato in ma-
niera particolare all’interno del database: quello in cui si incontrano RR CNAME in una
query di tipo NS. Essendo zone un’entità a parte rispetto domain_name, lo scenario che
si viene a creare è molto simile a quello descritto precedentemente per l’access path: per
ogni RR CNAME bisogna ciclare ricorsivamente sulla relazione alias ed alla fine inter-
rogare la relazione alias_to_zone la quale lega l’ultimo nome di dominio a quello che
corrisponde alla zona.
Esempio Supponiamo di voler interrogare il database per sapere se cdn-auth.digidentity.eu.
è una zona: se facessimo una ricerca nell’entità zone non troveremmo nessuna riga cor-
rispondente.
Questo perché cdn-auth.digidentity.eu. non ha un RR NS, ma è nome canonico del
RR CNAME:
cdn-auth.digidentity.eu. CNAME d1hljz92zxtrmu.cloudfront.net.
Solo dopo abbiamo:
d1hljz92zxtrmu.cloudfront.net. NS ns-530.awsdns-02.net., ..
Perciò nel database bisogna prima cercare, sempre attraverso la relazione alias, tutti i
nomi di dominio della catena di RR CNAME prima di arrivare alla risoluzione nella re-
lazione alias_to_zone.
Ovviamente nella sezione relativa alle interrogazioni, ne verrà presentata una che
implementa proprio questa funzione.
17

24. 4| Database
4.2 Gestione del database
Come detto nella sezione 2.2 si è utilizzato l’ORM peewee per definire ed interagire con
il database. Tutto il codice relativo ad esso è contenuto nel pacchetto /persistence.
In particolare il file /persistence/BaseModel.py contiene le informazioni per definire
a quale DBMS ci si debba collegare. Esse consistono in:
1. tipo di DBMS utilizzato
2. trattando con un ORM, il riferimento al database utilizzato prenderà forma in
un oggetto (oggetto database). Tale oggetto è istanza di una delle classi for-
nite da peewee in corrispondenza con i DBMS supportati. Nel caso sviluppa-
to abbiamo utilizzato SQLite come DBMS, perciò avremo un’istanza della classe
SqliteDatabase
3. opzioni da settare nell’oggetto database. Nel caso sviluppato abbiamo utilizzato
SQLite come DBMS, perciò è stato settato solo il percorso del file results.sqlite
citato nella sezione 3.1
4. la definizione di ogni entità e relazione del database. Queste prendono forma in
classi a sè stanti, i cui attributi sono istanze di oggetti corrispondenti agli attributi
nel mondo SQL.
Esempio vogliamo definire l’entità autonomous_system la quale presenta 2 attri-
buti: un intero da utilizzare come chiave primaria ed una stringa per rappresentare
una breve descrizione.
from peewee import TextField, IntegerField
...
class AutonomousSystemEntity(BaseModel):
number = IntegerField(primary_key=True)
description = TextField()
class Meta:
db_table = ’autonomous_system’ # nome effettivo
tabella
...
18

25. 4| Database
5. la classe BaseModel, molto importante poiché conterrà come metadato il riferi-
mento all’oggetto database. Ogni entità che definiremo in futuro estenderà proprio
BaseModel per trasmettere il collegamento al database al proprio interno.
Esempio nel programma sviluppato prende forma esattamente nel seguente
modo:
from peewee import Model
...
class BaseModel(Model):
class Meta:
database = db # db riferimento all’oggetto
database
...
6. una volta definite le classi che rappresentano tutte le tabelle, bisogna crearle
sull’oggetto database attraverso il metodo create_tables
Le possibilità di utilizzo e personalizzazione vanno molto oltre quello appena
esplicato, quindi si consiglia sempre la lettura della documentazione ufficiale1
.
Dopo aver visto come vengono definite le entità utilizzando peewee appare chiaro
che il codice sorgente dell’applicazione presenta 2 facce della stessa medaglia: la parte
in cui si svolge l’elaborazione utilizzando gli oggetti definiti come entità e la parte di
persistenza dei dati dove le stesse entità appena citate prendono forma mediante istanze
di oggetti definiti nel file /persistence/BaseModel.py. Per facilitare l’utilizzo delle
entità del database, il pacchetto /persistence è costituito da tanti file quanti sono le
entità/relazioni del database, i cui nomi iniziano per helper_. In ognuno di questi file
sono presenti metodi statici che permettono di fare operazioni sul database da qualsiasi
parte del codice senza il bisogno di avere il riferimento all’oggetto database. Nel definire
questi metodi statici si è cercato di utilizzare un pattern universale:
1. qualsiasi metodo definito all’interno del file helper_xxx avrà come output solo
oggetti di tipo xxx (o Collection di oggetti di tipo xxx). In qualche raro caso
non è vero, ovvero:
• nei metodi che eliminano una entità
1
http://docs.peewee-orm.com/en/latest/
19

26. 4| Database
• metodo resolve_access_path in helper_domain_name
• metodo resolve_reversed_access_path in helper_ip_address
2. il metodo per creare l’entità/relazione del file è detto insert(...): il metodo si
preoccupa prima di cercare se esiste già un entità con la stessa chiave primaria,
sennò la inserisce. In entrambi i casi l’entità risultante viene ritornata. C’è una
differenza sistematica nella definizione di questo metodo:
• per le entità il metodo richiederà solo dati sotto forma di tipi primari come
stringhe, numeri ...
• per le relazioni invece sono richiesti i riferimenti delle entità a cui fa riferimento
3. il metodo per cercare le entità get(...)
4. il metodo per selezionare tutte le righe di una entità/relazione get_everyone():
ritorna un insieme con tutte le righe al proprio interno
5. il metodo per selezionare le entità/relazioni non completamente risolte get_unresolved():
le entità/relazioni che prevedono questa funzionalità sono
Nome oggetto Nome tabella
WebSiteEntity web_site
IpAddressDependsAssociation ip_address_depends
ScriptSiteEntity script_site
NameServerEntity name_server
ScriptWithdrawAssociation script_withdraw
MailDomainEntity mail_domain
In aggiunta al pattern si sono definiti molti metodi per effettuare operazioni più elaborate
la cui firma cerca di essere il più autoesplicativa possibile.
Tra tutti i cosiddetti helper_ file, si è scelto di crearne uno appositamente per
effettuare gli inserimenti di tutti i risultati di un’esecuzione del programma: il file
helper_application_results.
20

27. 4| Database
4.3 Interrogazioni
Dentro i file helper_ molti metodi eseguono interrogazioni di vario genere, i cui nomi
tendenzialmente iniziano con get_. Di seguito si presenta un esempio di iter logico della
metodologia con la quale definire una query.
Esempio Si deve definire il metodo per interrogare le dipendenze da zone di un nome
di dominio. Possiamo dare come input il nome di dominio sotto forma di entità del
database, ovvero l’oggetto DomainNameEntity. Si andrà quindi a scrivere all’interno del
file helper_zone il metodo:
def get_zone_dependencies_of_entity_domain_name(dne: DomainNameEntity) ->
Set[ZoneEntity]:
La query consiste nel fare un SELECT dell’entità domain_name_dependencies da cui
ritorneremo le entità zone. Sapendo che peewee costruisce gli oggetti rappresentanti
relazioni con già al proprio interno il riferimento all’oggetto delle entità collegate al-
la relazione, basterà interrogare la relazione domain_name_dependencies ed accedere
all’attributo dell’entità zone. Perciò la query sarà implementata nella seguente maniera:
def get_zone_dependencies_of_entity_domain_name(dne: DomainNameEntity) ->
Set[ZoneEntity]:
result = set()
query = DomainNameDependenciesAssociation.select()
.where(DomainNameDependenciesAssociation.domain_name == dne)
for row in query:
result.add(row.zone)
return result
Nel caso in cui si volesse eseguire la query da una stringa qualsiasi, basterà creare un
nuovo metodo il quale prima cercherà un DomainNameEntity corrispondente alla stringa
di input e poi invocherà il metodo appena definito per evitare duplicazione di codice.
def get_zone_dependencies_of_entity_domain_name(dne: DomainNameEntity) ->
Set[ZoneEntity]:
result = set()
query = DomainNameDependenciesAssociation.select()
.where(DomainNameDependenciesAssociation.domain_name == dne)
for row in query:
result.add(row.zone)
return result
21

28. 4| Database
def get_zone_dependencies_of_string_domain_name(domain_name: str) ->
Set[ZoneEntity]:
dne = helper_domain_name.get(domain_name)
return get_zone_dependencies_of_entity_domain_name(dne)
Nel caso di entità DomainNameEntity non trovata verrà lanciata l’eccezione DoesNotExist.
Nella precedente sezione 4.1 si è parlato di 2 casi di ricerca speciali i quali vengono
implementati da delle query dedicate; queste consistono nei metodi:
1. resolve_access_path appartenente al file /persistence/helper_domain_name
2. resolve_zone_object appartenente al file /persistence/helper_zone
Entrambi ritornano i risultati sottoforma di tupla per includere anche la lista di nomi di
dominio attraversata per arrivare al risultato.
Per l’analisi dei dati si sono sviluppate 8 interrogazioni poste tutte nel file
/persistence/helper_application_queries. Ognuna di esse produce un file .csv
il quale verrà creato nella cartella output.
1. query #1: ritorna le informazioni architetturali relative alle zone. Il nome del
file risultante sarà zone_infos.csv
Tabella 4.1: Formato file .csv query #1
zone_name #nameservers #networks #as
nome della zona numero totale di
indirizzi IP relativi
ai nameserver della
zona
numero totale delle
netowrk in cui sono
posti gli indirizzi IP
numero totale egli
AS in cui sono
poste le network
2. query #2: ritorna le dipendenze tra website e zone dirette. In particolare per
ogni website si considerano come zone dirette:
• la zona diretta della seconda componente relativa all’URL del website
• le zone dirette dei propri webserver
Ogni website quindi potrà occupare più righe. Il nome del file risultante sarà
web_sites_direct_zone_dependencies.csv
Tabella 4.2: Formato file .csv query #2
web_site zone_name
website nome della zona
22

29. 4| Database
3. query #3: ritorna le dipendenze tra mail domain e zone dirette. In particolare
per ogni mail domain si considerano come zone dirette:
• la zona diretta del mail domain
• le zone dirette dei propri mailserver
Ogni mail domain quindi potrà occupare più righe. Il nome del file risultante sarà
mail_domains_direct_zone_dependencies.csv
Tabella 4.3: Formato file .csv query #3
mail_domain zone_name
mail domain nome della zona
4. query #4: ritorna le dipendenze tra website e zone. Ogni website occuperà più
righe. Il nome del file risultante sarà web_sites_zone_dependencies.csv
Tabella 4.4: Formato file .csv query #4
web_site zone_name
website nome della zona
5. query #5: ritorna le dipendenze tra mail domain e zone. Ogni mail domain occu-
perà più righe. Il nome del file risultante sarà mail_domains_zone_dependencies.csv
Tabella 4.5: Formato file .csv query #5
mail_domain zone_name
mail domain nome della zona
23

30. 4| Database
6. query #6: ritorna le dipendenze relative all’access path per ogni mail domain. Il
nome del file risultante sarà mail_domains_dependencies.csv
Tabella 4.6: Formato file .csv query #6
mail_domain #mailservers #networks #as
mail domain numero totale di
indirizzi IP relativi ai
propri mailserver
numero totale di
network in cui gli
indirizzi IP sono
posti
numero totale di AS
in cui le network
sono poste
7. query #7: ritorna le dipendenze relative all’access path per ogni website. Il no-
me del file risultante sarà web_servers_dependencies.csv
Tabella 4.7: Formato file .csv query #7
webserver #addresses #networks #as
webserver numero totale di
indirizzi IP
numero totale di
network in cui gli
indirizzi IP sono
posti
numero totale di AS
in cui le network
sono poste
8. query #8: ritorna le dipendenze in base alle network. La query è abbastanza
articolata (presenta 11 colonne in totale), motivo per il quale la tabella esplicativa
è divisa in 2. Il nome del file risultante sarà networks_dependencies.csv
Tabella 4.8: Formato file .csv query #8 parte 1
network as #webser-
vers
#mailser-
vers
#nameser-
vers
#direct_zo-
ne_name-
servers
network as numero to-
tale di web-
server in
tale network
numero to-
tale di mail-
server in
tale network
numero to-
tale di na-
meserver in
tale network
numero to-
tale di na-
meserver
di zone di-
rette in tale
network
24

31. 4| Database
Tabella 4.9: Formato file .csv query #8 parte 2
#zones_enti-
re_contained
#nr_websites #nr_maildo-
mains
#ap_websites #ap_maildo-
mains
numero totale
di zone i cui
nameserver
sono tutti in
tale network
numero totale
di website i cui
nameserver
delle zone di-
rette sono tutti
in tale network
numero totale
di mail domain
i cui name-
server delle
zone dirette
sono tutti in
tale network
numero totale
di website i
cui webserver
sono tutti in
tale network
numero totale
di mail domain
i cui mailserver
sono tutti in
tale network
25

32. 4| Database
4.4 Persistenza degli errori
Di seguito viene riportata una tabella la quale riassume come vengono salvati nel
database gli errori che si possono incontrare durante l’esecuzione del programma.
Tabella 4.10: Tabella persistenza degli errori
Descrizione er-
rore
Resolver Inserimento nel database
non viene risolto
un mail domain
il DnsResolver non riceve
una risposta per la query
di tipo MX relativa al mail
domain
dopo aver inserito l’entità
mail_domain, si inserirà nella rela-
zione mail_domain_composed una
riga per il mail domain con il valore
null settato nella colonna che riferisce
l’entità mail_server
non viene risolto
un nameserver
il DnsResolver non rice-
ve una risposta per la que-
ry di tipo A relativa al
nameserver
dopo aver inserito l’entità name_server
la quale implica l’inserimento anche del-
l’entità domain_name, si inserirà nel-
la relazione access una riga per il
domain_name con il valore null setta-
to nella colonna che riferisce l’entità
ip_address
un website non
riesce ad effettua-
re il landing me-
diante il protocol-
lo HTTP
il LandingResolver lancia
un’eccezione quando viene
eseguita la risoluzione del
landing relativo al website
utilizzando HTTP
dopo aver inserito l’entità web_site, si
inserirà nella relazione web_site_lands
una riga per il web_site con l’attribu-
to https settato al valore 0 ed il valore
null nella colonna che riferisce l’entità
web_server
un website non
riesce ad effettua-
re il landing me-
diante il protocol-
lo HTTPS
il LandingResolver lancia
un’eccezione quando viene
eseguita la risoluzione del
landing relativo al website
utilizzando HTTPS
dopo aver inserito l’entità web_site, si
inserirà nella relazione web_site_lands
una riga per il web_site con l’attribu-
to https settato al valore 1 ed il valore
null nella colonna che riferisce l’entità
web_server
26

33. 4| Database
uno scriptsite non
riesce ad effettua-
re il landing me-
diante il protocol-
lo HTTPS
il LandingResolver lan-
cia un’eccezione quando
viene eseguita la risolu-
zione del landing relativo
allo scriptsite utilizzando
HTTPS
dopo aver inserito l’entità
script_site, si inserirà nella rela-
zione script_site_lands una riga
per il script_site con l’attributo
https settato al valore 1 ed il valore
null nella colonna che riferisce l’entità
script_server
uno scriptsite non
riesce ad effettua-
re il landing me-
diante il protocol-
lo HTTP
il LandingResolver lan-
cia un’eccezione quando
viene eseguita la risolu-
zione del landing relativo
allo scriptsite utilizzando
HTTP
dopo aver inserito l’entità
script_site, si inserirà nella rela-
zione script_site_lands una riga
per il script_site con l’attributo
https settato al valore 0 ed il valore
null nella colonna che riferisce l’entità
script_server
un indirizzo IP
non viene risolto
nel database IP
route-AS
il resolver IpAsDatabase
lancia un’eccezione quan-
do viene eseguita la risolu-
zione nel cercare di risolve-
re l’indirizzo IP in una riga
del database
dopo aver inserito l’entità
ip_address, si inserirà nella rela-
zione ip_address_depends una riga
per ip_address con il valore null set-
tato nella colonna che riferisce l’entità
ip_range_tsv
un indirizzo IP
non viene risol-
to tra i prefis-
si annunciati nei
ROA dell’AS a
cui appartiene
il resolver
ROVPageScraper lancia
un’eccezione quando viene
eseguita la risoluzione
dopo aver inserito l’entità
ip_address, si inserirà nela rela-
zione ip_address_depends una riga
per ip_address con il valore null set-
tato nella colonna che riferisce l’entità
ip_range_rov
non è possibi-
le raccogliere
gli script da
cui dipende un
website
ScriptDependencies
Resolver lancia un’ec-
cezione quando viene
eseguita la risoluzione
dopo aver inserito l’entità web_site, si
inserirà una riga per web_site nella re-
lazione script_withdraw con il valore
null settato nella colonna che riferisce
l’entità script
27

34. 4| Database
28

35. Capitolo 5
Analisi
5.1 Dataset
Si sono considerati 2 tipi di dati:
Mail domain della pubblica amministrazione Un dataset per 4 diverse nazioni: Italia
(IT), Germania (DE), Gran Bretagna (UK) e Stati Uniti d’America (US). Per il caso
italiano si sono considerati tutti i domini del sistema PEC (Posta Elettronica Certificata
1
); questo servizio permette ai cittadini di mandare email con valore legale in modo
analogo ad una raccomandata con ricevuta. Il dataset è stato scaricato dal catalogo
Opendata della pubblica amministrazione italiana 2
il 27 gennaio 2022. La lista contiene
60098 indirizzi email dai quali si distinguono 4888 mail domain. Tutti questi mail domain
appartengono al sistema italiano PEC.
Per UK, DE, US si sono utilizzate le liste di website utilizzate nell’analisi del paper [1];
in particolare, per ogni stringa si è tolto il suffisso "www" ed il nome risultante è stato
utilizzato come candidato mail domain. Tutto ciò è risultato in una lista di 216 mail
domain per DE, di 467 per UK e 408 per US.
SPID IdP per la pubblica amministrazione italiana Lo SPID (Sistema Pubblico di
Identità Digitale 3
) è un sistema digitale utilizzato in Italia per accedere ai servizi della
pubblica amministrazione ed a quelli offerti da entità private (che presentano validità
legale) il quale garantisce legalmente l’identità dell’utente che sta accedendo. Il sistema
è basato sul protocollo SAML con l’intenzione di migrare su OAuth. Si è scaricata la
lista ufficiale di 9 IdP il 3 febbraio 2022.
Per avere un metro di confronto (baseline) nell’analizzare questi IdP, si è considerata
un’altra lista composta dagli IdP di:
1
https://en.wikipedia.org/wiki/Certified_email
2
https://indicepa.gov.it/ipa-dati/dataset/elenco-pec
3
https://www.spid.gov.it/en/
29

36. 5| Analisi
1. Google
2. Facebook
3. Twitter
4. Microsoft
5. Amazon
6. Netflix
7. Postoffice, Digidentity (IdP per Verify, l’analogo di SPID in UK)
8. Cl@ve (l’analogo di SPID in Spagna)
5.2 Metodologia
D’ora in poi col termine item ci si può riferire a: un mail domain, un website od un
pagina di login di un IdP.
Dipendenze nella name resolution Per ogni item si raccoglieranno tutte le zone da
cui dipende nella propria name resolution. In altre parole, si collezionano tutte le zone
le quali sono coinvolte nella traduzione del nome di dominio corrispondente dell’item
all’indirizzo IP di uno dei server responsabili di tale item (ovvero mailserver per un
mail domain, webserver in ogni altro caso). Nei prossimi paragrafi si raggrupperanno le
dipendenze risultanti in base all’architettura di ogni zona in termini di:
• numero di nameserver
• numero di network dove tali nameserver sono posti
• numero di autonomous system che controllano tali network
L’architettura di una zone consiste sempre nel risultato di un trade-off: un’alta ridon-
danza implica un’alta robustezza in termini di fallimenti od attacchi DoS, ma dall’altra
parte implica anche un maggior numero di possibilità per l’attaccante. L’effettiva porta-
ta di un attacco ad un nameserver, ad una network od a un autonomous system per un
dato item, dipende da quanta attività relativa alle traduzioni per il dato item attraversa
l’entità attaccata. In questa analisi non si cerca di quantificare o stimare tali attività,
ma si costruisce l’insieme di tutte le dipendenze dato un item, ovvero tutte le compo-
nenti che potrebbero influenzare la traduzione di tale item negli indirizzi IP associati in
modo da capire quali siano i principi di progettazione odierni.
30

37. 5| Analisi
Dipendenze nella name resolution (zone dirette) Si sono isolate dalle potenziali
dipendenze appena descritte quelle dalle zone dirette, più specificatamente:
• per un web site e per un IdP, sia U l’URL corrispondente e sia N il nome del
webserver dove il client viene pilotato dopo ogni redirection HTTP o RR CNAME
da seguire per ottenere l’indirizzo IP del webserver (la seconda componente di U ed
N possono anche non combaciare). Si considera come zona diretta sia quella della
seconda componente di U che quella di N.
• per un mail domain, si considera come zona diretta sia quella del mail domain che
quella di ogni mailserver.
Dipendenze nel access path Per ogni item, si ipotizza sia avvenuta la traduzione del
nome di dominio di tale item negli indirizzi IP assegnati per l’accesso. A questo punto
si associa ogni item alle network ed autonomous system associati agli indirizzi IP. Poi si
raggruppano le dipendenze risultanti in termini di:
• numero di indirizzi IP
• numero di network dove tali nameserver sono posti
• numero di autonomous system che controllano tali network
Più specificatamente:
• per un website e per un IdP, si considera l’indirizzo IP del webserver corrispondente
e di ogni sua possibile replica.
• per un mail domain, si considera l’indirizzo IP di tutti i mailserver di tale mail
domain e di ogni replica possibile di tali mailserver.
31

38. 5| Analisi
5.3 Risultati
Ridondanza nella name resolution per i mail domain
Heatmap: #Nameserver vs #Network Per ogni zona si conta il numero di mail domain
i quali dipendono da tale zone. Si sono raggruppate le zone in base al loro numero
di nameserver e network dove sono posti tali nameserver. Per ogni combinazione di
(#Nameserver, #Network) si sono sommati il numero di mail che dipendono dalle zone
con tale combinazione. Infine i valori sono stati normalizzati in base al numero totale di
mail domain per ogni dataset.
Figura 5.1: Ridondanza nella name resolution per mail domain: #Nameserver vs #Network
Le specifiche DNS stabiliscono che ogni zona debba avere almeno 2 nameserver in 2
network diverse. Tutti i dataset chiaramente eccedono tale requisito in maniera consi-
derevole. Ciò significa una maggiore replicazione che rende l’infrastruttura più robusta
rispetto fallimenti ed attacchi DoS. D’altro canto però aumenta il perimetro di sicurezza
da difendere.
32

39. 5| Analisi
Heatmap: #Network vs #AS Stessa analisi del paragrafo precedente, con l’unica diffe-
renza che ora le zone sono raggruppate in base al numero di network ed al numero di AS
in cui tali network sono poste.
Figura 5.2: Ridondanza nella name resolution per mail domain: #Network vs #AS
Tutti i dataset tranne DE presentano dei picchi di concentrazione. IT è maggiormente
concentrato in (4, 2). UK è peculiare poiché presenta una percentuale molto alta nei
casi di (2, 1) e (1, 1) rendendo quindi il perimetro di sicurezza molto stretto. Il caso US
presenta una distribuzione con varie concentrazioni e soprattutto è l’unico caso in cui
è presente una concentrazione alta sui valori (13, 13) ai quali corrisponde un perimetro
molto grande da difendere.
33

40. 5| Analisi
Heatmap: #Nameserver vs #Network solo da zone dirette Analisi uguale alle prece-
denti solo che per ogni mail domain si sono contate solo le dipendenze da zone dirette.
Raggruppamento zone dirette in base al numero di nameserver ed al numero di network
dove sono contenuti tali nameserver.
Figura 5.3: Ridondanza nella name resolution per mail domain: #Nameserver vs #Network
solo da zone dirette
Tutti i casi presentano dipendenze da zone che rispettano strettamente i requisiti, ma
la maggioranza li eccedono. Rispetto la heatmap della ridondanza nelle name resolution
per tutte le zone si può notare che le zone dirette presentano meno replicazione. Il caso
IT presenta una forte concentrazione nel valore (4, 4) e (2, 2).
34

41. 5| Analisi
Heatmap: #Network vs #AS solo da zone dirette Raggruppamento zone dirette in
base al numero di network ed al numero di AS dove sono posti tali network.
Figura 5.4: Ridondanza nella name resolution per mail domain: #Network vs #AS solo da
zone dirette
Il caso IT presenta anche qua, come nel caso di zone generiche, una forte concentrazione
nel valore (4, 2). Tutti i dataset presentano la maggior parte di zone le cui network
stanno in 2 o 3 AS. Per ogni dataset la percentuale di zone che non rispettano i requisiti
è molto basso.
35

42. 5| Analisi
Dipendenze nella name resolution per i mail domain
Barplot: in base agli AS (solo zone dirette) Per ogni autonomous system si conta il
numero di zone i cui nameserver sono contenuti in tale autonomous system. Per ogni
zona si conta il numero di mail domain che dipendono direttamente da tale zona. Si
sono considerati i 10 autonomous system con la percentuale di mail domain più alta.
Figura 5.5: Dipendenze nella name resolution per mail domain: dagli AS (solo zone dirette)
I casi UK ed US presentano un’alta concentrazione di dipendenze (circa il 25%-30%
del numero totale di mail domain) per l’autonomous system 8075, il quale è gestito da
Microsoft Corporation. Rispetto ai casi IT e DE la differenza è sostanziale, non solo
sull’autonomous system con la concentrazione maggiore. E’ chiaro che, per i casi UK ed
US, riuscire a prendere il controllo di uno degli autonomous system con la concentrazione
più alta, implicherebbe influenzare la name resolution di un grande insieme di mail
domain.
36

43. 5| Analisi
Ridondanza nell’access path per i mail domain
Heatmap: #Mailserver vs #Network
Figura 5.6: Ridondanza nell’access path per mail domain: #Mailserver vs #Network
Per chiarezza alcuni dati sono stati omessi e sono riportati sotto forma di tabella di
seguito:
Dataset #mailservers #networks %maildomains
UK 20 3 0.008
UK 60 17 0.002
US 16 1 0.0023
US 18 2 0.0046
Tutti i casi presentano un’altissima concentrazione nei valori bassi (2, 2) e (1, 1). In
particolare il caso IT presenta valori quasi esclusivamente nei 2 appena citati. Questa
significa poca replicazione e quindi una maggiore suscettibilità agli attacchi DoS. In tutti
i dataset ci sono zone che non rispettano i requisiti. I casi UK ed US presentano, rispetto
gli altri 2, più casi di dipendenze con tante repliche. Inoltre, sebbene in quantità minime,
dalla tabella si può notare che US ed UK presentano casi con una replicazione molto
alta concentrata in poche network.
37

44. 5| Analisi
Heatmap: #Network vs #AS
Figura 5.7: Ridondanza nell’access path per mail domain: #Network vs #AS
Per chiarezza alcuni dati sono stati omessi e sono riportati sotto forma di tabella di
seguito:
Dataset #networks #as %maildomains
UK 17 2 0.002
US 11 3 0.0023
Tendenzialmente tutti i casi presentano la maggior parte della concentrazione nei valori
bassi (2, 1) e (1, 1), solo UK ed US mostrano qualche mail domain che prevede dipen-
denze le cui network sono raggruppate in pochi AS. Tutti i dataset presentano quasi
esclusivamente dipendenza da un solo AS. Questo significa che un possibile attacco DoS
ad un AS potrebbe bloccare il traffico riguardante l’accesso di molti mail domain.
38

45. 5| Analisi
Dipendenze nell’access path per i mail domain
Barplot: in base agli AS (solo zone dirette)
Figura 5.8: Dipendenze nell’access path per mail domain: dagli AS (solo zone dirette)
I tutti i casi è presente un AS da cui dipende almeno il 20% dei mail domain dei rispettivi
totali. Nel caso italiano addirittura si tocca quasi il 60%. Una concentrazione così alta
potrebbe coincidere con una scelta strategica per avere un controllo maggiore su un
perimetro più piccolo e quindi più facile da gestire.
39

46. 5| Analisi
Barplot: in base alle network (solo zone dirette)
Figura 5.9: Dipendenze nell’access path per mail domain: dalle Network (solo zone dirette)
Anche in questo grafico il caso italiano presenta una concentrazione più alta in una
singola network (circa il 20%) rispetto gli altri casi. Il dataset IT quindi presenta delle
dipendenze molto concentrate nel contesto dell’access path rispetto agli altri dataset sia
in termini di network che di autonomous system. Il dataset DE segue la distribuzione
italiana ma con dei valori minori di concentrazione.
40

47. 5| Analisi
Ridondanza nell’name resolution per gli IdP
Scatterplot: #Nameserver vs #Network Essendo il numero di dati appartenenti ai
dataset relativi agli IdP nettamente inferiore rispetto quelli dei mail domain, si è deciso
di plottare i dati utilizzando uno scatterplot. L’analisi è stata eseguita utilizzando la
stessa metodologia presentata per i mail domain, indicando però i numeri assoluti e non
le percentuali.
Figura 5.10: Ridondanza nella name resolution per IdP: #Nameserver vs #Network
Il dataset BASELINE mostra dei dati che esprimono una maggiore replicazione rispet-
to il dataset IT, anche se è visibile un caso di dipendenza da zona con 2 nameserver
ed 1 sola network; questa non rispetta i requisiti ed in particolare si tratta del website
se-pasarela.clave.gob.es/WebPortal/login.xhtml. Il caso IT presenta una concen-
trazione molto alta nei valori (2, 2) i quali rispettano strettamente i requisiti, mentre i
website restanti (tranne uno) li eccedono.
Scatterplot: #Network vs #AS
Figura 5.11: Ridondanza nella name resolution per IdP: #Network vs #AS
Entrambi i dataset presentano una concentrazione in pochi autonomous system. An-
che BASELINE il quale, nonostante la maggior replicazione, si concentra in massimo 2
autonomous system (a parte 2 casi singolari).
41

48. 5| Analisi
Ridondanza nell’access path per gli IdP
Scatterplot: #Nameserver vs #Network
Figura 5.12: Ridondanza nell’access path per IdP: #Webserver vs #Network
IT presenta tutti i webserver nel valore (1, 1) tranne uno: posteid.poste.it che invece
presenta 20 indirizzi IP tutti concentrati in una sola network. Come già detto in pre-
cedenza, questo implica un perimetro più piccolo da difendere ma aumenta il rischio di
non offrire nessun servizio nel caso di attacchi DoS. Anche il caso BASELINE presenta
comunque una concetrazione in poche network (3 al massimo).
Scatterplot: #Network vs #AS
Figura 5.13: Ridondanza nell’access path per IdP: #Network vs #AS
Tutti i dataset mostrano dipendenze da un solo autonomous system.
42

49. Bibliografia
[1] Alberto Bartoli. Robustness analysis of dns paths and web access paths in public
administration websites. Computer Communications, 180:243–258, 2021.
[2] Keith Kirkpatrick. Fixing the internet. Communications of the ACM, 64(8):16–17,
2021.
43