Sei sulla pagina 1di 67

SICUREZZA DEI SISTEMI E DELLE RETI

Sicurezza & reti


Storicamente il grande pubblico ha iniziato a parlare di sicurezza informatica in congiunzione
con la diffusione delle reti. L'evento simbolo Rete/sicurezza dei sistemi è l'Internet Worm (2
novembre 1988). Colpí qualche migliaio di macchine ed è considerato il giorno della perdita
dell'innocenza di Internet.In realtà il problema era già ben noto: la legge grazie alla qualeR.
Morris fu condannato era del 1986.

Tipologie di malware

malware: codice progettato per danneggiare intenzionalmente un sistema, alterandone


funzionalità o dati.

Chi ha interesse a colpire un sistema?


Secondo Verizon 2010 Data Breach Investigations Report (contiene anche i dati dell'USSS) 900
incidenti, 2/3 dei quali non sono mai stati resi pubblici.
I protocolli TCP/IP
Protocolli di base
“SCRITTO A MANO”

PROBLEMI INTRINSECI
Problemi intrinseci in TCP/IP

Non esiste alcuna autenticazione fra le parti, i controlli di integrità sono banali(ci sono solo checksum che
rilevano problemi di trasmissione ma non manomissione volontarie, non hanno proprietà di sciurezza),la
rete è pensata per evitare la congestione ma non al denail of service (Ovvero la possibilità o disponibilità di
non potersi connettere a un determinato nodo).

IP spoofing

si sostituisce/imita un nodo e si prende il suo nodo nella comunicazione

Il campo src dello header ip può essere falsificato senza particolari difficoltà.

Le autenticazioni basate su indirizzi Ip sono particolarmente insicure all’interno di una stessa rete locale.

Se in una rete esistono due nodi con lo stesso indirizzo IP, tipicamente ci sono problemi nelle connessioni,
ovvero che non funzionano, quindi se venegono modificati due nodi e messi con lo stesso indirizzo ip potrà
causare denial of service.

Dal punto di vista dell’attacante

Se è molto facile falsificare il campo sorgente di un pacchetto ip, questo può servire per dos, ma le risposte
andranno al vero nodo titolare: se io metto nel pacchetto un mittente falso, a questo punto le risposte a
quel pacchetto andranno al mittente indicato perché questo stabilisce il protocollo e quindi non vedrò le
risposte.

La falsificazione di un ip non è sufficiente per falsificare per inserirsi a una connessione, se voglio fingermi
un nodo diverso da quello che sono cambiare il numero IP non è sufficiente.

Spoofing in connessione TCP

Cosa serve per inserirsi in una connessione TCP?

Serve l’handshaking:

1) Il cliente manda un richiesta syn al server


2) Questa richiesta syn produce nel server un nuovo pacchetto syn in cui si da un ack della richiesta
ricevuta con un serial number che ci ha mandato il client e producendo un serial number prodotto
dal server
3) A questo punto il client completerà l’handshaking con un ack che è in funzione del serial number
mandato dal server

Se questo serial number del server è imprevedibile, è difficile. Se un attaccante X vuole farsi passare
per un client C deve appunto prevedere questo numero, se non lo può prevedere non può
introdursi alla comunicazione. Se si mandasse un serial number sbagliato, il vero cliente C manderà
un reset al server resettando così la connessione.
Initial Sequence Number
In realtà non è cosi difficile come potrebbe sembrare, per un motivio tecnico, se si va a leggere la
RFC793(che è quella che definisce tcp\ip) i sequence number non sono casuali, ma sono dei
contatori globali connessione di quella macchina, ISN va incrementato circa 1 volta ogni 4
microsecondi per evitare confusioni con connessioni duplicate. Se voglio prevedere quando sarà il
prossimo ISN faccio una connessione vera, misuro i tempi e più o meno cerco di misurare l’ISN. In
alcuni casi erano ancora più prevedibili, come le kick-off war nella chat IRC negli anni 90.

ISN sicuri
Come fare per non rendere isn non prevedibile?
Non può essere completamente casuale!
Una soluzione possibilie è quella di RFC1948, in cui si mantiene il contatore globale, ma si ha un
contatore diverso per ogni quadrupla di connessione, in questa maniera si una sorta di contatore
locale a ogni quadrupla o tipologia di connessione. In questo il modo il serial number diventa
imprevedibile all’interno di una quadrupla.
Per ottenere questa cosa si mantiene un contatore incrementato ogni 4 secodni ma a questo si
aggiunge un qualche numero calcolato con qualche funzione di hash crittografica specifica del
server e non prevedibile dall’attaccante, quindi dovrà essere un hash della quadrupla di
localhost,localport,remotehost, remot port e in aggiunta qualche altra informazione segreta del
server non prevedibile.
Quindi
ISN = M + FS(localhost,localport,remotehost,remoteport)
M = contatore incrementato ogni 4 secondi
FS = funzione crittografica hash del server

Frammentazione
I dati TCP sono spesso frammentati e riassemblati dal destinatario.
Un man-in-the-middle può alterare i frammenti: in questo caso non serve indovinare i sequence
number. I checksum sono facili da aggiustare perché sono semplici controlli d’errore di trasmissione.

SYN flooding
il syn flooding o inondazione di SYN che è un attacco che permette di aver un dos, immaginiamo di
avere un server che è in ascolto su una certa porta, se riceve una richiesta syn , risponde con un syn
ack per iniziare un tree-way-hadshake. Per un certo tempo il server deve tenere traccia di questo
inizio di connessione(spesso 75s),per questi 75 s occorerà traccia di inizio di questa connessione,
tipicamente una coda in cui ci sono aperte le connessioni. Queste code sono molto piccole, a volte
solo di 5 elementi.
Se la coda è piena non si accettano più connessioni e il server rimane bloccato.
Vista da un attaccante, se io mando dei syn e arriveranno dei syn ack e io non chiudo il tree-way-
hadshake con l’ack, il server potrà rimanere bloccato.
Questo attacco viene addirittura meglio se falsifico l’ip (ip spoofing).

Per evitare l’attacco si può usare i SYN-cookie: Il SYN cookie è una tecnica per resistere a un attacco
Flood SYN (attacco SYN a valanga/allagamento), viene definita dall'inventore Daniel J. Bernstein "scelta
particolare di sequenze iniziali TCP, da parte dei TCP servers In particolare, l'uso dei SYN cookies permette a
un server di evitare la caduta della connessione quando la coda SYN è piena. Invece il server si comporta
come se la coda SYN fosse stata ampliata. Il server manda indietro la rispettiva risposta SYN+ACK al client,
ma scarta l'entrata in coda del SYN. Se il server poi riceve un conseguente ACK di risposta dal client, è
capace di ricostruire l'entrata nella coda SYN, grazie alle informazioni codificate nella sequenza TCP

Fingerprinting

L’attaccante ha la possibilità di riconscere “le impronte digitali del nostro sistema”, l’attaccante sa come sono
fatte le implentazioni del sistema sottoattcco e và a vedere se c’è qualche vulnaribiltà da sfruttare.

Cercare di capire quali sistemi, stack tcp sono in uso. In fase di difesa voglio che non sia facilmente
distinguile il nostro stack. Non è facile perché gli stack hanno tantissime piccole differenze ed è molto facile
da che stack un pacchetto è stato generato.

Dall’esame(non intrusivo) dei pacchetti di rete è possibile identificare molti dettagli utili negli attacchi.

Esistono tool, come p0f, che esaminando in manienra non intrusiva dei pacchetti rilevati sulla rete senza
alterare nulla, e guardando il contenuto dei pacchetti è possibile identificare il tipo di implementazione in
uso( ad esempio identifica molte implementazioni di stack tcp/ip).

Topologia della rete

È possibile identificare la la topologia della rete sempre grazie alle differenze che esistono tra le varie
implementazioni.

Per esempio i pacchetti hanno un campo TTL (time to live), questo campo permette di evitare che si formino
dei cicli nella trasmissione dei pacchetti, è un contatore che viene decrementanto ad ogni salto della rete,
questo fa si che i pacchetti non girino nella rete.

Il valore iniziale iniziale del TTL non è specificato, quindi implementazioni diverse fanno scelte diverse, per
esempio gli stack windows hanno un ttl = 128 e gli stack linux ttl = 64.

Ora immaginiamo di intercettare un pacchetto con un TTl di 80. Questo ci dà molte informzioni, perché già
se è 80 ci dice che non è un TTL di linux percè è maggiore di 80, quindi è windows.

Quindi questo vuol dire che ha viaggiato di 48 hop(salti) perché appunto da 128 è diventato 80.

Questi tipi di ragionamento permette a un attaccante non intrusivo, che semplicemnte è in grado di
esaminare i pacchetti della rete, permette di dare natura sulla rete e sulla topologia, in questo caso diciamo
che la rete ha una distanza di 48 salti.

Attività di ricognizione
Sono attività che ci permettono di conoscere uno stato di una rete, i nodi che la compongono, quali servizi
offrono, quindi come è composta una rete. è un’attività fondamentale sia da punto di vista della difesa sia
dalla parte del punto di vista dell’attaccante.

Il difensore dovrebbe conoscere la “cartografia di reti e servizi”, ma non è sempre così (la rete può essere
grande e aggiornata di continuo, e rende questo difficoltoso per avere una globale conoscenza).
Paradossalmente l’attaccante è avvantaggiato, perché gli è sufficiente una informazione parziale, e tenderà
ad acquisire informazioni parziali cercando ad esempio su google. Le topologie delle reti sono molto
presenti sulla rete: c’è un database WHOIS per tenere traccia dei nomi simbolici, da li è possibile ricavare
molte informazioni di una tipologia di una rete che non conosciamo lo stesso dai record DNS, in alcuni casi il
servizio DNS potrebbe essere configurato per dare informazioni che sarebbero meglio da nascondere.

Scanning
È un attività di scansione comune da parte dei difensori e attaccanti, permette di conoscere qual’ è lo stato
di una rete, i nodi che partecipano e quali servizi offrono.

Ping:

controlla la presenza di un nodo. era stata pensata già dall’inizio dell’architettura TCP/IP, infatti esiste un
protocollo ICMP (internet controll protocoll messagge) studiato per scambiare messaggi di controllo o
diagnostica varia, è un protocollo che gira su TCP/IP, (spesso gli altri protocolli prevedono in situazioni
particolari i messagi ICMP).

ICMP è usato Per esempio se un nodo non è raggiungibile (se i salti con I TTL finiscono, questo pacchetto
non viene più consegnato, nel momento che il TTL è esaurito viene mandato verso il mittente un messaggio
che lo avvisa del mancato invio).

ICMP è un protocollo nato per controllare lo stato di salute della rete e segnalare eventuali errori.

Ping è un messaggio ICMP, è un messaggio di “eco”, si manda un pacchetto eco ICMP a una macchina e il
protoccollo prevede che venga generata una risposta se il nodo è attivo. Quindi per verificare se i nodi di
una rete sono attivi, bisogna “pingarli”, ovviamente deve conoscere un numero IP di una macchina e vedere
se quel ip risponde al ping. Esistono tantissime utility o script per provare tanti numeri IP, e memorizzano gli
IP che rispondono, queste utility di ping massivo fanno ping anche in modalità non ICMP. Spesso le reti
impediscono i messaggi ICMP al loro esterno,filtrando il traffico di rete, per non farli intercettare (il filtraggio
avviene tramite dei filitri che sono i firewall e permettono di filtrare il traffico), ICMP dato che può essere
usato in modo facile per studiare la topologia all’interno di una rete dall’attaccante, vengono disabilitati
all’esterno della rete e viaggiano solo all’interno.

Traceroute:

è l’evoluzione di ping, non usa direttamente il protoccolo ICMP e generalmente usa pacchetti UDP. Sono
pacchetti che sono inviati nella rete con l’obbiettivo di studiare la topologia. Si fa un pacchetto con TTL = 1
(ricordiamo che ci dice quanti gateway attraversare prima di smettere di provarci, mormalmente i ttl sono
alti 60-80 per raggiungere nodi lontani ), è 1 vuol dire che superà solo il primo gateway presente, dopodichè
il pacchetto sarà eliminato dal traffico e verrà mandata una risposta ICMP. Ripetendo questo procedimento
con TTL sempre crescenti (prima 1 poi 2 poi 3, etc..) finchè non si riceve un reply della destinazione finale, si
ha la possibilità di capire la strada o una delle possibili strade che fa il mio pacchetto udp fa sulla mia
destinazione, e quindi tracciare quali gateway ci sono sulla mia strada. Questa informazione importante
permette di sapere dove è il mittente da dove viene lnciato il pacchetto rispetto alla destinazione, a scopi
diagnostici è molto importante ma è anche importante ai fini di un attacco per conoscere la topologia della
rete.

Port Scanning:

le porte sono i servizi disponibil, le possibili connessioni con TCP e UDP, il port scanning è quella attività in
cui si cerca di capire quali canali di comunicazione sono disponibili su quel nodo. Quindi si identifica un
nodo, il suo numero IP, si verifica quali socket o Connessioni tcp o udp è possibile aprirle.Questa è un
informazione importantissima per il difensore per capire quali applicazioni e servizi monitorare e dare una
difesa e per dare un indice di attività non voluto, quindi eventualemente chiudere delle porte o per
accorgersi di attività sospetta. Spesso worm e virus sono i primi che a insaput dell’utente aprono porte per
comunicare o trasmettere file con l’esterno.

Dal punto di vista dell’attaccante, ha bisogno di sapere quali canali sono disponibili per un attacco, ovvero le
porte aperte disponibili. È un attività importante per l’attacante, ed è per questo che è anche considerata
un’attività sospetta (infatti può essere rilevata). Ci sono alcune tecniche con l’obbiettivo di fare scanning
senza che la rete possa rendersene conto.

Stati di una Porta:

Open: c’è la possibilità di connessione con un’applicazione o un processo che ascolta su quella porta

Closed: è possibile connettersi a quella porta, ma non c’è nessuna applicazione in ascolto, quindi se mi
collego a quella porta non c’è nessuna possibilità di scambiare dati.

Filtered: dal punto di vista di chi tenta di connettersi appare come close, ma in realtà è aperta ma questa
chiusura è data dal firewall o router che non ci permette di connetterci.

Dal punto di vista sia del difensore che dell’attacante è importante definire se delle porte sono chiuse o
filtrate.

Le porte in caso di TCP:

ricordiamo l’handshake: tre fasi, alice(client) che manda un flag syn a Bob(server), bob risponde con i flag
syn-ack, alice risponde con un flag ack finale,l’handsake è completato e la connessione è così stabilita.

Se Alice Manda un syn a una porta chiusa di Bob, Bob riponde con un pacchetto reset.

Se Alice Manda un syn-ack a una porta chiusa di Bob, Bob manda un reset

Se viene mandato un reset mandato senza sollecitazione viene ignorato.

UDP scan:

udp è privo di handshake quindi è più complicato. Lo stato viene segnalato tramite messaggi ICMP(messagio
di diannostica), se si tenta una connessione UDP e la porta e chiusa, viene mandato un messaggio ICMP per
segnalare che la porta è chiusa. Il sistema è lento e basato su timeout.Lo scan delle porte udp è complicato
e inaffidabile.

NMap (Network mapping): è un tool efficace per fare scansioni. Le possibilità di scansione sono tantissime.
Ci sono modalità che richiedono un’accesso privilegiato con accesso di amministrazione sulla macchina da
dove gira NMap, questo perché si usa uno stack non convenzionale, modificano la produzione dei pacchetti
per sfruttare alcuni lati dei protocolli usati molto poco e che possono mettere in evidenza se una porta è
chiusa o filtrata. Per distinguere questa cosa bisogna distinguere i pacchetti in maniera un po' strana, quindi
bisogna avere i privilegi di amministrazione, perché se no il sistema operativo produce i pacchetti secondo
modalità standard. Il tool identifica anche le connessioni TCP e UDP

Tecniche di scansione TCP


Connect

Tentativo di connessione, se la connessione ha luogo (ovvero se l’handshake ha luogo), la porta è aperta,


altrimenti sarà chiusa o filtrata. È una modalità molto semplice in cui viene normalmente è usata su TCP.
Quindi semplicemnte manderò un Syn, se ricevo un syn-ack vuol dire che è aperta, altrimenti se rispondo un
reset è chiusa, altrimenti se non ricevo nulla è filtrata. È un’ attività sospetta se inizio a fare questa
operazione su tutte le porte, quindi viene considerata attività di scansione. Se la faccio senza cautela il
pacchetto tcp conterrà il mio numero IP da cui ho fatto la scansione, e quindi nei LOG risulterà questa
scansione fatta a proprio nome. Questa è la meno adatta per fare un’attacco perché lascio troppe tracce per
gli amministratori della rete che sto analizzando.

SYN scan

Una tecnica più sofisticata è il syn scan, detta anche “half open” perché si fa un hadshake lasciato a metà,
ovvero si evita di mandare l’ack finale, questo permette di evitare che la connessione si stabilisca, una
connessione che non viene mandata a buon fine non viene loggata ( a meno che non configuro la rete che
registri ogni pacchetto). È il metodo più veloce utilizzato, ma richiede i privilegi di root perché non si usa un
tentavo di connessione standard, quindi devo avere un tool che si sostiusice alla generazione normale dei
pacchetti. Nel dettaglio se voglio capire ad esempio se la porta 80 è aperta mando un syn, ricevo un syn-ack,
ma anziché mandare un ack mando un rst e così interrompo la connessione, ricevendo un syn-ack so che la
porta è aperta. Se invece è chiusa dopo che ho mandato un syn ricevo un rst.

FYN scan

Si può mandare un pacchetto con il flag fyn, se la porta è aperta non ricevo nulla, altrimenti ricevo un rst.

Xmas scan

Si chiama così perché accendo tutti i flag come fosse un albero di natale. In questa procedura attivo i flag,
mando il pacchetto e se non ricevo niente la porta è aperta, se ricevo un rst è chiusa.

NULL scan

Non mando nessun flag, stesso effetto , se non ricevo niente la porta è aperta, se ricevo un rst è chiusa

Maimon scan

Accoppiano i flag in maniera particolare, mette insieme fyn e ack e si ottiene la stessa cosa. Con Nmap si
possono fare varie combinazioni di flag e vedere cosa succede.

ACK scan

Tecnica per determinare se c’è filtraggio su una porta, se io mando un pacchetto con il flag ack, se non c’è
filtraggio ricevo un rst. Se invece non ricevo nulla o un messaggio ICMP diagnostico , si riesce da questo a
capire che è una porta con un firewall.

Window Scan

In alcune implementazioni comuni del protocollo TCP, viene specificato nel pacchetto una window size,
permette di poter tener traccia dei numeri di sequenza dei pacchetti, la window usata in un caso o nell’altro
è diversa,quindi riesco a capire che in un caso me la ha mandato un firewall piuttosto che il nodo.

Idle scan
È una tecnica molto ingegnosa, ma anche molto pericolosa perché coinvolge nello scan un nodo che è
inconsapevole dell’attività. La tecnica sfrutta i serial number dei pacchetti TCP che è banalmente
sequenziale(molti degli stack sulla nostre macchine probabilmente non hanno più questa generazione di
numeri sequenziali, perché è ormai noto questo problema di prevedibilità). Gli stack TCP non stanno solo
sulle macchine, ma anche sulle stampanti e altri oggetti, in cui gli stack sono molto semplici e prevedibili in
modo banale(soprattutto se i pacchetti sono sequenziali).

Il nodo che viene coinvolto deve essere idle, ovvero che non fa nulla o poco traffico, si sfrutta la
vulnerabilità dei numeri di sequenza per capire i numeri di stato di una porta. L’idea importante in questo
scan, che magari lo scan viene registrato, ma dato che verrà da una macchina prestanome, è del tutto
inutile. Ad esempio faccio far lo scan a una stampante della rete, questo scan viene dalla rete e quindi è
inutile per capire chi ha fatto effettivamente lo scan. Potrebbe esserci un log sulla stamapnte, mettendo
insieme i log posso capire chi è stato, ma divento più difficoltoso. Non è spoofing, perché non imito
qualcuno ma sfrutto qualcuno a sua insaputa e non si appare artefice dell’evento, quindi un log conterrà l’ip
della macchina “presta nome”. Il nodo deve essere idle, ovvero non produrre trafico di rete suo durante lo
scan. Lo stack tcp di questo nodo deve essere banale, incrmentando il numero sequenziale.

L’idle scan funziona quando la nostra vittima Ha una porta aperta. Ad esempio alice è l’attacante
(192.168.0.11) che fa lo scan, bob (172.16.0.22) è la macchina in cui vogliamo sapere lo stato di una
determinata porta, igor (10.0.0.33) è il nodo idle che non farà traffico suo ma traffico indotto da alice. Alice
manda un syn-ack a Igor, a questo syn-ack il protocollo risponde con un rst, questo pacchetto mandato da
igor ad alice avrà un serial number, alice tiene traccia del serial number (ad esempio può essere 40).
L’azione successiva è quella di Mandare un syn a Bob ma con un indirizzo di mittente falsificato, Alice manda
un syn a Bob (ma con ip di igor, 10.0.0.33) quindi supponiamo che la porta sia aperta, bob risponderà con
un syn-ack a igor. Sostanzialmente Alice ha fatto lo scan , ma bob vede lo scan da igor e non da alice. Come
fa alice a sapere che c’è stata la risposta dato che il syn-ack va a igor? Lo fa andando a vedere i numeri di
sequenza, perché la risposta di igor a quel syn-ack sarà un reset, siccome si stupirà di aver ricevuto un syn-
ack senza aver inviato nulla restituirà rst. A questo punto alice può mandare un syn-ack a igor, igor risponde
con un rst con serial number 42. Siccome igor è il nodo idle e quindi non fa trafico suo,il fatto che alice ha
visto due rst con numero 40 e l’altro 42, a deduzione il rst in mezzo è 41 ed è di Bob, e quindi la porta è
aperta.

Nel caso che la porta sia chiusa, ripetendo la procedura iniziale con igor: Alice manda un syn-ack a Igor, a
questo syn-ack il protocollo risponde con un rst, questo pacchetto mandato da igor ad alice avrà un serial
number, alice tiene traccia del serial number (ad esempio può essere 40). alice poi manda un syn a bob con
indirizzo ip falsificato con l’indirizzo di igor, bob non manda più un syn-ack a igor, ma un rst. Quando alice
manda un secondo syn-ack a igor, il rst che restituirà sarà 41, quindi da qui capirò che bob ha mandato un
rst e non un syn-ack, e da qui capisco che una porta è chiusa.

Supponiamo che la porta sia filtrata, alice lavorando come prima, syn da igor a Bob non c’è nessuna
risposta, igor non ha prodotto nessun pacchetto in più , quindi ottengo sempre un rst con 41 e quindi mi
rende evidente che bob non ha dato syn-ack a igor.

Versioni sicure dei protocolli TCP/IP


La suite TCP/IP non è stata progettata con particolari misure di sicurezza. All’origine Per vari motivi non sono
state inserite tecniche crittografiche. Al giorno di oggi è necessaria che ci siano protocolli crittografici!

IPSEC
È una versione di ip che specifica oltre come trasferire i pacchetti da un nodo all’altro, ma come spedire
pacchetti criptati! Detta meglio con IPSEC specifica come crittare,autenticare e scambiare chiavi con IP. Non
è un sostituito di IP, ma costruito su IP! È Possibile costruirlo sia su ipv4 (facoltativo) che su ipv6
(obbligatorio).

Servizi offerti da IPSEC

L’obbiettivo è :

- poter controllare l’accesso alla comunicazione, quindi è possibile stabile se due nodi possono
conettersi e scambiare dati,
- è possibile autenticare l’orgine dei dati ,ipsec rende impossibile fare spoofing.
- c’è un controllo dell’integrità dei dati (i dati non possono essere manomessi perché sono protetti da
checksum crittografici).
- ,è possibile cifrare i dati e quindi garantire la confidenzialità.
- c’è anche in parte una protezione dal replay degli attacchi: un’intercettatore di pacchetti per poi
ripetere la trasmissione in un'altra situazione(ad esempio man-inthe-middle), un pacchetto viene
ritrasmesso nella rete, IPSEC fornisce una protezione in modo tale che un pacchetto che è stato
trasmesso e ricevuto non può essere ritrasmesso di nuovo.

Protocolli IPSEC

In realtà non c’è un protocollo IPSEC solo, ma si tratta di una serie di specifiche protocollari, inanzitutto nel
protocollo non sono specificabili tutte le caratteristiche crittografiche, anche perché gli algoritmi crittografici
possono evolvere continuamente. Le specifiche protocollari sono

Authentication header (AH) = specifica come si ottiene l’autenticazione e integrità del datagramma

Encapsulating Security Payload (ESP) = specifica come avviene la cifratura del payload, i dati portati dal
pacchetto, quindi serve per la confidenzialità

Entrambi assumono che ci sia una”security association”(SA), stabilisce i parametri della sessione di
comunicazione, entrambi AH e ESP assumono che prima ci si sia accordati su SA, che è quella che permette
lo scambio di credenziali.

Authentication header (AH)

Serve per autenticare l’origine del pacchetto, per impedire che l’utente sia spooffato, e si stabilisce una
maniera per garantire l’integrità dei campi del pacchetto (tranne TTL, che durante il trasporto vengono
cambiati), i campi immutabili del pacchetto si occuperà di non farli modificare e tenerli integri tramite
checksum crittografici. Sostanzialmente incapsula il pacchetto ip in un pacchetto IPSEC e aggiunge:

-Security parameter index, che permette di identificare la security association (SA), quindi è un meccanismo
di stabilire quali parametri ha lo scambio di dati.

- Meccanismo per evitare replay di pacchetti: usa uno “sliding window” (è un contatore),l’idea è che in un
certo intervallo di tempo si possa ricevere solo i pacchetti contenuti di una certa finestra di pacchetti. Ad
esempio se io ricevo solo i pacchetti dal 2 al 10, e ricevo un pacchetto 12 non va bene e lo scarto! Se voglio
ricominciare a contare, o meglio inizializzare il contatore, devo rifare una nuova SA.

Encapsulating Security Payload (ESP)

Se ah serviva per autenticare il mittente per garantire l’integrità del pacchetto e che l’utente non sia stato
ulterato, ESP è la specifica protocollare come fare la cifratura del contenuto dei pacchetti. Anche qui ci sarà
un security parameter index, che è quello che identifica la SA(cioè i parametri di sicurezza della sessione di
comunicazione) e poi si ha un campo in quale modalità vengono criptati i dati, sono previste due modalita:

modalita transport: nei protocolli di livello superiore (TCP o UDP), questi protocolli sono criptati end to
end,quindi i pacchetti dei livelli superiori vengono criptati in IPSEC, quindi la destinazione riceverà pacchetti
IPSEC che poi andranno decriptati per trasformarli per il livello superiore

Modalità tunnel: IPSEC viene utilizzato per criptare pacchetti ip, i pacchetti IPSEC vengono ultizzati per
trasmettere dei dati che incapsulano dei pacchetti ip che vengono spacchettati e utlizzati. Questa modalità è
utile per modificare pacchetti IP(per NAT,proxy,etc).

Quindi In modalità transport cripto il livello superiore, mentre in modalità tunnel cripto i pacchetti IP che
vengono trasferiti da una parte all’altra.

Security association (SA)

Ogni conversazione IPSEC è abbinata a una SA, che è frutto di un negoziazione di parametri di sicurezza e
delle credenziali. (Se alice vuole comunicare con bob dovranno accordarsi su quale algoritmo di cifratura
useranno che verrano utlizzati per cifrare).

-Queste SA, sono diverse per AH e ESP, quindi ne ho due per ogni conversazione, una per AH e una per ESP.

- SA contiene ip destinazione

- SA possono essere stabilite sia statiche che dinamiche dall’amministratore (ISAKMp, IKE)

Problemi IPSEC

IPSEC non è molto diffuso, i protocolli che abbiamo visto non sono banali da fare funzionare con i firewall.

Ogni volta che una comunicazione comporta manipolazione del pacchetto IP (proxy e NAT), occorre
adottare misure speciali, con successive SA

TSL/SSL
In Ipsec le misure di sicurezza sono sotto TCP mentre invece TSL/SSL è sopra TCP. Si tratta di protoloccoli
inventati negli anni 90 da netscape(inventarono anche i browser), che erano interessati a proteggere le
navigazioni web. Inventò il security socket layer (SSL) fino al 2.0 pensato per proteggere la navigazione web,
è un layer di sicurezza per proteggere le comunicazioni http. Il protocollo successivamente si è evoluto nella
versione 3.0, la IETF (Internet Engineering Task Force) ha standardizzato questa cosa in un protocollo
aperto, che ha assunto un nome diverso, la versione standard si chiama TSL(transport layer security), spesso
però si fa riferimento a SSL per fatori storici, quindi SSL 3.0 = TSL 1.0 .

Obbiettivi di sicurezza di TSL

- Si vuole dare la possibilità di dare una cifratura end-to-end : ovvero rendere i dati sul canale sicuri da
intercettazioni.
- Ovviamente oltre a questo li si vuole proteggere nella loro integrità: ovvero che non vengano
manipolati.
- Si vuole autenticare il server: quando un client si collega con un server usando TLS, viene a
conoscenza di una identità con il server, il client invece rimane anonimo (ad esempio mi collego con
Amazone, ma voglio la sicurezza che sia amazone a collegarmi).
- Garantire una adeguata efficienza nelle connessioni http: nell’ idea originaria le connessioni http
erano molto brevi e stateless (“senza stato”, cioè una comunicazione tra client e server in cui
ciascuna richiesta è indipendente dalle altre) che per esempio mandavano un comando GET e poi
chiudevano la socket e la riaprivano (aprire una socket per una get è un lavoro oneroso, per di più
su questo se c’è un ovherad alle misure di sicurezza è inutlizzabile), quindi uno degli obbiettivi di tls
era anche un efficienza adeguate di connessioni di tipo http che erano brevi e stateless.

Sessione TSL

Abbiamo delle sessioni TSL (comunicazioni TSL) e come al solito sono i nodi che mantengono i dati della
sessione. Il protocollo specifica come deve avvenire l’handshake che scpecifica la sessione. Dopodichè c’è
un’altra parte del protocollo che si chiama record layer che stabilisce come spazzare i dati per definire come
devono essere spezzati i dati per come devono essere criptati e dati in pasto ai meccanismi di sicurezza. Gli
algoritmi sono negoziabili (quindi non fissi), una cosa significativa , per evitare di penalizzare le sessioni
brevi, una sessione può gestire più connessioni, se ho una conversazione hhtp che è fatta da più connessioni
(più GET ), tutte possono sfruttare che sia allestita una certa sessione e si può continuare ad usarla più volte
per aver un hoverhed (richiesta risorse, in sovrappiù rispetto a quelle strettamente necessarie) più
gestibile.

TSL HANDSHAKE

L’handshake funziona sempre con i soliti 3 passi m ain questa maniera:

- Il client richiede la connessione e la richiede elencando quali cipher suite (CS, suite di crittografia)
conosce.
- Ad es. il client se vuole connettersi a un server (es. amazon), il cliente comunica che sa fare RSA e
altre cifrature, il server risponde con una CS che sa anche lui, ad esempio RSA, quindi a questo
punto trasferisce un certificato digitale , un digitale certificate (DC), che deve essere firmato da una
certification autority (CA).
- Ultimo passo dell’hadshake il client controlla il DC , quindi questo gli permette di andare a verificare
che il server con cui sta parlando è effettivamente quello con cui voleva parlare,(es Amazon), a
questo punto manda una chiave di sessione random per criptare la sessione, la sessione sarà
criptata con una chiave generata in questa occasione.

Integrazione con le applicazioni

Ci sono 3 strategie:

- Ci inventiamo un nuovo servizio che sfrutta questo nuovo possibilità, esiste questo livello di
cifratura a livello socket, ci costruisco sopra un applicazione che la sfrutta (questa strategia è stata
sfruttatta con SSH2: un nuovo servizio, in cui si cripta una sessione di accesso con il terminale a una
macchina con questo servizio di socket layer)
- Usare un servizio che già esiste http, però aggiungendoli l’uso di queste misure di sicurezza( ad
esempio https: il protoccollo rimane http, ma lo si fa su delle socket tsl e non più le solite, bisognerà
dire a chi si collega di distinguerlo, di solito si usa una porta differente per un https, infatti si usa al
porta 80 per http e per https 443, ciò permette di distinguere i due protocilli e i client).
- Avere sempre un servizio noto, ed esterne il protocollo, perché possano usare anche TLS, questa
strategia è stata usata da ESMTP (Extenden Simple Mail Transfer Protocol ), è un protocollo per il
trasferimento della posta eletronica (di solito collegeto alla porta 25), si continua ad avere smtp
sulla porta 25 ma si fa un protocollo esteso, ovvero si aggiunge il comando “start ssl “che permette
di attivare uno standard tsl.

TCPCRYPT
Ipsec e tsl sono buone soluzioni dal punto di vista di sicurezza, ma penalizzanti dal punto di vista delle
prestazioni. Tsl rispetto a una normale connessione tcp può essere 82 volta più lento (ad esempio https è
82 volte più lento rispetto a un http, infatti mettere https in siti con un’alto traffico è un problema).

Tcpcrypt è una uscita recente, 2010, dal punto di vista del server dà una sicurezza analoga a TSL, ma è molto
meno lenta (solo 3 volte rispetto a una normale connesione tcp).

limiti di TSL:

Il meccanismo dell’autenticazione del server è cablato, tsl ci permette di identifcare il server tramite un
certifcato digitale, quindi si basa su di esso che deve essere fatto da autorità di certificazione. TSL è basato
sull’idea delle autorità certificate. Se l’autenticazione è falsa (certificato digitale falso), ad es empio il
certificato di amazon divneta amzon(senza la “a”), quando io mi collego non me ne accorgo e vado avanti e
mi fido. Questa struttura delle autorità certificatrici è sempre prevista anche quando è inutile o falsa.In
tcpcript esiste un meccasinismo di base che può essere utilizzato pr fare protocolli di autentificazione
tramite certificazione, ma il meccanismo non sovraccarica i server come tsl.

Tcpcrypt:

è un protocollo che estende TCP.

Il trucco per ridurre l’onore crittografico, è quello di spostarlo sui client. L’idea è che i client fanno una sola
connessione, (e non ne ricevono tante come i server) e possono accollarsi un po' di computazione
crittografica (adesso Anche i client più semplici hanno una potenza computazionale elevata)

In concomitanza con TCP normale i progettisti hanno pensato a Opportunistic encryption: ossia l’estensione
viene attivata solo se attivata da entrambi, se io mi collego e al momento del’hadnshake scopro che si tratta
di un nodo di un server tcpcrypt vado avanti in questa maniera, altrimenti decado. Questo difende dagli
attacchi passivi, ma non dagli attacchi attivi(potrebbe essere che un attaccante attivo in mezzo riesce a
convincere il client che il server non è capace a fare tcpcrypt, e quindi la comunicazione avviene lo stesso
ma con TCP)

Tcpcrypt handshake

L’idea è che tutto inizia con una richesta di connessione, la richesta di connessione che ha tcpcrypt e manda
questa richiesta di connessione con un syn che chiede se supporta tcpcrypt. Se è un server tcpcriot lo
supporta risponde “si”, e supporto RSA(esempio), il client allora manda una chiave pubblica RSA, il server
genera una master key di quella sessione e la manda criptata con la chiave pubblica. La chiave pubblica in
questo protocollo è fatta dal client, mentre in tsl si manda un certifcato digitale. Questa chiave pubblica non
è detto che sia in grado di certificare l’identità del client, ma non serve se il server non ha bisogno di
stabilire l’identità del client basterà una copia qualsiasi. Tutto l’ononre che aveva il server in tsl di mettere in
piedi la sessione, è spostato sul client. tutto ciò fa si che questo handshake sia 36 volte più veloce del
handshake di tsl.

Vedendo l’handshake nel dettaglio:

abbiamo un syn con un nuovo flag cript, che appunto è quello che chiede se tcpcrypt è attivo, e in qualche
modo il freeway handskake diventa four way handshake (anichè 3 passaggi ci sono 4 passaggi).

Abbiamo quindi Hello che chiede se sappiamo fare tcpcrypt, risponde che è capace e dice gli algoritmi che
sa fare, a questo punto gli si manda la chiave pubblica, e il server risponde mandando la master key criptata.
Dda questo punto in poi la crittografia è attivata e si possono trasferire i dati mantenendo la confidenzialità.

Autenticazione

Il protocollo ha un meccanismo di base per fare cose più complesse, non c’è l’autentificazione con la CA
come tsl , però c’è un session ID che è probabilisticamente unico! Perfino nel caso che uno dei due nodi sia
malevolo, se vuole usare il protocollo, non è capace di generare lo stesso session id di un'altra situazione, il
session id è unico di quella comunicazione. Questo è un meccanismo di base per costruire tutti i protocolli
di autenticazione che vogliamo!

Per esempio potrebbe servire per sviluppare un protocollo di autenticazione con un segreto condiviso tra il
client e il server. Per autenticare il client nei confronti del server, il client userà una funzione hash per
generare il segreto condiviso e questo session id, e il server anche lui potrà farsi autenticare con la stessa
cosa. Anche se un nodo si è sostutito ad amazon(ad esempio), non può comunque risalire al client, perché
non può riutilizzare il segreto.

SICUREZZA PERIMETRALE
Si definisce perimetro della rete locale il limite fra il traffico interno e quello esterno. L’assunzione che il
locale è uguale a trusted(fiducia), ovvero sul traffico locale facciamo delle assunzioni di fiducia, sul traffico
che non è locale prenderemo precuazioni più dure. I firewall sono dei dispositivi, che permettono di limitare
la località in maniera diversa o parzialmente, da quello che imporrebbero i mezzi trasmissivi. La differenza
locale e non locale della rete internet, è basata sulla condivisione o meno di un mezzo trasmissivo. I firewall
servono per imporre dei confini limiti/imposti dai mezzi trasmissivi.

FIREWALL
Firewall (parete taglia fuoco)

I firewall sono i più diffusi per la sicurezza, il firewall è un meccanismo che ci permette di definire
determinate regole, ma la sicurezza della nostra rete sarà frutto di una progettazione adeguata di tutto il
contesto della rete applicativo. Dal punto di vista tecnico il firewall (parete tagliafuoco), dal punto di vista
informatico sta fra due reti, quindi ha due interfacce di reti (A e B), per come è strutturata la rete tutto il
traffico tra A e B deve passare dal firewall. Abbiamo la garanzia, che tutto il traffico tra A e b passerà dal
firewall, questo ci potrà permettere di definire delle regole in questo punto. Quindi l’idea è questa:
coinvogliamo tutto il traffico in unico punto e li ci mettiamo delle politiche di accesso.
Il compito dei firewall è quello di stabilire quale traffico ha accesso alla rete. Il firewall di per se non fa nulla
per controllare che il traffico che è passato faccia o meno danni, il firewall semplicemente ad ogni bit o
pacchetto si chiede se rispetta le regole. Quindi si controlleranno i documenti del traffico (policy), ma
ovviamente nulla impedisce che una volta superata la politica di ingresso a una persona malevola di fare
danni. Quindi ricapitolando il compito dei firewall è stabilire quale traffico ha accesso alla rete (policy) e non
controllare che il traffico permesso non faccia danni (control, intrusion detection).

Si usa distinguere 3 tipi di firewall:

- Forwarding gateway: è il firewall più semplice, il gateway fra le due reti fa anche da firewall e non
solo inoltratore di traffico, quindi si occupa di controllare alcune credenziali.
- Filtering Router: un dispositivo che non fa solo da interfaccia fra due o più reti, ma che prenda
anche decisioni oltre che di instradamento anche di policy. Potrà anche prendere delle decisioni
diverse guardando anche le possibilità di instradamento
- Proxy: proxy significa “una delega”, ci sono delle macchine a delle reti che sono deputate a fare da
proxy, cioè da fare da sostituto di un determinato servizio. I proxy più utilizzati sono quelli che si
occupano chaching del traffico, esempio i computer dell’università anzichè connettersi direttamente
al “corriere della sera”, potrebbero usare una macchina proxy che fa cache del traffico. Quindi il
primo che si collega al corriere della sera ha un passaggio in più, ma dal secondo in poi risparmiano
perché il proxy è una macchina interna e quindi si risparmia traffico interno. Di proxy ne esistono
tantissimi tipi, ma le connessioni che vengono fatte con l’esterno, vengono fatte con il proxy al posto
con la macchina interna, ecco quindi che il proxy è un buon punto per mettere un dispositivo di
firewall, perché è un punto di contatto tra la rete interna e rete esterna, li mi chiederò se le richieste
interne sono possibili e rispettano le richieste della mia rete.

Le regole possono essere stabilite a tutti i livelli dello stack.

Firewall a vari livelli

I firewall nascono alla fine dagli anni 80 (non c’è un vero inventore, anche se molti hanno contribuito), in
questa versione iniziale di una architettura di firewall, per esempio il gatekeeper, era il proxy che noi oggi
chiamiamo proxy applicativo, raccoglieva le richieste applicative provenienti dalla rete
interna(telnet,FTP,SMTP) e le girava verso l’esterno tenendo traccia. L’idea è di tenete il gatekeeper che è
quello che fa da forward (proxy richieste applicative) e un gate (quello che filtà il traffico secondo regole
stabilite). Questo meccanismo a più pezzi permette appunto di distinguere in maniera chiara il traffico
esterno (non fidato) e il traffico interno. Ad esempio il dispositivo di mail (mailgate) è accessibile dalla rete
interna, in questo caso il mailgate non è accessibile dalla rete esterna, se non senza passare da questi filtri.

Rete Rete
esterna interna

router gatekeeper gate mailgate


Livelli Firewall

In generale si possono avere firewall:

- A livello appilicativo, stabiliscono delle regole sulle applicazioni , su come possono avvenire le
comunicazioni, questi si chiamano application gateway o proxy.
- A livello di trasporto: prendono il nome di “circuit gateway”, le regole riguardano la possibilità di
stabilire una connessione o circuito oppure no
- A livello rete: le regole saranno sul singolo pacchetto, prendono nome “packet filter”, la regola che
stabilisce che cosa può passare o no si riferisce al singolo pacchetto.

Esistono prodotti ibridi, dynamic packet filter, sono livello che agiscono a livello rete e a livello di
trasporto(qualche volta anche applicativo). I livelli di rete e trasporto sono i più generali quindi è sensato
metterli assieme. A volte conoscono le applicazioni più comuni (es. http ). I firewall possono essere realizzati
software e hardware. Ha senso farlo hardware, perché è più facile farlo veloce, ma sono più costosi e meno
flessibili da configurare.

Stateless Filtering

é il metodo più comune e più semplice. Viene fatto del filtraggio stateless (senza stato), cioè ogni elemento
che viene identificato (a liveelo di rete pacchetto ,trasporto la connessione, applicativo comando
protocollare, etc.) ogni elemento è valutato in isolamento,Quindi per la rete si guarderà il pacchetto, per il
trasporto la connessione e per l’applicativo il comando protocollare , senza tenere traccia di quelli
precedenti. Il firewall mi permette di dire cosa passa o no, nel caso dei firewall stateless sono regole che
riguardano il singolo pacchetto, il singolo connessione, il singolo comando protoccollare che passa in quel
moemnto per il firewall. In pratica per i firewall stateless si tratta di definire una access control list (ACL):

una politica corrisponde a un elenco di una lista di ACL, uno per volta i pacchetti o le richieste sono
analizzati. Si dice ad esempio se un pacchetto ha diritto di passare oppure no. Ogni prodotto ha la sua
sintassi specifica per scrivere le regole, es. i firewall cisco o IP table sono sintassi comuni. Un modo per
esprimere le ACL senza entrare in merito alle sintassi, sono da fare delle tabelle che hanno nelle colonne le
caratteristiche che prende in considerazione le

Int addr Int port Ext addr Ext port action


* * a.b.c.d * Block
192.168.2.3 110 * 110 disallow

Int = interno

Ext = esterno

*= qualsiasi

Si identifica l’interno della rete e l’esterno della rete (mittente e destinatario).

Nella prima regola (* - * - a.b.c.d - * - block ): qualsiasi interno con qualsiasi porta, può accedere solo ad
a.b.c.d, ma non può accedere a nessuna porta, è bloccato. Quindi gli accessi a qualsiasi porta a questo
indirizzo sono bloccati. Questa ed esempio può essere una regola per Facebook per evitare di collegarsi al
server.

Nella seconda regola (192.168.2.3 – 110 - * 110- al): L’indirizzo interno 192.168.2.3 con la porta 110 può
connettersi a qualsiasi indirizzo, basta che la porta sia 110.

Questo è un esempio di ACL che appunto definisce una politica di firewall.


Sulle ACL, vale la pena fale una piccola Digressione (devizione del discorso): L’acl fissa la politica di accesso,
tipcamente hanno una sintassi che specificano la politica di accesso in maniera compatta e comprensibile.
Quando si legge o si scrive una policy, è come deve essere interpretato il silenzio ovvero l’assenza di una
regola su un fatto specifico. Le possibilità sono due:

- Default deny: è vieteto tutto ciò che non è esplicitamente permesso


- Default permit: è permesso tutto ciò che non è esplicitamente vietato

Nelle reti e nei computer in generale, sono fattibili entrambi le cose. Da maggiore sicurezza la prima, perché
se mai si dimentica di inserire qualcosa nella policy è vietato.

Nel concreto quello che succede è che l’ACL è una serie di regole che vengono esaminate nell’ordine in cui
sono presentate. Per essere sicuri di avere default deny (la strategia più sicura), è quello di avere una regola
alla fine che tutto quello che non si è detto prima nelle regole, viene bloccato. Se non sappiamo il default
del nostro sistema, possiamo inserire default deny come ultima regola.

Stateful filtering

Il filtraggio che tiene conto dello stato del sistema, della storia dei pacchetti visti (in una finestra temporale).
Questo è meno efficiente perché bisogna mantenerlo questo stato (usare maggiori risorse come memoria).
Allo scopo occorre mantenere una tabella delle connessioni, accettare per esempio un certo pacchetto solo
se la chiusura di un freeway handshake che c’è stato prima.

Stateful filtering è abbastanza utile in alcuni casi, perché tiene traccia delle connessioni in corso.

Deep Packet inspection

C’è un ulteriore specializzazione del filtraggio statefull, “deep packet inspection”, quando noi abbiamo delle
regole quando noi andiamo a predicare sul contenuto delle comunicazione. Se la comunicazione è TCP, noi
abbiamo bisogno di ricostuire il flusso, ovverro tutti i pacchetti della comunicazione, se ad esempio nel
flusso c’è la parola “cocaina”, quel flusso non deve passare. Quindi deep packet inspection è un filtraffio
statefull, che tiene traccia / ricostruisce il contenuto dei pacchetti e mettiamo delle regole su quei
contenuti. Di solito è fatto a livello applicativo. In molti paesi le comunicazioni sono protetti dalla legge,
quindi non è detto che sia lecito fare questo tipo di ispezione, In generale non è possibile che una rete
aziendale vienti um invio messaggi di posta elettronica che contiene la parola “cocaina”, non si può guardare
dentro il contenuto di una comunicazione!!! Quindi la deep packet inspection oltre a essere onerosa dal
punto di vista tecnologica è difficoltosa a livello legale!

Configurazioni ricorrenti

Abbiamo queste 3 principali configurazioni:

- SHBH = Single-homed bastion host


- DHBH = Double-homed bastion host
- DMZ = Demilitarized zone (o screened subnet)
Inanzitutto diciamo cosa è un bastion Host:
non è un firewall, è un nodo della rete particolarmente protetto, è stato configurato per essere il più
possibile protetto e immune da attacchi. Tipicamente l’idea di base, come un bastione delle città fortificate
è molto forte, non solo difende ma anche nel caso crollasse da rete alla rete interna di allestire nuovo difese
(quindi essere lasciato al nemico senza danni per la rete interna).

Analizzando la configurazione del SHBH (Single-homed bastion host), siingle homed indica che questo nodo
ha un’unica interfaccia di rete. L’architettura di rete, si identifica nella rete dei servizi verso l’esterno, che
sono raggruppati un segmento di rete. I computer della rete interna devono passare per il bastian host, che
è il tramite di tutto il traffico all’esterno. Il traffico dall’esterno passa dal firewall, e se il traffico e diretto
verso i server di servizio, sarà traffico che passa dal firewall. Viceversa se è traffico che è traffico di risposta
dalla rete interna dovrà prima passare dal bastian host e poi essere rigirato verso la rete interna. Il
vantaggio di questa configurazione è che se anche il firewall viene danneggiato, la rete viene comunque
protetta.

DHBH ( Double-homed bastion host)


Si può avere anche un bastian host con due interfaccie di rete. La protezione è ancora più efficace, è
possibile stalire quale traffico và nella inner zone e outer zone. In questo caso si hanno due sottoreti: una
“intima” inaccessibile dall'esterno e una piúesterna, ma sempre difesa dal bastion host. Una evoluzione di
questa architettura può essere quella di screened subnet.

screened subnet:

è la rete più comune, l’idea è quella di avere due firewall, anche qui c’è il bastian host, si mette un firewall
anche tra il bastian host e la rete interna. Sostanzialmente qui c’è “una terra di nessuno” che fa da
protezione.
Dal punto di vista logico abbiamo partizionato la rete in tre livelli di trust diversi: La rete esterna(non fidata),
lòa rete interna(fidata), e la terza zona la DMZ che è una zona semi-fidata perché è all’interno del confine
del firewall più esterno (li potrebbe essere attraversata da traffico sospetto).

Effetti di un firewall
- separazione in zone aventi diverso grado di sicurezza
- solo i componenti esterni al firewall sono direttamente accessibili
- è possibilie regolare la “direzionalità” delle connessioni(per esempio la rete interna può connettersi
verso l’esterno, ma l’architettura può impedire il contrario, i socket però rimangono bidirezionali)

Stateless filtering TCP


Per definire la ACL usiamo una tabella così:

Verso: fa riferimento alla rete interna ed esterna, quindi utilizzeremo IN come reta interna e OUT rete
esterna

IP src/IP dst: ip sorgente /ip destinatario

Protocollo: TCP, UDP, ICMP, IP (per il momento ci concentremo su TCP)

Porta sorgente/destinazione: si può mettere un’insieme di valori (es. > 1023)

Flag: normalmente è il flag ACK, che permette di distinguere la risposta nel handshake

Azione: puo essere permit (il traffico è permesso) o deny (il traffico viene bloccato)

Sia per il numero IP che per le porte è possibilie usare delle variabili. Permette di riutilizzare politiche in
topologie di rete diverse, mantendo fissa la politica e cambiando le variabili. L’uso di variabil è
fondamentale per evitare di scrivere ogni volta tutta la politica.

Esempio:

Protezione contro lo spoofing IP


Vogliamo proteggerci dallo spoofing degli indirizzi sorgenti/destinazioni. Non esiste nel protocollo una
protezione sulla falsificazione di un IP su un pacchetto (appunto spooffato). La prima cosa che possiamo
mettere nelle nostre regole, evitare alcuni casi evidenti di falsificazione IP. Queste regole sono così
comuni, che sono chiamate ingress ( ingresso, regole dei pacchetti in ingresso) ed
egress(uscita,pacchetti in uscita) filtering. Quando si parla di ingrees ed egrees si riferisce contro la
falsificazione IP. I nostri pacchetti in uscita, il mittente dovrà essere necessariamente un numero IP che
appartiene all’insieme dei nodi interni. Quindi se il mittente non è un nodo interno, quel IP è falso. Allo
stesso modo possiamo mettere dei vincoli in ingresso: il mittente dovrà essere necessariamente
appartenenteal’insieme dei nodi esterni, non vogliamo che qualcuno si faccia credere interno quando
non lo è, quindi permetteremo solo i pacchetti che hanno solo come mittente un numero esterno e
destinazione un numero interno. C’è una terza regola dove impediamo qualunque altro pacchetto.
Questa è una protezione da almeno alcune forme di spoofing:

naturalmente uno spoofing per esempio verso l’esterno che usi un altro ip ma sempre verso gli interni
sarebbe permesso.

SSH con stateless filtering


Un altro protocollo comune che permette di fare un sacco di cose hanno la politica di autorizzare
connessioni ssh dall’interno della rete verso l’esterno. Questo necessita di essere riportata al modello
che mi impone la mia tecnologia di firewall. Se stiamo facendo stateless filtering, devo riportare questa
politica a qualche cosa di più concreto , quindi devo dire che le connessioni ssh corrispondo alle
destinazioni che hanno porta 22. È una semplificazione! Perché normalmente usa la porta 22, ma nulla
viete di usare altre porte, spesso il server ssh sono sotto attacco di brute force(es. user:root,
Pass:root,etc). Se si scelgono buone password siamo tranquilli ma per non intasare i file di log si usa
spostare il ssh su un’altra porta. Se abbiamo dei server di questo tipo gli utenti della nostra rete
aziendale non si potranno connettere, perché stiamo permettendo le connessioni porte destinazioni
22(nel caso si usa una porta diversa).

Quindi riassumendo:
La politica da implementare autorizza solo connessioni SSH dall'interno della rete aziendale
verso l'esterno. semplificazione: identifichiamo SSH con i pacchetti TCP con porta
destinazione 22(si noti che talvolta si cambia la porta proprio per ragioni di sicurezza!)
ecco come scrivere una regola di questo tipo:

C’è un osservazione da fare: abbiamo all’interno di queste regole lasciato passare un sacco di pacchetti che
non servono! Abbiamo impedito qualsiasi connessione che non faccia riferimentp alla porta 22, ma allo
stesso tempo permettiamo connessioni che non dovrebbero esserci. I pacchetti che provengono all’esterno
dalla rete, noi non li vogliamo tutti! Tutti quelli che non hanno l’ack(non sono pacchetti di risposta), li posso
scartare. La regola quindi la si può riscrivere più stringente in questa manienra, scartando ciò che non mi
serve,

Ad esempio qua i flag ack in entrata sono impostati a 1

COMPLESSITà DEL FILTERING

LPP
Il principio del least privilege(LPP), è Un principio importantissimo da tener presente quando si scrivono le politiche
per limitare il traffico, "Ogni attore dispone del minimo numero dei privilegi necessari per raggiungere gli obiettivi
assegnateli dalle specifiche del sistema. " È molto difficile da applicare, poichè c'è una costante tensione tra flessibilità
e sicurezza.

Protocolli firewall- friendly

Sono piuttosto "semplici", è ben definito il ruolo del client e il server. C'è un pattern di scambi di messaggi in maniera
chiara. Questo tipo di protocolli sono ad esempio telne,ssh,rlogin,etc.

SMTP
è il protocollo che serve per il trasporto della posta eletronica. É un protocollo firewall-friendly, la politica che vogliamo
realizzare è che ci sia un solo server smtp autorizzato a gestire la posta elettronica con l'esterno e non vogliamo che ci
siano altre connessioni esterne se non questo server autorizzato.

In analogia per quanto si è fatto per ssh, usiamo due variabili:


smtpSrv := 159.149.70.23
Con questa variabile diciamo che è il server smtp è 70.23

External := not(159.149.70.0/24)
Con questa variabile è esterno tutto ciò che è esterno alla rete 70.

La porta usata per smtp è la porta 25.


Proviamo a scrivere delle regole

L'impostazione non è corretta, perchè al contrario per quanto avveniva per ssh, questa politica bloccherebbe le
connessioni syn.

Le regole devono essere necessariamente più sofisticate:


- se vogliamo scambiare la posta in realtà il MailServer riceve e invia posta da e verso altri MailServer.
- Ricevere Posta: Il MailServer si connettono al nostro MailServer come Client
- Invare posta: il nostro MailServer aziendale si connette ad altri MailServer agendo invece da client.
Il nostro Mailserver agisce ogni tanto da Client e ogni tanto da Server. Il tipo di connessioni da gestire non è uno solo!

Secondo tentativo che facciamo

è quello di scrivere una regola molto generale, semplicemnte togliendo il riferimento alle porte e ai flag. Questa regola
funziona ma non rispetta Il LPP.

Dobbiamo scrivere più regole:

Ci sono due regole IN e 2 regole out che rappresentano il ruolo di client e server.
Protocolli non firewall-friendly

FTP

è un protocollo abbastanza diffuso anche se c'è ne sono di migliori (tipo SSH, ma occorre avere un account ssh, essere
un utente della macchina server, FTP è Più flessibile da questo punto di vista). È un servizio che pone una serie di
problemi: il problema nasce dalla sua flessibilità. Esaminando il dettaglio una comunicazione FTP: tutto inizia tra il
client e server con un TCP- Handshake. In modo particolare la porta normalmente usata è la 21. Una volta avvenuto
l'handshake, il protocollo prevede che il client comunichi al server un numero di porta specifico per questa
connessione (esempio in questo caso il client comunica la porta 5151, è un numero arbitrario non prevedibile a priori,
dal punto di vista della sicurezza non è difficile prevederla dato che le porte sono limitate). Una volta che la porta stata
comunicata il server risponde "ok ho capito", il server apre una connessione sulla porta 5151 iniziando u'handshake
con la porta 5151 del client. La connessione inizale mandata alla porta 21 del client viene utlizzata per mandare i
comandi(trasferisci, interrompi,etc.). Mentre l'altra connessione è riservata allo scambio di dati.
Questo protocollo permette di aver una connessione dati, che permette a una macchina diversa di aprire un nodo( ad
esempio il client contatta il server porta 21, e poi gli dice di utilizzare la 5151, il server potrebbe dare la porta a
qualunque altra macchina, e così un'altra macchina può fare il download/upload dei dati ). Oltre a questo la gestione
tramite un firewall c'è un problema, non è firewall-friendly(Il client fà sempre il client, il server fà sempre il server).

Proviamo a scrivere le regole:

non è firewall-friendly perchè il canale dati è un canale dal server verso il client.
La regola che sono solo permesse connessioni dall'interno all'esterno non è applicabile.
La porta destinazione verso l'interno è imprevedibile e non determinata a priori.

FTP in Passive MODE


Gli FTP moderni sono firewall-friendly, i cosidetti FTP in modalità "Passiva".
Infatti c'è la possibilità di fare la connessione sia in modalità attiva e passiva.
È una variazione semplice, c'è il solito handshake con la porta 21, sulla porta comandi diciamo che vogliamo la
modalità passiva(PASSV), a questo punto è il server che comunica un numero di porta al client. Il client apre la
connessione , fà l'handshake sulla porta xxx che è stata comunicata, e tutto avviene come prima.

Il vantaggio di questa nuova modalità è che la seconda connessione è dal client al server, posso scrivere regole di
connessione dall'interno verso l'esterno

le regole:

RPC(remote procede call)


è un altro protocollo non firewall-frendly, si tratta di un porotcollo che permette una serie di flessbibilità.
È un protocollo molto diffuso inventato dalla sun, permette di gestire una serie di servizzi che non sono tutti noti in
fase di deployment iniziale.
L'idea è che i servizzi disponibili possano cambiare nel tempo:
se nel mio server attivo un nuovo servizio, il servizio la prima cosa che fà è di registrare se stesso come servizio
disponibile, e lo fà usando il portmapper, che è quello che viene contatto dal client. Quindi Il servizio RPC si registra al
portmapper, il client contatta il portmapper che c'è sempre e richeide su quale porta c'è un determinato servizio (es. Il
client chiede ehi RPC server su quale porta posso scambiare dati/ fare condivisione del discho). Il portmapper
comunica la porta di quel servizio che ho richiesto, il client fà un servizio alla porta stessa del servizio xxx. La porta del
client non è nota a priori.

PROXY
Un proxy è un componente (nodo della rete) che è in mezzo alla comunicazione a due altri componenti, che però
apparentemente non si accorgono della sua presenza. Il proxy può essere anche usato per scopi lontani dalla sicurezza.
Il vantaggio di avere un proxy è che fà da disaccopiatore tra i due componenti (per esempio possono servire per
rendere più efficiente l'accesso a un altro sito. Se ci sono tanti client che fanno la stessa richiesta il proxy può fare da
cache). I proxy fanno sia da client che da server. Fà da client rispetto al server originale, però è anche un server ,perchè
è un server a cui il client si rivolge il client originario.
Quandi si fà uso di proxy abbiamo delle connessioni reali che sono diverse da quelle cha appaiono dai client. Ad
esempio un proxy usato come cache (es.web server corriere della sera), fà si che , questi sono una serie di macchine
nodi che fanno una connessione al corriere della sera, però è mediata dal proxy. La connessione reale è quella (in
rosso) i nodi si connettono al proxy dicendo che vogliano vedere il sito del corriere della sera, se il porxy non ha i dati
nella cache, il server li restituisce e il proxy li salva in cache. Dal punto di vista del client questo è trasparente, a livello
logico delle applicazioni quello che succede è che si sono collegate al sito del corriere della sera, nella realtà le
connessioni che avvengono sono questi e parliamo di connessioni reali piuttosto che apparenti (disegno)

L'esempio più classico è l'uso di un proxy come cache per ridurre le latenze e caricamento di pagine web.
Un'altro uso è quello di anonimizzare le connessioni web. Se pensiamo ad esempio al coriere della sera, non
riceveranno mai connessioni dalla rete interna ma sempre del proxy, quindi c'è un anonimato, quindi la mia identità è
nascosta dentro un gruppo, quindi non è possibile da parte del coriere della sera quale nodo ha effettuato il
collegamento, perchè qualsiasi collegamento apparentemente arriva da proxy (il numero IP del nodo è nascosto).
Quindi con i proxy si possono fare connessioni anonime, in cui l'indirizzo IP non è reso noto al server.
Ci sono altri due modi di uso del, proxy reverse per la sicurezza degli accessi e il proxy firewall.

Reverse Proxy

Non è molto diverso dai proxy per fare cache, ma di solito sta nella rete dei client e ripetono le richieste al server.
I reverse proxy invece stanno nella rete dei server e l'uso è analogo, disaccoppiano una connessione diretta.
Il reverse proxy è nella rete del sever(in questo caso facciamo finta che tra il reverse proxy e il web server ci sia un
firewall, anche se non è sempre detto ). Il client si connette al firewall, il firewaall si connette al reverse proxy. Nel
reverse proxy succedono una serie di cose(la connessione viene analizzata, autenticazione, filtraggio etc.) e solo dopo
si rivolge la connessione al web server.

Proxy Firewall
Opera a livello applicativo (è un firewall statefull, lavora tipicamente su http a livello applicativo), le sue performance
possono risultare critiche per la rete. Il proxy firewall viene messo come plugin di un firewall.

Può essere utile aver un proxy firewall per prevenire FTP Bounce: in questo attacco, ll comando FTP ,port (consente di
dire a quale porta deve fare il server la connessione), il comando port prende 6 parametri, i primi 4 sono gli ottetti che
costituiscono il numero IP del server e gli ultimi 2 vanno usati in questo modo: il penultimo và moltiplicato per 256 e
poi si somma l'ultimo(questo ci dà la porta).
Se ad esempio mandassimo il comando port 159.149.10.8 sulla porta 23, l'attaccante si connette al FTP server, e gli dà
il comando port. Il server deve aprire la connessione dati sul nodo 159.149.10.8 porta 23, l'ftp server apre questa
connessione ma la apre verso una macchina non coinvolta nel ftp ma un nodo che sta nella rete interna e che fornisce
il servizio telnet. Quando l'attacnte darà il comando RETR, avverrà una connessione telnet alla macchina interna e
apparentemente proverrà da un'altra macchina interna che è l'ftp server.
Per fermare questa possibilità il proxy firewall è adeguat, perchè conosce l'applicazione ed è in grado di iterpretare
l'applicazione.

NAT/ Masquerading
Sono 2 tecniche simili per nasconder una rete interna verso l'esterno.

Network address translation (NAT) e IP masquerading


L'idea è quella di manipolare gli indirizzi IP mentre il router li instrada, in maniera tale da poter utilizzare degli IP nella
rete interna che poi non vengono mai visti nelle reti esterne. Risultano una scelta privata della rete interna, quindi la
topologia e numero delle macchine risultano ignote all'esterno. Tipicamente viene usato sfruttando le classi di indirizzi
IP riservate e non instradabili (classe 10, 172.16-31 e 192.168) questi numeri secondo lo standard IANA non possono
uscire (Se un router riceve uno di questi numeri come pacchetto destinazione è tenuto a non farlo passare). Si usano
questi IP, li si manipola in modo che escano con degli IP pubblici, cioè che è possibile utilizzare nell'internet globale.
Questa è una tecnica che è nata come gestione delle reti, è una tecnica di visibilità di numero delle reti. Ha degli effetti
poitivi per la sicurezza, perchè delle macchine che dell'esterno non si sà l'esistenza, non sono attaccabili.
Ha l'effetto di mascherare gli indirizzi dei nodi interni della rete.

NAT
è una tecnica di manipolazione dei pacchetti a livello di rete o trasporto.
È un servizio fornito dal router che modifica gli indirizzi dei pacchetti prima di instradarli, il router si occupa di
manipolare il pacchetto in modo che appaia con un IP pubblico e poi di nuovo cambia i pacchetti quando entrano
mettendo come ip destinazione quello corretto. Per fare questa attività biosgna fare un mapping dei numeri IP interni
con i numeri IP esterni. Questo maping può essere statico, definita una volta per tutte in fase di configurazione, e il
ruter usa questa tabella per modifche ai pacchetti, oppure questa tabella può essere usata in modo dinamico.
Masquerading
è una forma di NAT, ma può lavorare a livello applicativo, quindi può fare queste manipolazioni a livello di protocolli.
Usa la port address transation, ossia l'associazione frail numero ip interno e numero ip esterno(o servizio interno e
servizio esterno), viene fatta anche modificando la porta sorgente(es. Porta 1027 viene mappata sulla porta 32536)
l'idea è che i servizi interni sono mappati su servizi publici che hanno porte diverse.
Il masqurading proxy conosce alcuni protocolli e adatta la conversazione alle nuove condizioni (per esempio FTP
INTRUSION DETECTION SYSTEM(IDS)
è un sistema di monitoraggio (generalmente passivo, cioè genera allarmi e non altre attività).

È un sistema che controlla traffico di un sistemo e genera allarmi e segnalazioni se qualcosa non và. Il
funzionamento di un IDS può essere schematizzato in 3 fasi:

1)Raccolta dati (monitoraggio)

2)Analisi dati

3)Generazione allarmi

IDS e firewall sono complementari: il firewall definisce i confini della rete, ma non si occupa di capire se
quello che entra nella rete sia buono o meno. Definisce i confini e quello che può entrare o meno, IDS
invece si preoccupa di quello che c’è dentro la rete e genera allarmi se qualcosa agisce in modo illecito.

Perché usare un IDS?

Non è possibili distinguere sempre alla frontiera il buono dal cattivo, la nostra prevenzione potrebbe sempre
fallire. Non è detto che non ci sia qualche attività che non vogliamo all’interno della nostra rete. Glli IDS
segnalano un evento che arriva totalmente da un’attore interno (a differenza del firewall). L’ids cerca di
automatizzare questa segnalazione, può avviare un processo di segnalazione/ gestione emergenza. Un altro
motivo importante è che oltre a essere strumenti di rilevamento intrusioni, con il fatto che raccolgono molti
dati sul funzionamento della rete si rivelano strumenti importanti per conoscere la rete. Il comportamento
reale non sempre al comportamento progettato.

HIDS e NIDS

HIDS

Esistono diversi ids, sono classificati in 2 dimensioni. Inanzitutto dal punto dove vengono raccolti i dati. I dati
possono essere raccolti a livello di host, ogni nodo potrebbe ospitare un ids che raccoglie i dati sul traffico
che raggiunge quel nodo. Generalmente l’intusion detection host based(HIDS), analizzano i log di sistema o
accesso file critici o determinate zone di memoria. Quindi sono sistemi che analizzano informazioni relative
ad attività locale di un singolo host.

NIDS

Oppure si analizzano dati a livello di rete. Si mettono sensori NIDS (network intrusion detection system),
sono comuni a tutti i livelli topologici (LAN, reti aziendali,carier,etc) è possibili avere questo rilevamento
intrusioni a qualsiasi livello

Rilevazione di eventi critici

Un’altra dimensione di caratterizzazione degli ids è la maniera con la quale analizzano i dati. Si analizzano i
dati per scoprire una situazione da essere rilevata. Le strategie a grandi line sono 2:

Misue detection: Cercare di riconoscere l’abuso (caso illecito), si sa riconoscere un attacco e quindi il
sistema genera un allarme (es. vedo nel mondo reale una rapina e do un allarme).

Anomaly detection: un’altra strategia è quella di caratterizzare un uso normale, anziché descrivere l’attacco
descrivo il modo giusto di comportarmi (Es: io dico che mi aspetto che in banca si vada in viso scoperto, se
qualcuno arriva con il passa montagna do un’allarme). In questa maniera è possibilie rilevare anche
un’attacco non riconosciuto. Tutto ciò che si discosta dal caso normale viene segnalato.

Misue detection

Si tratta di elencare al nostro sistema le situazioni illecite. Il codice penale è un esempio del misue detection
(se non c’è questa descrizione non è reato), queste leggi sono le cosiddette “signature”. L’amministratore
definisce questi pattern di misuse (abuso), e il sistema analizza gli eventi monitorati(rete, sistema,log,etc) e
se matchano uno dei pattern descritti si dà l’allarme. Questa è la tecnica più diffusa di intruction detection
(Gli antivirus funzione in modo simile usando una signature, dato che i virus sono composti da sequenze di
byte illecite note).

Problemi:

- Banalmente l’attacante può cambiare pochissimo dell’attacco noto, e l’ids non lo rileva più. A volte
questi ids sono così rigidi per una sequenza di byte, basta cambiare un bit non fondamentale per
quel attacco, e così non viene più rilevato.
- Sono così rigidi, perché se fossero flessibili sarebbero difficili da configurare.
- Un altro problema, se scriviamo una signature che definisce un’attacco (al nostro web server per
esempio), non è facile fare una signature per tutti i web server della nostra rete. Bisogna farne una
signature diversa per ogni macchina (lavoro complicato e oneroso). Tante aziende come lavoro
fanno signature per IDS (ad esempio snort uno dei prodotti che tratteremo, il prodotto è open
source però le signature più aggiornate in quel caso si pagano).
Anomaly detection

Si descrive il comportamento normale. La Anormalità è una anomalia.


- ad eventi singoli: esempio azioni “anomale” di un utente rispetto un profilo d'uso
predefinito, Per esempio come una richiesta al web server di questo tipo
http://example.com/##&<>623??% è anomala e come tale segnalata.
- L’anomalia può essere rispetto a dati agreggati, tipicamente è una deviazione rispetto a dati statistici
per esempio potrebbe essere il traffico con sorgente 123.45.67.88 è di 5GB al minuto

Vantaggi:
Non dipende dalla conoscenza puntuale di tutte le modalità di intrusione.
Un altro vantaggio quando si fa misuse detection si elencano pattern di attacco, quindi si rende pubblico che quel
attacco è possibile. (es. leggendo codice penale so che è un attacco che verrà rilevato), invece nell’anomaly non
abbiamo questo problema.
Svantaggi:
Fare un modello dell’uso normale non è affatto facile! La normalità cambia anche(quello che è normale oggi può
non esserlo in futuro). C’è un onore dello sviluppo della normalità che non è da poco.

Modelli di uso normale

Non è facile fare uso di modelli normale. Di solito si usa una fase di training del sistema in cui si usa il sistema in
maniera” normale”, così registro i parametri della normalità.
L’attività di trainging anche quella è un po' “anormale”, quindi in fase di test si rischia l’anomalia.
Richiede anche tecniche sofisticate per essero costruito(data mining, analisi baesyana,etc) mentre invece nel caso di
misuse detection è più semplice.
La normalità evolve quindi bisogna stare al passo. Questo monitoraggio è oneroso, perché bisogna tenere sotto occhio
parecchi paremetri che tengono d’occhio lanostra normalità.

Usi consolidati dell’anomaly detection: Ci sono alcuni casi in cui l’anomaly detection funziona:
- Hasing dei file(hids): Verificare l’integrità di un sistema rispetto a quella di una distriubzione originale. Ci sono
sistemi che usano l’hashing dei file(immaginiamo che nel nostro so ci sia un hash dei file, ogni volta segnalo
quando i file hanno degli hash diversi rispetto alla impostazione iniziale).
- Protocolli anomaly detection (NIDS): analizzo il traffico di rete rispetto alle specifiche del protocollo
applicativo.

Falsi Allarmi

In generale abbiamo falsi negativi e falsi positivi, i falsi negativi sono attacchi che non vengono rilevati, i falsi positivi
sono allarmi che però in realtà non corrispondono ad attacchi.
Falsi Negativi: attacchi non rilevati
Falsi positivi: attacchi rilevati corrispondenti a situazioni normali

In generali entrambi i falsi vanno bilanciati.


Quanto più la rilevazione è specifica (es. firme dettagliate) tanto più aumenta il carico computazionale e la rilevazione
diventa sensibile alle variazioni dell’evento analizzato.

Quanto più si fanno firme molto generiche, rilevo tutto e quindi anche un sacco di cose che non sono degli attacchi. Ad
esempio se metto come firma tutto, prenderò sicuro un sacco di attacchi ma che in realtà sono richieste leggitime
molte.

I falsi negativi (FN) e falsi positivi (FS) sono correlati inversamente. Se io aumento uno diminuisce l’altro!

Architettura NIDS
Un Network IDS, è sempre un complemento ad alte misure di sicurezza.Sono destinati a fornire allarmi buona parte
falsi, L’IDS è un complemento ad altre misure di sicurezza. In generale è una parte portante di “defense in depth”, cioè
un’architettura fatta a livelli di protezione, di cui uno di questi è l’IDS.
Importanti aspetti architetturali:
- Quanti sensori installare nella rete (tenendo presente i costi e complessità di gestione)
- Dove installarli (quantita e ridondanza informazioni)
- Come gestire i dati (analisi e logging centralizzato vs distribuito)

Sensori e firewall
Il sensore di un IDS può stare all’esterno o all’interno del firewall:
- Se lo mettiamo all’esterno possiamo rilevare tutto il traffico della rete, quindi abbiamo più dati, ma anche più
allarmi e falsi allarmi. Tra l’altro riusciamo ancha a rilevare dei tentativi.

- Un’altra possibilità è di averlo nella rete interna dopo il firewall,quindi si rileva solo il traffico che entra
effettivamente, si può usare anche per testare il firewall.

Risposta agli allarmi di un NIDS


Un ids raccoglie dati, li analizza e poi genera una risposta, generalemnte un’allarme!
Questo allarme deve essere colto da qualcuno e reagire in qualche maniera(dare una risposta).
A volte la segnalazione và elaborata e capire di cosa si tratta e capire la gravità della situazione.
L’allarme può essere di tanti tipi (anche acustico), ma la forma più standard è la scrittura nei file di log.
Esistono molte varianti di log implementate dai NIDS, tra cui salvatagio in formato tcpdump, scrittura su
database,visualizzazione video, etc.

Analisi:
Una volta che abbiamo questi dati li dobbiamo analizzare. I log che otteniamo sono molto onerosi da
guardare, non è facile vedere le minacce, esistono tantissimi strumenti che aiutano gli analisti a rilevare gli
allarmi (molti anche open source, e altri venduti con gli ids).
Tool di analisi: ACID, SGUIL,SNORTSNARF, symantec network security 7120.

Risposte automatiche:
Il sogno di tutti è avere dei tool che danno risposte automatiche, ovvero una modalità di allarme che genera
un’azione che permette di evitare il costoso intervento di un operatore. L’intervento costa molto perché la
persona deve essere molto ben preparata.

Tipologia di risposte:
- Session sniping (reset di sessioni): L’ids si prende il carico di rispondere al allarme interrompendo la
connessione. Non è una cosa banalissima dal punto di vista tecnico, non è facile interrompere una
connessione quando non si è una delle 2 parti coinvolte. Quindi bisogna in questo caso per terminarla bisogna
mandare un reset a entrambi, però che sia mandata da entrambi. L’ids deve fare finta di fare la controparte di
un e dall’altro (simile allo spoofing).

- Aggiornamento Firewall: aggiornare le regole del firewall, per filtrare quel tipo di traffico.è tecnicamente più
semplice. Una volta che ho rilevato qualcosa di pericoloso, posso generare una regola di firewall che filtri quel
traffico. Per esempio un attività di scan su una certa macchina, sarà messo in black list tutti gli ip sorgenti
coinvolti nello scan.Questo metodo È meno efficace, perché nulla vieta che l’intruso lo usi a proprio vantaggio,
l’attacante può mandarmi dei pacchetti che mi fanno tagliare fuori qualcuno che non dovrebbe essere. Quindi
possono introdurre facilmente delle configurazioni del firewall che sono limitanti rispetto le prestazioni del
sistema. Per evitare questi problemi, basta mettere un tempo limitato in blacklist.

Considerazioni Conclusive degli IDS


- Gli ids come qualsiasi come misura di protezione può essere eluso o aggirato.
- Soprattutto nel caso degli ids misuse, questi ids si prestano ad essere illusi variando la forma dell’attacco non
cadendo più nel pattern descritto nella signature e passare inosservati dall’ids.
Per esempio una regola dice che va segnalato come problema alla richesta qualsiasi richesta verso un determinato file
(esempio etc/passwd.). l’attacante potrebbe aggirare questa regola usando dei formati equivalenti (come ad esempio
etc/\ passwd o etc/rd.d/../passwd). Occorre riportare la regola a nomi canonici.
- Tecniche di evasione più sofisticate sfruttano pacchetti frammentati per la loro difficoltà di gestione.

- Se ci sono meccanismi di risposta automatica può essere usato dall’attacante per creare danno al sistema che
viene protetto

- Le risposte sono costose!

ZERO DAY E BOTNET


Attacchi imprevisti

I NIDS si basano sulla assunzione di saper caratterizzare un attacco. Hanno un modello che generalmente è una stringa
dell’attacco che si vuole evitare. Bisogna sapere che attacchi bisogna evitare e come sono fatti. Abbiamo visto che
questo tipo di rilevazione basata nella maggioranza dei casi sulla rivelazione di una stringa. Queste signature o firme si
scrivono così: l’analista cerca possibili vulnerabilità del sistema, e cerca di rappresentare tutti i possibili attacchi che
possono usare la vulnerabilità. Un’altra possibilità è accorgersi che c’è stato un exploit (uno sfruttamento di qualche
vulnerabilità), abbiamo visto un attacco, e da quel momento in poi non vogliamo che si ripeta. Quindi le 2 strategie
sono:

- Partendo dalle vulnerabilità


- Partendo dagli attacchi ricevuti

Zero day

Un’attacco può essere del tutto inatteso, il nome in gergo per questi attacchi inattesi sono “zero day”. Il giorno
zeresimo in cui precede un attacco noto, ovvero è un attacco non noto agli IDS.

Finestre di vulnerabilità

La finestra di vulnerbailità è l’intervallo temporale da cui la vulnerabilità è nota all’attacante a quando il difensore
capisce come ci si può difendere da quel attacco. Quindi è un intervallo temporale in cui è possibile attaccare.

Ricerca delle vulnerabilità

È un mestiere molto complesso, e se ne occupano i laboratori di sicurezza. Attività molto diffusa, quello che
fanno queste persone è di analizzare i programmi e sistemi per identificare se ci sono vulnerabilità che la
gente non conosce. Questi laboratori hanno varie politiche per rendere pubbliche queste vulnerabilità, di
solito il primo che avviene avvertito è il produttore del sistema oppure lo si rivela al mondo (strateggia
aggressiva e pericolsa, perché rivela l’esistenza anche ha chi ha cattive intenzioni). La ricerca delle
vulnerabilità non note e gli attacchi zero day hanno vulnerabilità non note, e hanno un mercato florido
(aziende danno taglie per chi trova vulnerabilità sui propri prodotti).

Tecniche per la ricerca


Ci sono 3 strategie:

- Studio analitico: si ragiona sulle specifiche di applicazioni e protocolli, è un campo di ricerca molto evoluto.
- Fuzzing: Tecnica rozza ma efficace, si provano nelle applicazioni e protocolli dandogli input strani prodotti
casualmente. Si prende qualche sistema e lo si bombarda di input strani. Si spera che in questa maniera si
vadano a sollecitare condizioni operative che l’uso normale non solleciterebbe. Molti attacchi sfruttano casi
particolari di input, questo sistema ha una probabilità bassissima di trovare casi realistici di attacchi, ma
costano poco e quindi si possono fare ricerche che durano molto
- Honey pot (vaso di miele): è un sistema che viene messo li e non fa nulla. Dato che è in una rete appetibile,
qualche attacante proverà ad attacarla, e provando ad attacarla lascerà delle tracce di come l’attacco è
avvenuto, e registreremo tutto il traffico dell’attacco. Questa tecnica non è stata così efficace perché si
raccolgono solo attacchi di tipo automatico, ma non quelli rilevanti o nuovi attacchi. Un attaccante intelligente
terrà i trucchi più forti per cui sa bene che hanno un valore.

Poliformismo degli attacchi

Conosciamo una vulnerabilità, ma non vuol dire conoscere tutti gli attacchi che sfruttano quella vulnerabilità. Esempio
lasciamo la porta aperta di casa, ma nessuno ci dice come uno entra. Noi possiamo bloccare tutti quelli che entrano in
bicicletta, ma non uno che entra invece con la automobile. Gli attacchi hanno una natura poliformica, ovvero che
hanno più varianti, e individuarle è difficile.

Tecniche di Poliformismo

cifratura del codice: una delle tecniche più diffuse.

- Per ogni attacco viene generata una chiave casuale.


- Il payload dell’attacco appare sempre diverso.
- L’unica parte di codice costante è una piccola routine di decifratura (possono bastare 3-4 istruzioni: esempio
cifratura XOR)
- Anche la cifratura può essere variata con tecniche di poliformismo

dead-code insertion: aggiungere codice senza modificare il comportamento.

La tecnica più semplice è inserire nop oppure inserire tante istruzioni che si annullino tra di loro.

Code transposition: sposta le istruzioni in modo che l’ordine del codice binario sia differente dall’ordine di esecuzione,
riordinano casualmente blocchi di istruzuoni e isnerendo salti incodizionati(facile da fare automaticamente).Possono
anche mischiare istruzioni indipendentidi (richiede analisi sofisticate del codice).

instruction substitution: dizionari di sequenze di istruzioni equivalenti, che possono essere sostituite tra loro.

register reassignment: sostituisce l'uso di un registro con un altro equivalente.

Generatori di signature (o firme)

L’idea di base è che si possa riuscire a generare le varianti possibili di un’attacco conoscendo le caratteristiche delle
vulnerabilità e magari di un certo numero di attacchi. Si sa la vulnerabilità, si sa quali cartatteristiche devono avere gli
attacchi, si ha un certo numero di attacchi, si cerca di generralizzare la firma per comprendere tutte le possibili varianti.
Così è possibile rilevare programmi che non sono ancora girati ma che possibilmente potranno girare.

I generatori di signature possono essere classificati sotto 2 grandi categorie:

Semantic-based: si ha un qualche modello di un comportamento di un attacco, si geenra una firma in abse a questo
comportamento.Molto poco utilizzati, perché l’implentazione è molto dispendiosa

content-based: abbiamo già visto che la maggior parte degli ids fanno pattern di stringhe, l’idea della strategia è di
cercare delle invarianti che comunque rendo polimorfo il mio attacco dovrà esserci. Se c’è un invariante mi focalizzo su
quello.

HAMSA
Per parlare più concretamente di un esampio prendiamo un prodotto di ricerca(è stato proposto nel 2006 in un
congresso grande di security) che prende il nome di Hamsa. L’obbiettivo era quello di generare firme che fossero in
grado di bloccare zero day,ovvero attacchi ignoti alle IDS. Anche se era ignoto al’ids l’ids lo conosce grazie alla
classificazione automatica. Hamsa deve essere usato a livello di rete dove c’è molto traffico. La strategia usata è
content-based. L’attacco è fatto da una serie di byte classificati categorie che sono invarianti(ad esempio se voglio
parlare con http devo fare comandi http). Quindi l’invariante c’è di sicuro ma non per forza identifica l’attacco.
Nel gergo di Hamsa c’è il code byte, che è una parte che potenzialmente può cambiare, ma che sostanzialmente deve
fare una certa cosa (la parte dell’attacco), qui l’attaccante si metterà nel poliformismo. Questi sono i byte che servono
per sfruttare la vulnerabilità. Poi c’è una terza parte di byte che può assumere qualsiasi valore perché sono irrilevanti ai
fini dell’attacco.

Sintetizzando:
invarianti: byte il cui valore e fissato a priori e la cui variazione implica il fallimento dell'attacco
code byte: parte potenzialmente polimorfica, ma con una semantica fissa
wildcard byte: possono assumere qualsiasi valore

Esempio: Lion Worm

Un esempio reale, il lion worm, è un worm che si propaga con richieste DNS. Essendo richieste DNS sono parti fissate
del protocollo, e quindi sono invarianti (altrimenti sarebbero scartati, ci devono essere byte uguali per tutti stabiliti dal
protocollo). Poi ci sono dei byte varianti che dipendono dalla furbizia dell’attaccante e li varieranno per fare funzionare
l’attacco. Ci sono poi dei byte di codice , questi byte realizzano veramente l’attacco, e ogni volta saranno
potenzialmente diversi.

Architettura Hamsa
Raccoglie il traffico con uno sniffer di rete, divide il traffico il flussi per ogni porta destinazione(25,53,etc.).
Si lavora con una serie di attacchi di worm noti, il traffico che è stato suddiviso in flussi, arriva al classificatore di flussi
che tiene conto dei warm noti e sostanzialmente produce un insieme di flussi sospetti e un inseme di flussi innoqui,
oltre ciò identifica anche gli invarianti dei flussi considerati sospetti e gli nvarianti dei flussi innoqui. Tutto ciò va in
pasto al generatore di signature, che tramite un algoritmo genera le signature.

Sostanzialemte i 3 componenti fondamentali di Hamsa sono:

classificatore di protocolli: considera i flusso TCP (o i pacchetti UDP) e li classifica secondo la


porta destinazione
politica di selezione: indica quali flussi prelevare e inviare al generatore di signature
generatore di signature: genera le signature, considerando i flussi innocui e sospetti

Firme di hamsa

Sono dette conjuction signature: consiste in un insieme di stringhe e un flusso viene


considerato malevolo se contiene tutte le stringhe, indipendentemente dall'ordine.
Si tratta in realtà di multi-insiemi di token, cioè insiemi in cui un elemento può apparire piú
volte.

I token indicati devono comparire in un unico flusso e con un numero di occorrenze maggiore o
uguale a quello indicato.

Algoritmo generazioni firme

Si prendono dal classificatore un insieme di flussi malevoli M, un’insieme di flussi innocui N, e


un insieme di invarianti i. si crea una signature vuota, per ogniuna delle invarianti lo si prova
ad aggiungere, si calcolano i falsi positivi e veri positivi, si fa una valutazione se ha
carattersitiche accettabile e se è il migliore trovato al momento lo si tiene.
Dentro ci sono una serie di formule per valutare la bontà di una firma.

Attacchi ad Hamsa

- Target feature manipulation Si cerca di variare le parti considerate invarianti.


- Innocuous pool poisoning: prima di iniziare la diffusione vera e propria e quindi prima di
lanciare un attacco verso una nuova macchina, ci si preoccupa di inviare una serie di
pacchetti leciti contenenti ciascuno un invariante inserito nelle parti di traffico che
possono essere modificate a piacere.
- Suspicious pool poisoning l'attaccante incorpora finti invarianti all'interno dei flussi
malevoli per portare alla generazione di signature che dipendono da tali finti invarianti
al posto o in aggiunta agli invarianti veramente necessari.

La diffusione del malware

Con malware intendiamo tutto l’universo del sofftware che ha un effetto malevolo nella
macchina a cui viene applicato.
Il malware viene diffuso sfruttando vulnerabilità generiche allo scopo di compiere attacchi piú
redditizi. L’incentivo a diffondere malware generico (e non un obbiettivo specifico) perché è il
sottofondo di attacchi ben più redditizi, che poi saranno più specifici ma grazie alla
infrastuttura che il malware crea.

Phishing: è una truffa che si fa una campagna di spam (messaggi di posta e sms) con una
qualche offerta commerciale con qualcosa che convinca l’utente a cliccare in uno dei link nei
messaggi di spam e fare qualche richiesta get http voluta dall’attacante(ovvero inserire dei
dati). Normalmente nessuno andrebbe a caricare sti siti che sono la copia di un sito vero che
generalmente danno servizi finanziari(di solito banche e poste). Qui si vuole che l’utente carichi
la pagina del sito fasullo credendo sia il sito vero. L’utente credendo di parlare con il sito vero
inserisce le credenziali o scarica del materiale malware, fidandosi che sembra un sito affidabile.
L’incentivo a fare phishing permette di rubare credenziali,(ad esempio bancarie) ciò permette
di fare operazioni(generalmente importi piccoli, che se sono svolte in una serie di passaggi
internazionali la possibilità di perseguire il reato sono piccole). La campagna di spam per
essere efficace deve affidarsi a una serie di macchine che mandino queste camapgne email,
eprchè da un normale account di posta si viene bloccati a mandare tante email. In questo caso
il malware è un server di posta eletronica che è analogo a un server normale, ma inserito a
insaputa dell’utente che fa da vettore dello spam. Il malware serve a pasturare l’ambiente per
attacchi come quello del phishing.

Captcha: permettono di distinguere un utente da un servizio gratuito, sono tipicamente figure


di scritte non facili da interpretare automaticamente. È possibile che esistano gruppi di persone
pagate per risolvere i captcha per distribure le soluzioni.

Click fraud: una delle trovate vincenti di google è l’attività di advertisment, paghi che qualcuno
ha cliccato la pubblicità (se metto un cartello in piazza del uomo, non sapremo mai quante lo
hanno guardato), google fa pagare in base ai click sulla pubblicità. Google stessa dice che
sottostimando l’entità di questi clcik, il 10% sono fraudolenti (circa un miliardo di dollari viene
prodotto così), ci sono clickbot che cliccano al posto delle persone, questo genera traffico click
che ha valore. Magari per fare pagare la pubblicità dell’avversario(ci sono tecniche per ridurre
l’impatto su ste cose).

Botnet
Sono una seri di macchine compromesse che sfruttano altre macchine compromesse per
nascondere l’esistenza di macchina controllate sotto il cosiddeto”bot master”(colpevoli botnet),
questa serie di computer multilivelli diventa praticamente impossibile andare a beccare il
botmaster(in alcuni casi ci è riusciti tramite intelligence).
Conficker era la botnet più grossa (9 milioni di nodi).
Le botnet non venegono usate solo per spam, ma anche per conservare informazioni rubare

Tecniche propagazione:
La prevalente era la condivisione di file di fonti ignote

Botnet Fast-Flux

Ricordiamo che una botnet (rete di bot), i bot sono macchine infette compromesse, controllate
da un unico attaccante(bot master), c’è qualcuno che è in grado di controllare tante macchine
infette. Sono usate per tutti quegli attacchi di secondo livello spam,ddos,phising,etc.

Le botnet che usano per costruire la propria infrastruttura o meglio nascondere la propria
topologia, dal punto di vista del bot master è importante fare in modo che non risalgano a lui.
La fast-flux è una tecnica nel 2007 ben conosciuta e in parziale declino, è una tecnica che
permette di nascondere la topologia della rete botnet. È difficile identificare il controllore o
colpevole, l’idea che sta dietro queste fast -flux è usare un livello di indirettezza ceh viene
costruito sfruttando la struttura del dns, questo livello rende difficile collegare le vittime e
l’attaccante.

Tecnica:
- Macchine rosse: macchine dell’attaccante o che l’attacante ha un controllo diretto
- Macchina verde: vittima
- Name server non-authoritative: non è comprmesso è un DNS server chef à il suo
mestiere.

Botnet nasconde i veri (quelli rossi), la mediazione è fatta nella rete con gli agenti infetti.
C’è stata una campagna di spam o ho convinto la vittima a chiedere la risoluzione di un
indirizzo di rete(tipicamente indirizzi strani, esempio tje.mooffx.com.cn), c’è questa
richiesta della vittima al suo DNS server. Essendo il serve dns non autorevole, gira la
richiesta al DNS autorevole per quel dominio.
Quello che fa il DNS ha il ruolo di distribuire come di risposta una serie di IP che
corrispondono agli agenti infetti. Quando questa risposta alla vittima e quando cercherà di
connettersi a questo sito, in realtà si connetterà agli agenti infetti o i quali contengono del
malware, poi andranno a rigirare queste richieste a mother-ship, e a questo punto fa
l’attacco. Quindi c’è l’attacco da qualche tipo fatto dal rosso ma con il livello di indirettezza,
la vittima vede l’attacco arivare da questi agenti, segnalerà gli agenti e non il vero
attacante. Non è facile costruire la struttura, è una struttura molto flessibilie. La rete
potrebbe esserefatta da milioni di agenti. Gli agenti individuati e disnifettati vengono
immediatamente rimpiazzati da altri.

Non basta neanche ad andare a beccare un registratore di domini collaborante e chiuderlo.


Ogni botnet non ha solo un dominio, ne ha un sacco! I registratori di nomi di dominio(come
cina e russia) queste cose sono regolate in maniera un po' lasca, fanno questo mestiere di
registrare il nome di dominio a pagamento e non hanno nessun interesse a fare verifiche,
quindi si registra questa associazione con tanti ip e la si usa nella botnet.

Protezione di servizi infrastrutturali


Protezione dei servizi critici
L'accesso ai servizi critici è controllato
- Autenticazione: chi è l'agente (che opera in nome di un principal)
- Autorizzazione: l'agente autenticato ha il permesso?
Le due cose di solito avvengonono contemporaneamente, ma sono logicamente separate.
L’autenticazione dice chi è l’agente(programma,utente,etc), autenticazione vuol dire dare
l’identità di chi accede al sistema.
L’autorizzazione si sa una volta che so chi è la persona, il sistema decide se ha il permesso di
fare determinate cose.

Autenicazione
Autenticare significa verificare l'identità di un soggetto (non necessariamente umano).
L’autenticazione mediata dalla rete è diversa rispetto una localmente. Bisogna verificare
l’identità di un soggetto, valutare l’affidabilità di una qualche prova di un soggetto.

Ci sono 3 Modalità di base per l'autenticazione (di Alice) tramite rete:


1. password (ossia la conoscenza di un segreto)

2. locazione (logica o fisica) da cui proviene la richiesta di autenticazione: non è


necessariamente una coordinata gps di un terminale, ma può essere logica o fisica (es. il
numero ip, permette le richieste da un terminale che arrivano da un determinato ip, ma non è
un buon modo dato che ip può essere modificato)

3. per mezzo di operazioni crittografiche su dati forniti dall'autenticatore(Bob)

Pericoli:
Alcune vulnerabilità sono intrinseche:
- Le password possono essere indovinate
- Le locazioni possono essere millantate (ovvero falsificata)
- I dati crittografici possono essere intercettati e riutilizzati (replay attack)
Difese:
- Queste minacce possono essere mitigate:
- Aumentando la cardinalità delle password possibili
- Controlli di coerenza:andremo a vedere se quella locazine è coerente con le altre
informazioni che riceviamo dal soggetto.
- Crittografia a chiave pubblica e protocolli articolati, per il replay in particolare, si usano
numeri usati una sola volta.

L'autorizzazione conseguita con l'autenticazione dura un intervallo temporale detto sessione.

Password guessing
- Una password può essere scelta in maniera prevedibile (anzichè del tutto casuale) nell'
insieme possibile.
- Online guessing: l'attaccante prova tutte le password possibili (brute force); si limitano i
tentativi e/o si rallenta il feedback.

Offline guessing

Offline guessing: l'attaccante accede all'elenco dei segreti (generalmente crittati con hash) e
prova elenchi di parole (dictionary attack); si salano gli hash.

- Possibilità di intercettazione
- Utilizzo in occasioni differenti
- distribuzione iniziale delle credenziali (si fanno scadere al primo accesso).

Credenziali generalizzate
Credenziali generalizzate Alice può provare la sua identità mostrando:
- qualcosa che sa (password tradizionale)
- qualcosa che ha (authentication token)
- qualcosa che è (biometria)
- E naturalmente possibile (e spesso desiderabile) avere autenticazioni a più fattori.

Client inaffidabili
La diffusione del malware ha reso spesso inaffidabili i client.
L’autenticazione è mediata da strumenti software, i client sono spesso affidabili dei server,
perché sono su macchine meno protette che possono ospitare malware. Questo può rendere
inutile l’autenticazione:
- Se il client è inaffidabile(compromesso), lo sa anche il malware che lo compromette e
conoscere il segreto trasmesso
- L’utente può essere convinto di parlare con il server, invece parla con qualcun altro
dando informazioni per fare cose diverse(Phising, siti falsi che pescano le credenziali di
utenti sprovveduti).

Chi garantisce che la schermata


di login non sia un cavallo di Troia capace di memorizzare/rubare le credenziali?

I tastierini:La protezione del “tastierino" che cambia ad ogni login è puramente apparente.
Se il client può essere compromesso, può darsi che un malware registri la pressione dei tasti,
ma un altro magari registra le coordinate del mouse o la schermata. Se il client è
compromesso è totalmente inaffidabile!
Un esempio di falsa sicurezza, che tra l'altro impedisce all'utente di utilizzare meccanismi
automatici di memorizzazione delle password.

Anti-malware
Contro client alterati è difficile proteggersi, ma protezioni più efficaci sono:
- In ogni sessione viene comunicata solo parte della password
- Two-factor authentication (2FA)
- One-time password (OTP)

Altri attacchi
Nessuna di queste misure protegge da:
- Man in the Browser: il client alterato non si limita ad intercettare le credenziali, ma è in
grado di manipolare i dati della transazione.
- Session hijacking: l'attaccante è in grado di manipolare una sessione già in corso.

2FA
Due (o più) meccanismi di autenticazione: una password e il possesso di un oggetto fisico:
p.es. un security token o un telefono cellulare.
è importante che i due fattori siano effettivamente indipendenti.

Security token
I più diffusi si basano su Synchronous dynamic password: la password cambia ad intervalli
regolari, per esempio ogni minuto. La sincronia è un fattore critico.

One Time Password


In generale si tratta di password utilizzate una volta soltanto e pertanto non riutilizzabili da un
eventuale intercettore.
L'effettivo possesso di un security token è generalmente verificato tramite una one time
password generata dal token stesso o richiesta out of band.

Lo schema di Lamport (vedere lezione SSR_M4_U1_L3)


Leslie Lamport nel 1981 ha proposto uno schema per autenticazione tramite OTP(one time
password) ogni volta si usa una password diversa, ha una particolarità, ovvero che non
prevede la necessità di sincronizzazione temporale.
L’unica cosa che serve perché questo schema funzioni, è una funzione di hash (quindi non
invertibile, es. md5)
L’algoritmo funziona cosi:
Alice si deve autenticare con Bob e condividono un segreto (W) la funzione di hash che
useranno è H.
Concordano un segreto ad esempio “pippo”, bob non conserva pippo ma in realtà l’hash di
pippo n volte(esempio md5 di pippo che da un numerone, l’hash di questo numerone, l’hash di
nuovo ottenuto dal numeron e così via). Dopodichè conserva l’hash cha ha ottenuto e il
numero di volte(ad.es 100) che ha applicato la funzione H.
L’autenticazione avviene così:
Alice dice” sono alice”. Bob per verificare che si tratta davvero di alice, gli dice il numero N
(Bob dice “guarda io ho questo numero 100”). Alice genera dalla password pippo, un hash,
questo hash viene generato n-1, quindi la funzione viene applicata una volta in meno (in
questo caso 99 volte) , ottenendo un hash diverso da quello di bob, ma per bob è facilissimo
verificare se si tratta della cosa giusta perché basta riapplicare la funzione di hash (per ottente
il 100esimo hash).
Lo schema funziona n volte, poi bisogna cambiare W.

1. Alice e Bob concordano un segreto W


2. Bob conserva H(: : : H(H(W)) : : : ) = Hn(W) e n
3. Autenticazione:
3.1 Alice comunica la propria username
3.2 Bob risponde con il numero n
3.3 Alice comunica x = Hn-1(W)
3.4 Bob verifica che H(x) = Hn(W) e decrementa n
Lo schema funziona n volte, poi bisogna cambiare W.

S/KEY (versione schema lamport diversa)


Lo schema di Lamport è stato implementato da Neil Haller, Phil Karn e John Walden in S/KEY.
Usa numeri a 64 bit + 2 bit di parità.
Stringhe casuali di 8 caratteri sono difficili da utilizzare per un utente umano, è
prevista una mappatura su 2048 parole da 1 a 4 caratteri: i 66 bit diventano una
sequenza di 6 parole

Questo sistema Ha delle vulnerabilità: Non protegge da Man in the Browser o Session
Hijacking. Più grave è l'attacco con n piccolo:

Bob conserva il numero n (es.100), un attaccante che si mette in mezzo, Mallory, si sostituisce
a Bob (tipo phising). Ad alice comunico un numero più piccolo di n (es.67), alice Manda la
funzione hash di 66. Il problema è che Bob è fermo a 99, Mallory si è appropriato di un dato
che potrà utilizzare fra un pò per sostituirsi ad alice quando Bob arriverà a conservare n
segnali. Sostanzialmente è un replay attack, in cui il replay lo faccio in un momento diverso.

Un modo per mitigare questo attaco, è di fare conservare l’n corrente anche ad alice(se
eravamo a 99, e trovo uno che mi chiede 67, c’è qualcosa che non và si genera sospetto e si
prendono le decisioni per difendersi)

1. Bob conserva il numero n


2. Mallory impersona Bob e manda ad Alice un n0 < n
3. Alice risponde con Hn0(W)
4. Mallory potrà usare Hn0(W) per sostituirsi ad Alice quando Bob arriverà a conservare n0

Mitigato rendendo Alice edotta su n corrente, in modo che possa insospettirsi per eventuali
n’ << n

Paper Lamport
Funziona bene con modalità “carta e penna".
Do ad alice una lista di hash già prodotti,ogni volta alice si cancella quello che ha usato.
L’attacco non è più possibile perché tengo traccia al punto in cui sono arrivato.

- Alice conserva una lista cartacea di password (Hn(W);Hn-1(W); : : : )


- Una volta usata la prima della lista la cancella
Questo schema non è suscettibile all'attacco di n piccolo, ma la lista è naturalmente un punto
critico.

Riassumendo: Lo schema di Lamport


- Un meccanismo algoritmico per OTP
- Si basa sull'esistenza di funzioni di hash non invertibili
- Vulnerabile all'attacco ‘n piccolo.

Metodi crittografici per l’autenticazione in rete


Challenge/Response

È Il meccanismo di base basato sui protocolli crittografici.


Nel passaggio 1 alice dichiara di essere alice, nel passaggio 2 Bob manda un numero Random ad
Alice, alice risponde criptando con una chiave k condiviso tra Alice e Bob e questo permette di
autenticare.

L’autenticazione non è reciproca! Qualcuno può sostituirsi a Bob.


Non solo, ma se ho sia r che K ab R, posso provare tutte le chiave finchè non la trovo(dictionary
attacc).

CHALLENGE RESPONSE CON AUTENTICAZIONE

Ripetiamo lo schema da una parte e dall’altre:


Sono necessari ben 5 scambi, si può rendere più efficiente facendone solo 3 e comprimendo gli
intermedi in 2 passaggi:
Quando uno dice sono alice, dice anche il numero casuale (r2), bob risponde sia con il numero
casuale che la chiave e poi ultimo c’è Ka{br}

Purtroppo si presta ad un reflection attack:


Inoltre si presta all'offline guessing (anche senza intercettazione!).
Quindi adotiamo questo schema:

Needham-Schroeder
Per semplificare la gestione dei segreti condivisi, possono essere introdotti dei Key Distribution
Center (KDC). Needham-Schroeder
[1978]

Ma è vulnerabile:
Qualora KAB sia compromesso (p.es. accedendo alla macchina di
Alice) è possibile un replay attack del ticket, quindi occorre complicarlo ulteriormente
introducendo dei timestamp, in modo che i ticket non possano essere riutilizzati.
Un'evoluzione(molto diffusa) che include i timestamp è Kerberos.

Riassumendo: I protocolli crittografici possono essere molto utili


- Permettono mutua autenticazione
- Occorre fare molta attenzione alle possibilità di replay
- La gestione delle chiavi è architetturalmente la faccenda più complicata

Il single sign-on (SSO)


Il sso vuol dire utilizzare un’unica qualità di credenziali per accedere a servizi diversi, quindi
accedere con una credenziali a diversi servizi. Il servizio web è critico su questo, perché sono
indipendenti l’uno dagli altri.
L'idea di avere credenziali uniche che permettono l'accesso a sistemi diversi è appetibile per
una serie di ragioni:
- Riduce il problema di trovare un buon segreto (se dobbiamo trovare su 100 serivizi diversi
100 password buone e ricordarle è problematico.)
- Riduce l'overhead totale di gestione degli accessi, perché se devo accedere a 100 servizi con
autenticazione diversa, io in una giornata ne uso 15, devo fare 15 procedure di autenticazione,
quindi verrebbe ridotto la gestione dell’overhead
- Permette la gestione centralizzata degli accessi, più semplice da manutenere (Aumenta la
criticità delle credenziali, però)
Architettura di base
La maggior parte dei protocolli sso sono disegnati sull'impronta di
Kerberos, che è una variazione con timestamp del protocollo Needham-Schroeder.
Un Ticket-Granting Server (TGS) fornisce ticket d'accesso a scadenza.

Kerberos

Il SSO sul web


Il SSO sembra particolarmente attraente in situazioni come i servizi web a bassa criticità:
- Decine di password da ricordare
- Utenti poco sensibili al problema all’autenticazione(molti non danno un attribuzione a
questa sicurezza, usano password indovinabili e peggio le usano per tutti i servizi)

Ma soluzioni tipo Kerberos sono difficili da adottare, perchè occorre che servizi indipendenti
concordino sulla KDC.

OpenID

L'idea è che esistano siti che facciano da OpenID provider (OP) e gli OpenID Consumer (OC)
accettano come credenziali quelle che gli utenti ottengono dagli OP (cui sostanzialmente gli OC
delegano l'autenticazione).

Esempio: supponiamo che google sia un OpendID provider. Alice vuole collegarsi a Facebook,
che è un OpendId consumer. Invece di autenticarmi con Facebook, dirò a facebook “guarda di
solito mi loggo con google”, quindi alice comunica che si collega a facebook tramite google.
Alice si autentica tramite google, google emette un certificato della avvenuta autenticazione
che l’openID Consumer accetta come prova dell’autenticazione. Facebook si fida della
autenticazione di google. Sostanzialmente Facebook accetta la delega di google.

Lo schema di open id:


1. Alice si connette al sito meraviglie.org
2. Per accedere comunica che ha un account su faccialibro.com/openid/alice
3. Alice accede (con credenziali tradizionali) a faccialibro.com e produce un certificato d'accesso
4. meraviglie.org accetta il certificato d'accesso come credenziale d'autenticazione

Problemi e principali rischi di open id:


- Facilità di allestire inganni di tipo phishing
- Privacy

Alternative migliori
In realtà sembra meglio avere credenziali multiple e gestirle con modalità come:
- PasswordSafe (http://passwordsafe.sf.net): un db criptato
- SuperGenPass (http://supergenpass.com/): un'unica password viene giustapposta ad un
identificatore del sito e la vera password è ottenuta con una funzione hash

(DHCP)Dynamic Host Configuration Protocol


è un elemento critico nelle reti in cui i numeri IP sono assegnati dinamicamente.
Il dinamismo è sempre fonte di incertezza e insicurezza, la staticità invece no, però il
dinamismo è comodo dato che il mondo cambia.
Il vantaggio principale in questo caso è:
- Permette configurazioni dinamiche delle topologie di rete (quindi aggiornate), se
abbiamo una rete fatta di molti nodi è probabile che la cambieremo. Un altro esempio ci
si collega a reti telefoniche che sono dinamiche.

- Ma non prevede forme di autenticazione (ipotesi trusted LAN), quindi il DHCP è privo di
forme di autenticazioni sicure

Il DHCP la sua funzione è quella di:


- Assegna i numeri IP: in realtà assegna configurazioni, più che numero IP. È un
protocollo per configurare i nodi di una rete in maniera dinamica.
- Default gateway: come fare l’instradamento per uscire dalla rete, il gateway è un router
di interfaccia tra una Lan e l’esterno.
- DNS server: quale macchina fornisce il servizio di risoluzione degli indirizzi simbolici.

Anche i numeri IP in contesti in cui i nodi sono in variazione, ci possono essere problemi di
esistenza di IP per tutti i nodi, quindi vengono assegnati degli IP ai nodi che sono collegati
in quel momento nella rete(questo Fanno gli ISP Gli isp non danno ip pubblici, ma ip di una
qualche intranet).
Particolarmente adatto nelle reti la cui tipologia cambia continuamente (es internet service
provider).

Funzionamento del protocollo


1. L'amministratore della rete mantiene un pool di configurazioni(insieme configurazioni
che verrranno assegnate) sul DHCP server.

2. Quando un client si connette alla rete (spesso al boot) fa broadcast di una richiesta di
configurazione. Quando un Client si connette alla rete e non ha ancora un IP (immaginiamo
che si collega alla LAN,) fa broadcast, chiede a tutti i nodi della rete locale una configurazione.

3. Il DHCP server che riceve questa richiesta, prende una configurazione del pool che non è
stata assegnata a nessun altro, e gliela comunica.

Il protocollo
1. La richiesta broadcast che lancia il client si chiama DHCPDISCOVER
2. Il server risponde con un messaggio DHCPOFFER
3. Se accetta, il client fa broadcast di DHCPREQUEST (il broadcast serve a rispondere anche ad
eventuali altri DHCP server, in modo tale che sanno che ha ha già accetta una connessione da
un altro server, ovviamente il messaggio contiene l’indirizzo del server)
4. Il server DHCP risponde con un messaggio DHCPPACK che tiene la configurazione da utilizzare

Vulnerabilità
Il protocollo lavora a livello di rete locale in cui i nodi:
L’idea è che ci sia un mezzo trasmissivo condiviso(broadcast). Il client parte con questi
messaggi in broadcast, i nodi che partecipano al DHCP in qualche modo (almeno i client) non
hanno ancora IP, vengono identificati con Il MAC che è estramente debole perché sono molto
facili da falsificare.

Qunidi ricapitolando le debelozze sono:


- condividono il mezzo trasmissivo
- sono “identificati" dal MAC

Address starvation
Si muore “di fame di indirizzi”. Il server DHCP ha un numero finito di configurazioni, l’idea che
può venire a un’attacante è creare un denial of service (DoS), l’impossibilità di connettersi a
quella rete, perché senza una configurazione DHCP non ci si connette.
Questo attacco viene fatto mandando tante richeste con dei MAC differenti, facendo finta di
essere tanti client differenti. Il server DHCP vedrà tutte queste richieste e risponderà
assegnando a ciascuno un pool, così verrà esaurito, e così client leggitimi non riusciranno ad
avere una configurazione.

sintetizzando:
- manda molte richieste, con MAC differenti
- il pool si esaurisce
- client legittimi non riescono a ottenere una configurazione

Contromisure

Una parziale contromisure che ha il protocollo è che le configurazioni non vengano assegnate per sempre,
ma possano contenere una durata, quindi la configurazione viene assegnata per una durata(questo viene
chiamato leasing, nollegio di una configurazione). Quindi la configurazione viene noleggiata a un client, poi
torna al server per riassegnarla a un altro client.

Se io sono un’attacante, probabilmente basta che faccia delle richeste, tengo conto del tempo di leasing.
Oppure se scade il lesagin richiedo subito un’altra connessione. Ecco perché no è una forma di difesa, ma
può servire a rallentare l’attacante.

Una contromisura efficace:


Tutti gli switch moderni permettono di limitare il numero di MAC utilizzabile da una determinata borchia. I
pacchetti di una rete che vengono da quella borchia (o cavo di rete), oppure da quella borchia possono
venire solo pacchetti da un determinato MAC (troppo statico e non viene quasi mai fatto, perché una sola
macchina si potrebbe collegare, non accettabile ad esempio per i portatili). Ricordiamoci sempre che il MAC
è falsificabile!
Una contromisura è il fatto di limitare il numero di MAC che possono essere emessi da una determinata
borchia. Se questo limite è minore della quantità di configurazioni server che ha nel pool , l’attacante non
riesce a fare address starvation a meno che non controlli più borchie. Facendo finta che si ha un limite di 10
su quella borchia, più di 10 cinfigirazion non potrà avere. Naturalmente se avrà 10 borchie può arrivare a
100.

Sintetizzando:
- Una parziale contromisura già presente nel protocollo è il concetto di leasing: una
configurazione viene “noleggiata" solo per un certo tempo, poi ritorna disponibile nel
pool.
- Molti switch permettono di limitare il numero di MAC utilizzabili da una determinata
borchia: se questo limite è minore della disponibilità del pool, l'attaccante deve
controllare più borchie per essere efficace.

Rogue Server
Quando uno entra nella rete non sa chi è il DHCP server, questo da modo di fare finte di essere
il DHCP server. Io attacante entro nella rete e mi comporto da DHCP server. Questi si chiamano
Rogue server(server falsi).

Sintetizzando:
I client che entrano nella rete non conoscono l'indirizzo del DHCP server (infatti fanno
broadcast)
- Un attaccante può allestire un rogue server
- Deve raggiungere il client prima del server legittimo

Un rogue server può sostituire il gateway:

Se il client riceve una risposta dal rogue server prima del DHCP, prenderà la configurazione del
rogue server, potrebbe essere comunicato un gateway diverso da quello vero, tutto il traffico
finisce in questa macchina indicata dal server finto. Questo è un modo che permette di
intercettare il traffico senza essere rilevati. Le schede di rete possono essere in modalità
promiscua (che prendono pacchetti non indirizzati a loro), ma l’amministratore della rete è in
grado di rilevarlo. Invece che tutti pacchetti vengano indirizzati a una macchian gateway non
può essere rilevato dall’ammisnitratore della rete.

Sintetizzando:
Un rogue server può comunicare una configurazione scorretta.
Può Sostituirsi al gateway, In questo modo intercetta tutto il traffico (senza agire in modalità
promiscua)

Un rogue server sostituire il DNS:

Questo è ancora più grave, perché tutte le volte che c’è un indirizzo manipolato in maniera
simbolica( quindi tutti gli indirizzi generati da utenti umani, i programmi usano direttamente
l’ip) possono essere manipolati e indirizzate secondo le mie esigenze. Se altero la maniera con
il quale viene scelto il server DNS è molto più grave.

Sintetizzando:
Un rogue server può comunicare un configurazione scorretta.
Sostituirsi al DNS, In questo modo può manipolare tutte le destinazioni espresse con nome
simbolico.

Difese Contro rogue server:

Può monitorare i nodi cche fa DHCP server o che venga fatto solo da una determinata porta.
Sotto il controllo degli switch può in qualche modo filtrare e le risposte di dhcp possono essere
determinate da una borchia determinata. Esistono anche estensioni al protocollo con forme di
autenticazione, ma vuole dire mettere su un infrastruttura complicata.

Sintetizzando:
- L'amministratore di rete può monitorare i nodi che fanno da DHCP server o anche
forzare che ciò avvenga solo da un borchia determinata
- Esistono estensioni di DHCP con varie forme di autenticazione.

Riassumendo
Il protocollo DHCP
- Lavora a livello LAN, con mezzo trasmissivo condiviso e identificazione affidata ai MAC
- Generalmente non sono previste forme di autenticazione sicura , infatti da come
problemi: Address starvation e Rogue server
DNS
È un servizio critico, la risoluzione dei nomi simboligici.

La protezione del DNS

Il DNS è un servizio fondamentale per il buon funzionamento delle reti.


La risoluzione dei nomi simbolici, ad esempio l’associazione tra www.google.it e il suo IP è un
elemento critico, e fondamentale per la costruzione della catena di trust. Se ad esempio voglio
accedere al sito web dell’università, non conosco l’IP dell’università, ma ricordo che il sito ha il
nome www.unimi.it. Questo indirizzo è scritto nel browser, viene risolto dal DNS in un numero
IP e i dati provenienti dal borwser vengono da quel IP. un umano che costruisce la sua fiducia
su quello che interagisce tramite questi elementi. Il nome simbolico è un presidio importante
per la fiducia, è l’attribuzione a un’identità alla sorgente dei dati.

Il servizio DNS è un servizio interessante, perché è un servizio di tipo pubblico, nessuno sa


risolvere i nomi di tutti, non esiste un elenco di qualche mega server che conosce le
associazioni tra nomi simbolici e tutti i numeri IP, questa soluzione viene in modo
decentralizzata, cioè ogni uno conosce le risoluzioni della sua zona o fetta.

La risoluzione dei nomi deve avere una faccia pubblica, perché non serve solo a me, ma serve
anche agli altri. È sempre un servizio che quasi mai è puramente interno, ma un po' interno ed
esterno e questo rende più difficile la sua protezione.

Il DNS è critico per vari motivi, tra i quali contiene informazioni ad attacchi che non per fozra
riguardano il DNS:
se ad esempio risolviamo il nome simbolico di google, otterremo una serie di IP diversi,
raccogliendo questi IP scopriremo che questi domini sono all’interno di Google e così possiamo
sfruttarli per costruire la topologia di Google. Quindi può essere il modo per conoscere
informazioni di una rete.

Và anche detto che esistono tante implementazioni del DNS, la più usata è la “Bind”, e non è
molto curata dal punto di vista della sicurezza.

Sintetizzando:

- è un elemento molto importante nella catena di trust delle transazioni iniziate da un


utente umano, che raramente usa direttamente i numeri IP.
- è un servizio generalmente pubblico e ottenuto in maniera decentralizzata, quindi
nessuno ne ha il completo controllo
- Può essere utilizzato anche come strumento di “intelligence" prima di ulteriori attacchi
- Esistono moltissime implementazioni, non tutte curate dal punto di vista della sicurezza
- Per questi motivi è un bersaglio particolarmente attraente
-
Separazione di servizi DNS

I DNS server hanno sempre una parte pubblica, è importante che i DNS partecipino alla
conoscenza pubblica con altri DNS. Pe rquesto motivo uno dei principlai dei meccanismi di
protezione del DNS è separare, quindi allestire 2 server DNS, perché in questa maniera si
attribuiscono i ruoli a due nodi differenti.
In modo particolare avremo un DNS esterno, che è la parte pubblica del nostro DNS ed è li per
ricevere query da utenti esterni. Risponderà alle query solo per host pubblicamente accessibili
(per esempio host del mail relay, ovvero quello che è in grado di distribuire la posta nella
nostra rete). L’idea di base è quella di dividere i DNS in 2 nodi che fanno 2 servizi diversi, un
DNS esterno che partecipa al DNS globale e un DNS interno.

Il DNS interno riceve query solo dagli utenti interni, e risolve i nomi simbolici interni della
intranet aziendale, in questa maniera se questa parte fosse insieme a quell’altra, un attacante
verrebbe a conoscenze di informazioni della rete e topologia, in questo modo tenendo i DNS
separati questo non può succedere. Gli host interni, o meglio le query degli host interni
passano per il DNS interno, quando il DNS interno non sa la risposta contatta DNS esterni (o
quello esterno o di un’altra rete). Questo meccanisco si chiama query ricorsive

Sintetizzano,spesso si allestiscono due server DNS:


- DNS Esterno: Riceve query da utenti esterni per informazioni riguardo host
pubblicamente accessibili della rete aziendale, incluso l'MX server (il Mail Relay)
- DNS Interno: Riceve query da utenti interni per informazioni su host sia
della intranet aziendale che di Internet. Per le query che il DNS Interno non è in
grado di risolvere contatta altri DNS (query ricorsive).

I vantaggi di questa separazione sono:

- I due DNS mantengono informazioni differenti (solo quelle pubbliche l'esterno, tutte
quelle della intranet l'interno) e hanno connessioni con zone a diverso grado di
sicurezza, questo vuol dire che sarà possibile configurare firewall e infrastruttura di rete
garantendo la sicurezza di rete ai vari livelli.
- Separazione fisica delle informazioni riguardante servizi pubblici da quelle riguardanti
servizi della intranet
- Assegnazione a diverse zone di sicurezza per la protezione delle informazioni
- Isolamento del DNS pubblico dalla rete interna nel caso di compromissione
Questa è una possibile architettura che permette di separare le varie zone, in basso a sinistra è
presente la rete interna e il servizio di DNS interno. I nostri client interni(workstations),
quando chiedono i servizi interni, li mandano a questo dns interno. Il firewall è una bariera tra
il border router,il servizio del DNS interno e i client. I collegamenti verdi sono link logici, perché
i fisici sono tra il firewall e i client, il firewall e la rete dei DNS.
Se un client vuole risolvere l’indirizzo di un servizio esterno, farà la query ricorsiva, ariverà
all’interno del dns server, che sarà lui a fare al query al dns esterno. La zona dei servizi
pubblici e la zona dei servizi esterni sono completamente separati, per evitare attacchi alla
parte pubblica.

ATTACCHI AL DNS
Alcuni attacchi possibili sfruttando le caratterisitiche del protocollo, prima vediamo in dettaglio
il funzionamento del protocollo:

Risoluzione di una query


Vogliamo risolvere il nome simbolico www.example.com, ci deve essere un server DNS
configurato nel nodo, la query viene richiesta al server DNS. Il server DNS cerca di capire se è
nota oppure se la deve richiedere all’esterno, quindi se non è capace di risolvere l’indirizzo
localmente, consulta l’elenco dei root serve (i domini di più alto livello, .it,.com.etc) con questo
elenco farà partire la query ricorsiva. In questo caso il root server è quello di .com, il root dns
sarà il livello di livello .com ma non sa l’associazione di tutti i .com immaginabile, quello che fà
è di rispondere con un record di tipo name server che dici chi sono i global top level domain
(gltd) server di .com e che hanno maggior informazioni per quel dominio, e così via lo si và a
fare per tutti i livelli necessari fino a quando non si ha una risposta autorevole(authoritive), di
qualcuno che sa per certo il numero ip di example.com.

Sintetizzando:
1. Si vuole risolvere www.example.com
2. Richiesta al server DNS configurato
3. Il DNS esamina se è risolvibile localmente o se la query è ricorsiva: in questo caso consulta
l'elenco dei root server che conosce
4. Il root DNS non conosce l'indirizzo, ma risponde con un record di tipo NS corrispondente ai
Global Top Level Domain (gTLD) server di .com
5. si ripete fin quando si ottiene il ns autorevole (authoritative) per example.com

Fragilità del sistema


Questo sistema è efficiente e resistente ai guasti. Nonostante ci siano cache nel dns permettono
comunque flessibililtà.
Però la versione originaria non prevede nessuna autenticazione e integrità, tutti quei pacchetti
possono essere intercettati e falsificati e non abbiamo garanzie che provengano dal server che
sia il name server originale di quel dominio. Questo fa capire che può creare problemi.

Supponiamo che il name server di unixwiz.net conservi delle associazioni sulla


bancaditalia.com . Nessuno gli vieta di tenere quelle associazioni. Questo non è un problema,
perché nessuno chiederà a di unixwiz.net di risolvere bancaditalia.com, perché la risoluzione
che è guidata da i gloo record non arriverà mai a chiedere le cose di bancaditalia.
Però un’attacante potrebbe riuscire a fare chiedere bancaditalia.com se riesce ad avvelanre la
cache del DNS.

Cache poisoning
Avvelneare, vuol dire introdurre associazioni false nella cache. Per introdurre informazioni false,
bisogna capire come il dns autentica l’associazione. Non c’è un meccanismo di autenticazione, ma
è implicito come avviene il dialogo.
1. La risposta deve arrivare con la stessa porta UDP sorgente della richiesta. altrimenti viene
scartata
2. La sezione Question coincide con quella della richiesta
3. Il query ID corrisponde a quello della richiesta
4. La risposta contiene dati riguardanti nodi nella zona (non bancaditalia.com per esempio)

Se l'attaccante riesce a prevedere questi dati, può alterare la cache

Indovinare il query ID
Spesso le implementazioni DNS non sono attente alle problematiche di sicurezza, spesso il
query id è un contatore. Faccio delle richieste normali, guardo il numero, provo un po' di query
id e riesco a indovinarle.
Porta UPD sempre la stessa
Se la stessa porta sorgente udp è sempre la stessa non è difficile da indovinare. Quando ho
una risoluzione,dovrebbe
Se il nome è già nella cache, l’attacco non funziona: Ovviamente non funziona se il
nome è già nella cache. Le chance dell'attaccante sono minori se il dns authoritative è più vicino
al dns vittima.

DIFESA:
La difesa principale è la randomizzazione del query ID
- Con ID sequenziali l'attaccante prova una ventina di ID
- Con ID random (su 16 bit) occorre provare 64K (prima che il dns authoritative
risponda)

L'attacco di Dan Kaminsky


L'idea di base è la stessa, ma amplia l'impatto falsificando il dns authoritative stesso.
L'attaccante ne allestisce uno proprio, che però normalmente non riceverebbe richieste.

Chance dell'attacco
Con la randomizzazione dei query ID sembra difficile fare le 64K prove necessarie in tempo
utile (prima che arrivi la vera risposta).
Ma nella versione Kaminsky l'attaccante genera tanti nomi casuali (p.es.
www12345678.bankofsteve.com).
Anche se riesce a fare solo poche (50?) risposte finte prima di essere superato dal vero
authoritative, può comunque ripetere questo tentativo tante volte con nomi diversi: ogni
tentativo ha probabilità di riuscita 50/65536
Con 100 tentativi: 7;3%, con 1000: 53;4%, con 10000: 99;9%
Un possibile miglioramento si ha randomizzando anche la porta UDP. Se la porta è random su
65535 ci vogliono almeno 60 X 10 alla 6° tentativi. (MS DNS server sceglie fra 2500 porte, quindi
in realtà “bastano" 2,3 X 10 alla 6°)

DNSSEC
È la variazione di dns con caratteristiche di sicurezza. È importante perché è supportata da
molto agenzie governative.
Il DNSSEC è uno standard retro-compatibile, quindi è possibile mischiare dnssec con dns
normale, l’idea di base è di aggiungere le cose che mancano a dns , come l’autenticazione e il
controllo di integrità.
DNSSEC è un elemento che è considerato fondamentale nella trust di internet, l’intern sicura
del futuro. La sua adozione è molto limitata, nel 2009 degli 80 milioni di millioni erano solo
274. Pochi lo adottano, la difficoltà sta nel deployment, perché bisogna mettere in piedi una
struttura di autenticazione che non è semplice. Convincere 80 milioni di amministratori di
dominio e in più facendogli pagare un prezzo di fatica e un prezzo di rallentamento traffico non
è semplice.
Un altro motivo è che molti ritengono che l’efficacia di DNSSEC non ci sia o non sia
paragonabile al costo da sostenere.

Principi Fondamentali
Il concetto fondamentale è che le risposte dei dns autorevoli sono firmate digitalmente, posso
controllare da chi è autorevole rispetto a quel dominio.
Ad esempio La risposta sull’associazione bancaditalia.it mi deve arrivare dal name server di
bancaditalia e per aver questa garanzia sulla sorgente la risposta è firmata digitalmente. Il
problema è che devo avere una chiave pubblica per verificare questa firma digitale. La chiave
pubblica di una zona viene distributa dalla zona superiore, ad esempio bancaditialia.it sarà
distribita da .it .
Viene introdotto nel protocollo la possibilità di avere “risposte di non esistenza”: si può avere
una risposta che dice no guarda io sono .it e dice guarda che bancaditalia.it è falso o non
esiste più, quindi non usarlo.

Complicazioni
Il problema grosso è che le firme devono continuamente scadere per evitare replay
attack( posso sfruttare delle firme e rimandare del replay di informazioni non attuali).
Di solito le firme scadono ogni 30 giorni.

Limiti di DNSSEC
Secondo D. J. Bernstein, autore di djbdns e di una proposta alternativa
(DNSCurve), mal progettato:
- L'assunzione di base _e che non _e pensabile usare la crittografia in ogni pacchetto, per
ragioni di efficienza.
- Non c'_e crittografia dei dati (solo integrità)
- Le firme sono precalcolate (e quindi occorre ruotare le chiavi per limitare i replay)
- Tutti i tool per la modifica dei dati DNS devono essere `signature aware'
- Non c'è protezione contro DoS

Ulteriori pericoli
Bernstein identifica anche vulnerabilità di DNSSEC
1. Ogni pacchetto di risposta DNS è firmato: se i dati sono alterati andrebbe scartato
- So che i dati potrebbero essere falsi, ma non ho comunque i dati veri (denial of service)
- Di fatto, al momento la maggior parte dei server non lo fa
2. Vengono firmate solo le associazioni di cui un ns è authoritative: i glue record rimangono
falsificabili
3. Il protocollo permette l'amplificazione di DDos (una query di 78 byte si può trasformare in
una risposta da 3113 byte)

BGP (BORDER GATEWAY PROTOCOL)


È il protocollo che viene usato a livello internet per fare routing fra le reti. BGP per questo motivo è un punto critico.

Struttura di internet Globale

Internet è una rete di reti globali. Però il router a livello globlae non è gestita in maniera decentralizzata nelle reti locali,
perché nella rete attuale fatta di dorsali che si attaccano gli isp, l’elemento che acquista peso sono gli Autonumos
System(AS): sono aggrgegazioni di reti locali che hanno un solo amministratore, che vengono gestiti secondo una
qualche politica.

A livello di una rete locale il routing è praticament inesistente, ma fra reti locali i protocolli classici sono protocolli di
instradamento più semplici che sono basati di trovare la strada migliore calcolando le distanze.

Fra AS la cifra importante a livello di instradamento non è la distanza, ma i fattori di gestione del traffico. Entrano in
gioco fattori di scelte commerciali, potrei decidere che la mia infrasturttura non venga usata per routing di traffico di
un concorrente. Un altro fattore sono motivi politici, esempio voglio evitare che il traffico statunintesne passi da
qualche nemic degli stati uniti. Entrano in gioco una serie di fattori che non sono facilmente condensabili in concetti di
distanza, servono protocolli per gestire queste politiche complesse.

BGP

Uno di questi protocolli usati fra gli AS è “BGP(border gateway protocol, gateway ricorda il passaggio fra gli AS)”.
Il BGP è un protocollo che viene definito “path vector”.

Path vector: l’instradamento è fatto conoscendo una serie di percorsi che il traffico potrebbe fare, l’algoritmo di
instradamento sceglie il percorso più adatto alle esigenze, che non sono espresse in distanza ma in base a politiche di
routing che tengono conto di tanti fattori(principalmente di costo).

Concetti BGP

Ogni AS gestisce tutti i nodi con un determinato prefisso. Tutti i nodi che hanno un IP di un certo tipo, sono gestiti da
un certo AS. A questo punto si parla di AS path, che è la lista di AS da attraversare per raggiungere un nodo che ha un
determinato prefisso. I router di Ogni AS partecipano al protocollo con i BGP update, che sono messaggi di update in
cui dicono per esempio AS A annuncia ai propri vicini che sa indirizzare un certo prefisso X e lo farà comunicando il
path a A X. Supponiamo che B riceva questo messaggio, trasmetterà questo messaggio ai propri vicini, che dirà io so
raggiungere A che è in grado di raggiunger i nodi con prefisso X(questo è un path). Chi riceve un path che contiene se
stesso non lo riannuncia. I path contengono anche gli attributi utilizzabili nelle policy.

Le comunicazioni tramite AS avviene tramite TCP, la porta è la 179 (a livello di rete fa uso del livello 4 che è quello di
trasporto per scambiare dati). Si scambiano tra di loro i messaggi su questo canale. I pericoli sono:

- L’attaccante controlli il link, sia in grado di alterare il canale (subverted link), in quel caso i 2 router sono
perfettamente legittimi, ma dato che l’attacante varia i dati sul canale questo può variare sui problemi
- Router maligni (subverted router), possono esserci router che trasmettono informazioni false.

Attacchi esterni

Dai subverted link ci si può difendere con un'infrastruttura a chiavi asimmetriche (non presente
nel protocollo di base). Come al solito, la gestione delle PKI è complessa, ma molto
efficace. (Non difende dall'interruzione del collegamento, naturalmente)

Attacchi interni

È più subdolo il caso in cui in realtà c’è un router maligno che emette delle informazioni
falsificate. È più difficile difendersi. Un router è compromesso e si sostituisce al router. I casi
più frequenti sono o alla compromissione,allo spoofing o malfigurazioni.

Vulnerabilità BGP

BGP non prevede nessuan autenticazione della sorgente e né integrita dei messaggi. Se non
mette una infrasturttura, i messaggi sono falsificabili. Non c’è nenanche un controllo sugli
ownership dei prefissi, uno può dire io controllo questo prefisso anche se non è vero.
Anche le informazioni di path non sono controllate(non è facilissimo controllarli).

Controlli di coerenza

Un AS riceve messaggi dagli AS, Io posso mettere informazioni da più parte e rilvevare delle
incoerenze. Sono previste, perché il protocollo tende ad adattarsi alla situazine della rete in
evoluzione(guasto, cambio politiche, etc). Non è necessariamente vero che siano incoerneti le
informazioni date da attacchi ,ma anche perché sono state rilevate in momenti diversi.
Se l’attacante conosce la topologia della rete, può produrre informazioni false ma coerenti a
quelle che potrebbero arrivare al AS.

Obiettivi degli attacchi


La falsificazione delle informazioni di routing può servire per
- Redirezione del traffico
- Instabilità del routing
- Black hole
Prefix Hijacking

- attaccante D
- Fa finta di controllare il prefisso di A
- Se AS 50 preferisce i path corti, D ha successo nella redirezione D potrebbe anche
attribuirsi i prefissi di AS 20

Prefix aggregation
Quando più prefissi condividono un certo numero di bit è conveniente
Aggregarli
- 10.42.2.0/24 e 10.42.3.0/24 condividono i primi 23 bit
- aggregati in 10.42.2.0/23 (o 10.42.3.0/23) permettono di accorciare i path
- allo scopo si usa un AS set

Prefix De-aggregation

- attaccante D
- AS 50 riceve da
AS 40 una rotta più specifica
- Il traffico passa per D ,D potrebbe anche attribuirsi il prefisso 1.2.3.0/24

Route flapping
A livello Internet è perfettamente normale avere una topologia
estremamente dinamica: BGP permette di scartare e annunciare nuove rotte con facilità.
- link flapping un link viene disattivato e poi riattivato (normale)
- Se succede spesso però, crea instabilità nella rete perchè gli instradamenti sono in
continua variazione
- route damping la riattivazione di una rotta viene accettata con tempi crescentemente
più lunghi
Flapping attack

- attaccante D
- AS 50 si convince che il link è flapping
- AS 10 diventa irraggiungibile da AS 50 a causa del damping

Contromisure

La contromisura più semplice è l'attivazione di filtri ingress e egress che scartano i path relativi
a prefissi “imprevisti"
Versioni sicure di BGP
Ci sono diverse evoluzioni sicure di BGP:
- S-BGP: PKI e IPsec
- Secure Origin BGP (Cisco):PKI, nuovi messaggi BGP
- IRV: indipendente dal protocollo (non solo BGP), basta un livello di trasporto sicuro

RETI WIRELESS
Le reti wireless, usano onde radio per stabilire le connessioni, nascono negli anni 70. Il primo
esempio è nell'arcipelago delle hawai, c'è una ragione evidente perchè sono nate li. Le ret wireless
hanno il vantaggio di essere usate dove estendere dei cavi è costoso.
Risulta comodo oggi avere un wireless per spostare dispositivi mobili, negli ultimi anni hanno avuto
una grossa diffusione. Questa estrema flessibilità ha un costo in sicurezza( come ogni ambito della
sicurezza).
Dal punto di vista della sicurezza:
All'interno di una rete wireless sono tutti "intrensicmanete boradcast", sono ragingibile a tutti i nodi
della rete che hanno un ricevitore radio. È come se fosse una LAN, ma è polto più pervasivo di
quanto sia un cavo, è molto più difficile sapere chi è collegato. Un'altra differenza è che oltre che il
mezzo trasmissivio è condiviso, non è la stessa condivisone con il cavo: con le onde radio ci
possono essere range di ricezione diversa, per esempio posso raggiungere un certo nodo in cui Alice
raggiunge Bob, bob raggiunge charlie ma non necessariamente aliche raggiunge Charlie, quindi non
vale più al proprietà transitiva della ricezione. Il mezzo transitivo è sucitebbile alle attenuazioni e
inteferferenze, quindi possono renderle inutilizzabli tramite interferenze.

Collision detection

In ethernet sappiamo che un elemento caratterisitico è la "collision detection". Non è possibile in


questo caso usare la collision detection, perchè può esserci il caso che esiste una zona A e una zona
B, ed esiste una zona di collisione dei segnali C, i segnali collidono ma ciò nonostante A non può
raggiungere B e B non può raggiungere A.

Nelle reti wireless che non vale questa proprietà, Usiamo una zona A e D e una zona BC che sta tra
A e D. La collisione và evitata, e per fare questo si usa un carier fisico e se non è possibile si
aggiunge un carier virtuale. Questo protocollo si chiama "CSMA/CA", il protocollo stabilisce tempi
di attesa standard in cui uno non deve trasmettere, questi tempi sono studiati per minimizzare la
probabilità di connessione. Il protocollo stabilisce 4 tempi standard: SIFS,PIFS,DIFS,EIFS.
SIFS è maggiore di PIFS che a sua volta è maggiore di DIFS che a sua volta è maggiore di EIFS.
Quindi: SIFS<PIFS<DIFS<EIFS. Ci sono 4 evoluzoni temporali dei nodi nel caso che A voglia
trasmettere un frame o messaggio a B. A inizia a trasmettere, per fare questo manda un messaggio
di request of sender(RTS), ovvero la volontà di trasmettere. Notiamo che l'RTS viene sentito da B
che è nel range di A e da C, ma non da D. B è il destinatario del messaggio dice che è pronto a
ricevere con un "cleare to send" (CTS), però lo fà dopo un tempo EIFS. A a questo punto manda il
frame ma lo manda dopo un tempo SIFS dopo aver ricevuto il CTS. Allo stesso modo B manda
l'ack aspettando quello più corto di tutti. Per renderdesi conto che il messaggio sia stato ricevuto fà
partire un timer che si accorge se gli arriva l'ack.

802.11(wiriless)

I protocolli più diffusi sono quelli che vanno nello standard del 802.11, noto con il nome
commerciale di wi-fi.
C'è ne sono diversi che usano caratteristiche diverse. In generale iniziano per 802.11 e finiscono con
una lettera diversa per diversficarsi. I più famosi:
- 802.11a : lavora su frequenze 5GHz, ha una banda ampia su 54MB/sec teorico, in realtà per vari
problemi tecnici si arriva in realtà a 20mb/s.

-802.11b: è quello più diffuso! lavora su frequenze 2,4GHz, ha una banda ampia su 11MB/sec
teorico, con tcp 6 mb/s e udp 5mb/s.

-802.11g: lavora su frequenze 2,4GHz, ha una banda ampia su 11MB/sec teorico, pratico 25mb/s.
Sta sempre prendendo più piede.

-802.11i: non è un protocollo di trasmissione, ma è lo standard di sicurezza WPA2.

-802.11n: si sta diffondendo adesso, è interessante perchè permette bande elevate e uso congiunto di
antenne.

Modalità di funzionamento
Le schede di rete che partecipano a queste trasmissioni possono avere 3 modalità diverse di
funzionamento:
- Modalità access point(o modalità infrasturrura): la rete funziona con una topologia a stella, ogni
nodo spedisce i pacchetti tramite un access point (AP), in cui tutti i nodi (che vengono chimate
stazioni) parlano con l'access point

- Modalità Ad-hoc: abbiamo una rete punto a punto. Ciascuno scampia i frame con un'altro. Non c'è
più bisogno di uan infrastruttura, si usa al posto di un cavo.

- Modalità Monitor: la scheda si mette in modalità ricezione, incamera tutti i segnali che sente.
Viene anche chiamate modalità promiscua, in cui ricevo tutti i frame e intercetto il traffico.

Carattersitiche
- Ogni nodo è contrassegnato da un numero MAC.
- l'access point è contrassegnato da un service set identier (SSID), per identificare l'access point.
Ci si può riferare SSID o con il MAC del access pint , il BSID. L'access point annuncia che il suo
BSID è tale dei tale, questo annunco si chiama beaconing.
I nodi per capire quali access point ci sono in giro e collegarsi con l'access point fanno scanning,
cercano di capire se c'è un assesion point. Lo scanning può essere passivo o attivo.

Servizi 802.11

Associazione: servizio che permette di collegarsi con un AC.

Autenticazione: Per poter partecipare alla trasmissione, bisogna autenticarsi, il protocollo adottato
specificherà come autenticarsi.

Vulnerabilità intinseche

- Il segnale è facile da intercettare, basta avere un ricevittore e intercetto il segnale. Non c’è modo di
vedere se qualcuno è in ascolto (a differenza del filo).
- Il segnale è facile da disturbare
- In alcuni casi il nodo può avere ridotte capacità di calcolo
Attacchi frequenti

- L’attacco più comune è l’ascolto indesiderato (Eavesdropping)


- Un altro attacco comune e facile fa fare, perché facile interferire e disturbare è il denal
of service, molto comune e difficile da evitare
- Attacchi più raffinati sono lo spoofin e il message replay

Troppo spesso l’identificazione di una stazione di un nod è affidata al Numero MAC. Il numero
MAC è una proprietà della scheda di rete, ma siccome i pacchetti li produce lo stack software
nulla vieta che lo stack software cambi il MAC nel pacchetto, quindi il MAC è facile da
falsificare. Nell’ambito wirelless, il traffico lecito è accessibilie, non è difficile mettere un MAC
legittimo. L’identificazione affidata al MAC è debole in ambito wireless.

WEP

Wep (wireled equivalent privacy), è stato il primo tentativo di introdurre una sicurezza nel
wireless. È un protoccolo che ha una serie di problemi ma è abbastanza diffuso,( una scheda
un po' vecchia non fa cose diverse da wep).
Si basa su una chiave condivisa(di 40, 104 bit,232 etc), fra l’access point e le stazioni,a tempo
di installazione bisogna impostare questa chiave nei nodi e nell’access point, di chiavi il nodo
può averne più di una. Chi conosce questa chiave è all’interno della rete e non ha nessun tipo
di protezione. Una volta che la chiave è nota non c’è più nessuna misura di protezione.

Sintetizzando:

- Shared key di 40, 104 o 232 bit (WEPkey)


- Le chiavi sono identificate da un keyID di un byte, perchè un nodo ne può avere più di
una
- Le chiavi devono essere trasmesse tramite un canale sicuro (offline a tempo di setup)
- Non c'è protezione fra coloro checonoscono la chiave (come in una LAN Ethernet)

Autenticazione Wep

L’autenticazione si basa su una chiave condivisa k. Si basa su questi 4 step il protocollo:


un nodo N vuole autenticarsi con l’access point AP. È già associato, i due si parlano,
L’access point manda una challenge, (un numero casuale fatto di 16 byte o128 bit) detto W .
Il nodo genera anche lui un numero casuale, Inizialization vector(è un numero di 24 bit) detto
IV. Dopodichè calcola questo numero: K è la chiave condivisa prende il vettore di
inizazilizazione IV, lo concatena con la chiave K (quindi ha una serie di 24 bit di vettore più la
chiave 40, 24+40 =64bit), questi 64 bit vengono usati come seme di RC4(è un algortimo
crittografico, serve per produrre uno stream streafer che è un flusso di numeri pseudo-casuali)
e il risultato viene messo in XOR con la challange W….. CONTINUA

WPA
WI-FI Protected Access (WPA) nato nel 2002 per superare WEP
- Utilizzabile sullo stesso hardware
- Superando le vulnerabilità di WEP
- Sostituisce CRC con un nuovo algoritmo per l'integrity check (Michael)
- Usa ancora RC4, ma impedisce replay e correlazioni con Temporal Key Integrity Protocol
(TKIP).
Autenticazione WPA
Due modalità:
- Home-and-Small-Office: Pre-shared Key (PSK) analogo a WEP
- Enterprise: usa 802.1X e un authentication server connesso all'access point con una
rete wired
Enterprise WPA
- Ogni nodo (supplicant) condivide una chiave segreta con l'authentication server
(Remote Authentication Dial-In User Service, RADIUS)
- L'access point riceve le richieste del nodo e le gira al RADIUS dal quale riceve l'ok
all'autenticazione
Misure di sicurezza introdotte da WPA/TKIP
- TKIP usa una pairwise master key (PMK) generata differentemente per ogni nodo
- la PMK viene usata per generare 4 pairwise transient keys (PTK) da 128 bit.
- le PTK sono diverse in ogni sessione di associazione con un AP
PTK
Le PTK vengono generate con un 4-handshake a partire da:
- un numero casuale con seme PMK
- MAC del nodo
- MAC dell'AP
- nonce generati dal nodo e dall'AP
Integrity check
- 2 PTK vengono usate da Michael per l'integrity check
- Michael è soggetto ad un attacco per cui bastano 229 (invece di 264) tentativi per
falsificarlo
- perci_o 2 failure escludono un
nodo per un minuto
......
Replay di IV
Per evitare che gli IV vengano riutilizzati, TKIP introduce i TKIP sequence counter (TSC).
- 48 bit divisi in 3 blocchi da 16 (con 24 bit, dopo 5120 trasmissioni è più probabile avere
collisioni che no)
- questo permette di riutilizzare RC4, spesso cablato nello hardware
......
DoS WPA
I pacchetti che non superano l'integrity check vengono scartati;
2 scarti portano alla dissociazione per 1 minuto.
- L'attaccante intercetta pacchetti con IV (in chiaro)
- Modifica l'IV con valori maggiori del contatore
- L'integrity check fallisce, causando DoS
Sintetizzando
WPA è un protocollo nato per superare i limiti di WEP, funzionando sui medesimi device.
RC4 based, Algoritmo crittografico per, l'integrity check, IV non riutilizzabili
802.11i (WPA2)
WPA nasce per mettere una pezza a WEP. In realtà l'IEEE
stava elaborando uno standard di sicurezza che è stato completato
solo nel 2004
- 802.11i
- Wi-Fi Alliance ha prodotto uno standard compatibile con 802.11i chiamato WPA2
Al contrario di WPA, non permette di riutilizzare lo hardware WEP.
- Crittografia basata su AES
- Autenticazione PSK o 802.1X (come WPA)
- Counter mode-CRC MAC Protocol (CCMP) usa AES-128 in counter mode per
autenticazione, confidenzialità e integrità: senza IV in chiaro

Counter mode AES


Il counter mode AES permette di trasformare un block cipher in uno stream cipher usando
valori successi di un counter: il
messaggio M viene spezzato in blocchi di 128 bit Ci = AESK(i) _ Mi
CCMP inoltre (per questo servono 2 PTK) usa il cipher-block chaining message
authentication code (CBC-MAC) in cui ogni blocco dipende dalla corretta cifratura del
precedente.
Sicurezza di 802.11i
CCMP _e ritenuto piuttosto sicuro, ma rimangono alcune vulnerabilità generali
- DoS
- Attacchi rollback
- Dissociazioni e de-autenticazioni
Dissociazioni e de-autenticazioni
Un attaccante può forzare una dissociazione allo scopo di:
- tentare un attacco di rollback
- intercettare i pacchetti utilizzati durante l'autenticazione (per esempio per tentare un
dictionary attack)
Sicurezza nelle reti
Dopo aver parlato della sicurezza delle reti, ci occuperemo della sicurezza all’interno della rete internet.

Censura e controlli

Le reti come internet, risultano uno strumento di libertà, grande possibilità di comunicare con persone
entità lontane. Però và detto che anche se dal punto di vista esterno la rete sembra un fattore anarchico e
incontrollabile, in realtà sotto c’è un infrastuttura che permette di controllare in maniera sistematica la rete.
L’elemento anarchico della rete interne è che è “una rete di reti”, in internet gli amministratori di rete sono
tanti, ma ciascunoa amministratore di reti ha enormi poteri nella sua sottorete. A livello globale i poteri di
un amministratore in un sistema multicentrico all’interno di un dominio ha enorme possibilità di controllo.
Da una parte hanno possibilità i carier (i mezzi tramsissivi), perché possono vedere il
traffico,manipolarlo,esaminarlo,statistiche etc. Poi ci sono i governi che hanno la possibilità di obbligare i
carier a fare determinate cose. Quindi la rete è soggetta a un pericolo di censura, content filtering, pericolo
di fare trucking delle abitudine (rilevare le nostre abitudine dalla rete). Fino adesso abbiamo avuto la
prospettiva dell’amministratore della rete, ora ci metteremo nei panne dell’utente della rete che in qualche
modo vuole evitare che le sue attività siano censurate, i contenuti che ha bisogno vengano filtrati o che
qualcuno possa tenere traccia di quello che fa. Il filtraggio è molto pericolo all’interno della rete, perché non
è mai precisissimo, quindi questi controlli possono recare del danno a qualcuno che ha diritto di fare attività
lecite, ma non può farlo perché esistono filtri / censure imprecise.

Diritti fondamentali

Il diritto alla privatezza e segretezza delle comunicazioni è un diritto fondamentale tutelato da tutte le
costituzioni democratiche.

Costituzione italiana, art. 15:


“La libertà e la segretezza della corrispondenza e di ogni altra forma di comunicazione sono inviolabili. La
loro limitazione pu ò avvenire soltanto per atto motivato dell'autorità giudiziaria con le garanzie stabilite
dalla legge.”

Tutela
Gli utenti delle reti hanno quindi diritto di:
- veder tutelati i loro diritti dalla legge
- usare la tecnologia in modo da difendersi all'interno di una rete (quindi in potenziale conflitto con
l'amministratore della rete stessa)
Esempio In cina sono filtrate le ricerche su google! Chi opera queste ricerche non riesce a trovare i nomi sui motori di
ricerca. Lo impedisce l’amministratore delle sottoreti della rete cinese.Difendersi ad esempio in questo caso dagli
amministratori, risulta impossibile.
Privacy-Enhancing Tecnologies (PET)
PET: tecnologia progettata allo scopo di tutelare la privacy (privatezza, riservatezza)
- Non solo reti: le porte dei bagni sono PET. . .
- In campo informatico: tecniche per minimizzare o eliminare i dati personali
- tecniche per evitare il controllo delle attività

Privacy e sicurezza
La privacy è importante anche per la sicurezza tradizionale, questo per diversi motivi:
- La riservatezza delle informazioni che riguardano permettono di evitare i furti di identità
(identity theft), qualcuno che si sostituisca alla nostra identità, qualcuno che abbia
raccolto abbastanza informazioni su di noi(chiamato anche spoofing di identità), può
essere limitato litando le informazioni personali.
- La mancanza di privacy è un elemento fondamentale nel controllo e repressione del
dissenso (la CIA ha pubblicato un articolo in cui evidenza in cui la conoscenza di
informazioni personali può essere più efficace della tortura per avere informazioni )
- le persone cambiano, ma i dati restano (diritto all'oblio)

Minimizzazione dei dati

Bisogna cercare di minimizzare i dati, solo informazioni rilevanti per un servizio. Se un’informazione già non viene
raccolta è già un buon servizio e rischio in meno.
- Ogni servizio dovrebbe richiedere e raccogliere solo l'insieme minimo di dati necessario a fornirlo
- I dati personali (o addirittura sensibili) dovrebbero essere raccolti solo quando strettamente necessari (e
conservati in maniera adeguatamente protetta)
I dati personali sono tutti i dati che ci riguardano, i dati sensibili sono quelli che riguardano argomenti delicati(politica,
religione, etc), oltre a essere personali sono anche sensibili e la legge italiana li tuttela entrambi

Sanitization

Consiste nel rendere i dati che si vogliono conservare(tipo per statisitche), li si conserva sanitizati o meglio privati di
quelle caratteristiche sensibili. Un conto è tenere Mattia monga che guadgna 1 milione di euro e un conto è dire c’è
una persona a Milano che guadagna a 1 milione di euro, così non si può risalire al proprietario di quel dato. È difficile
perché bisogna evitare i collegamenti. Esampio in campo medico negli USA Alcuni dati medici sanitizati, incrociandoli
sono riusciti a risalire a quelche personaggio famoso americano. l’anonimato richiede grandi quantità di dati. Esempio
come dire un nero di 30-40 che abita in Islanda,non abbiamo detto chi è ma in islanda a Dalvik saranno veramente
poche di persone con questa tipologie ed è facile risalire.

Protezione

Ogni volta che dati personali/sensibili sono conservati, processati o trasmessi dovrebbero essere protetti
- Controllo degli accessi
- Crittografia e shredding (cancellare i file in maniera sicura dai dispositivi di massa)
In Italia norme di legge piuttosto precise: vedi Decreto legislativo 30 giugno 2003, n. 196 Codice in materia di
protezione dei dati personali.

Anonimato
La difesa rispetto ai pericoli di controllo è l'anonimato (non a caso tutti i tentativi di controllo
politico di Internet cercano, in un modo o nell'altro, di limitare l'accesso anonimo)
Tema assai controverso, perchè l'anonimato perfetto permette azioni non perseguibili (e in
effetti in alcuni casi la legalità locale potrebbe essere in contrasto con i diritti fondamentali).

Inosservabilità
Un utente usa una risorsa o un servizio e non esiste la possibilità che terze parti non coinvolte
nella fruizione del servizio, non siano in grado di osservare l’uso(ovvero un determinato utente
che abbia utilizzato quel servizio).
Incollegabilità: un utente usa diverse risorse e servizi, noi vogliamo l’incollegabilità e che non
sia possibile collegare i diversi usi.
Un caso particolare di incollegabilità è quello fra mittente e sdestinatario. Alice e Bob
comunicano, l’attavante può osservare che Alice sta comunicando, può osservare Bob che sta
comunicando, ma non può sapere che Alice comunica con Bob e che Bob comunica con Alice.
Questo se non vogliamo fare sapere all’’amministratore della rete con chi stiamo comunicando,

Anonimato: è leggato al fatto di poter una risorsa senza render nota la propria identità.

Pseudonymity: è una parola che sta tra pseudonimo e anonimato, consiste nel fatto che una
risorsa viene usata identificando tramite uno pseudonimo, esiste una identità, ma è fittizia.
Non è possibile risalire con il collegamento con l’identità reale, ma permette di autenticarsi. Un
altro fatto importante è che gli pseudonomity posso essere legati a un ruolo.

Virtual Private Network (VPN)

L’idea di base è che c’è una rete “overlay”(virtuale), che non corrisponde alle connessioni
fisiche che ci siono fra i nodi, per di più anche l’amministrazione di questa vpn è indipendente
dall’amministrazione della rete fisica. Questa rete è inaccessibile dal resto di chi non è nella
vpn, è una rete virtuale privata in cui solo che partecipa condivide il traffico. Sono molto usate,
uno degli usi più frequenti. Ad esempio una azienda può proteggere le sue risorse interne e
fare accedere i suoi dipendenti da lontano.

Tunnell: le VPN sfruttano il concetto di tunnell. È quando si usa un protocollo incapsulando dei
pacchetti in un altro protocollo. ES. si può fare tunneling di TCP su http, si usa http per fare
tcp. Usare un protocollo che non è nato come livello inferiore, lo si usa per trasportare
pacchetti che vengono incapsulati per formare il protocollo che volgiamo formare.
Identicheremo un protocollo della rete reale e facciamo tunneling dei protocolli della vpn
all’interno di questi protocolli. Le vpn differiscono molto a seconda di quale protocollo si sceglie
per fare il tunneling . ci saranno vpn che offrono reti di livello data-link o ci saranno vpn che
forniscono reti di livello reti(le più usate).

Encryption: Un fattore importante di questa privatezza della VPN, tutte le conversazioni sono
criptate, e per questo possono essere incapulate nei protocolli della rete stessa, così se
vengono intercettate non possono essere alterate. Questa encryption la si può ottenere in vari
modi: quello più classico è tramite IPSEC. Questo necessità di una infrastruttura configurata
per costruire queste VPN. Si utilizzano anche molto protocolli standard ssl/tsl, ssh e protocolli
proprietari.

SSH: può essere usato per realizzare una VPN. Ssh è uno strumento di livello applicativo. Si
usa un’applicazione ssh per aprire un terminale su una macchina remota, si sfrutta il canale
criptato per fare tunnelling dei protocolli. Ci sono due forme:
- Port forwarding
- Vera e propria VPN

Port forwarding:
Immaginiamo di avere 3 nodi: un nodo esterno alla rete, uno interno alla rete e WWW (ad
esempio una digital livery della acm che è una risorsa che quando è acceduto da un pc
all’interno unimi, permette di scaricare gli articoli delle riviste perché unimi ha gli abbonamenti,
La digital livery concede questo accesso). Se siamo a casa in una maccchina esterna
normalmente non possiamo accedere alle risorse. Ma se abbiamo la possibilità di accedere via
ssh possiamo fare port forwarding e accedere alla macchina www come se arrivasse
dall’interno. Il comando che daremo dalla macchina esterna è “ssh -L 1234:www:80
user@interno”, si può dare anche in automatico dal browser. L’utente user fa un accesso ssh
alla macchina interno, poi però l’utente dice anche che il canale che si costituisce deve essere
sfruttato per fare il port forwarding della porta (-L sta per la porta locale su esterno) della
porta 1234, gli accessi a questa porta locale si tramuteranno ad accessi www porta 80. Sulla
nostra macchina risulta aperta la porta 1234. Se noi con il nostro browser andiamo sulla porta
localhost 1234 questa richiesta viene inoltrata passando per il canale interno. Il primo
vantaggio è che la connessione dall’interno all’esterno è criptato, il secondo la connessione da
www che non è più criptata, questa connessione permette a www come se arrivasse
dall’interno.

Una vera vpn con ssh


Per avere una vera VPN bisogna appoggiarsi sui livelli più bassi dello stack.
Con Linux esiste un device tun che serve proprio a questo scopo (Tunneling/NAT regolato da
applicazioni utenti).

Setup di TUN/TAP
Se non è già attiva, bisogna creare l'interfaccia TUN/TAP
In Linux potrebbe essere necessario:
1 mknod /dev/net/tun c 10 200
2 modprobe tun

OpenVPN
Un programma open-source che permette di costruire VPN basate
su tunnel TCP o UDP. (La porta assegnata da IANA a OpenVPN è 1194)
Anche in questo caso l'implementazione sfrutta il driver TUN/TAP.

Autenticazione
Può avvenire in 2 modi:
- Pre-shared key: si configurano i nodi della vpn in modo che tutti abbiano la stessa
chiave
- Non c’è questa distribuzione di chiave sui nodi, ma invece si stabiliscono delle sessioni
TSL/SSL con le quali si scambiano delle chiavi
Tunnel
Il tunnel può essere TCP(sconsigliato per ragioni diefficienza) o UDP (default)
Si può anche scegliere se usare l'interfaccia TUN (livello network) o TAP (livello link).
ANONIMATO SUL WEB
Privacy e web
Caricare una pagina web da un server HTTP espone moltissimi dati personali (alcuni addirittura
sensibili)
- IP del client (pseudonym)
- IP del server (il client è interessato a quel server)
- identità (vedi panopticlick.eff.org)
- Dati del browser (history, cookie,. . . )
- System profile(quali macchine e applicativi installati, come i browser)
- Dati trasmessi con form,. . .

Nemici da cui dobbiamo difenderci :


1. Un eavesdropper(qualcuno che sniffa il traffico) può osservare il traffico: anche quando è
criptato (https) gli IP e il system profile è accessibile.
2. Il server web conserva i dati riguardanti il client
3. Il gestore della rete osserva e/o censura il traffico

Ci possiamo difendere tramite:


- https
- Per difenderci dal server web che raccoglie le nostre informazioni, possiamo mettere
qualcuno in mezzo ,un proxy, cambiando proxy server in modo che anche lo
pseudonimo del server diventi variabile e il tracciamento difficile. Bisognerebbe anche
cambiare i borwser o almeno le stringhe identificative
- Per difederci dalla censura possiamo utilizzare le tecniche di onion routing.
Proxy
Se utilizziamo un proxy normale, le informazioni che rileviamo sono comunque tantissime.
Quindi bisogna utilizzare proxy abili nella gestione delle informazioni, che si chiamano
“transparent proxy”, in cui tutto è trasparente ma anche il client ip è dichiarato.
Poi ci sono gli “anonimous proxy”, nascondo l’IP ma tutte le altre informazioni ci sono.
Poi ci sono i “distorting proxy” che mostrano un numero IP falso. Poi ci sono gli High Anonymity
Proxies che lasciano tutti i campi vuoti.

Privoxy
Uno di questi proxy adatti alla privacy è privoxy, è un prodotto open source, è un proxy web
pensato per la privacy. Si possono personalizzare tante cose, gestisce cose complicate come i
cookie, javascript,etc… noi possiamo personalizzare privoxy che cancelli tutti gli header dal
browser o li falsifichi. Questa categoria di prodotti è detta protocol cleaner.

Onion Routing
Una possibile difesa dei tentavi di censura dei gestori della rete
Onion Routing (OR), come una cipolla a strati, è una tecnica sviluppata dal Naval Research
Laboratory di Washington.
Il traffico viene instradato in una serie (mutevole) di onion router, cioè di router speciali, in
maniera tale da rendere difficile il tracciamento delle attività.
Gli onion router costituiscono dei mix di Chaum, è una tecnica classica per ottenre anonimato,
gli onion router sono costruiti attorno questo concetto.

Mix di chaum
È un qualcosa che rende le correlazioni tra ingresso e uscita difficili da costuire. Un mix riceve
messaggi di lunghezza fissa, li cripta, aspetta di averne in numero sufficiente da garantire un
certo livello di anonimato e inoltra i messaggi (in ordine arbitrario) ad altri mix.

Onion router
Sono analoghi ai mix di chaum.
- Gli onion router intermedi non hanno informazione sufficiente per tracciare
mittente/destinatario e traffico
- Rimane una certa criticità degli exit node(gli onion router che fanno la consegna finale,
perché conoscono il destinatatio) e (minore) dei nodi d'entrata.
TOR

TOR (The Onion Router project) è l'evoluzione più recente del concetto di Onion routing.
Sviluppato da NRL, open source, supportato da EFF. Il progetto fa parecchi sforzi per rendere il
prodotto comprensibile e utilizzabile anche da utenti inesperti (il numero di
utenti è un valore per l'anonimato).

Onion router con TOR

È un’implementazione di onion router, basato sui mix che rende difficile costuire il traffico. Alice
vuole parlare con Bob tramite una rete di onion router. La prima cosa che deve fare è ottenere
una lista di nodi TOR(per esempio da Dave li procura).

A questo punto il Client TOR di alice, costruisce un path totalmente casuale tra questi onion
router. Le frecce verdi indicano un link criptato, quelle rosse link non criptati. Il client serve per
selezionare questo percorso, che è il percorso utlizzato. Bob riceve il percorso dalla exit
node(nodo di uscita) dalla rete TOR, e quindi è difficile ricostruire il fatto che alice sta parlando
con bob, persino per bob è difficile sapere che la comunicazione arriva da li.

Qualora alice voglia fare una nuova connessione è quasi certo che verrà usato un percorso
completamente diverso da quello di prima. Per ogni connessione viene attibato un nuovo
percorso. Da jane ad esempio si connette in un percorso diverso.

Circuiti

L'instradamento di ogni messaggio


viene detto circuito
- Ogni nodo del circuito conosce solo il nodo precedente e successivo (non origine e
destinazione)
- Molte richieste diverse vengono multiplexate in un unico circuito
- Robusto rispetto alla compromissione o l'introduzione di onion router malevoli
- Nodi trusted operano da directory server iniziali

Struttura di una rete TOR


- Nodi utenti hanno un Onion Proxy (OP)
- Onion Router (OR) connessi tra loro con TSL
- Gli OR hanno una long-term key e short-term \onion" key
- L'unità di trasmissione è la cella, di dimensione fissa di 512 byte
I circuiti:
- l'OP costruisce un circuito in background, e diversi stream utente vengono multiplexati
sullo stesso circuito
- Ogni minuto viene creato un nuovo circuito

Creazione dello stream


L'OP sceglie quale OR può fare da exit node (ognuno ha una exit
policy)mSolo TCP stream possono essere creati (UDP, e quindi le risouzioni DNS, rimangono
problematiche: vedi http://code.google.com/p/torsocks/ per una soluzione) Un protocol cleaner è
necessario per evitare che informazioni rilevanti finiscano nello stream.

Reti p2p
Sono reti composte da un gruppo di nodi, in cui ogni nodo opera sia come client che come
server, lo stesso nodo può fare le stesse operazioni dell’alltro, partecipano tutti al protocollo
nella stessa maniera. Ci sono 2 famigli importanti della rete p2p:
- Napster-like: un server centrale conserva un indice dei servizi
- Gnutella-like: anche l'indice è distribuito fra i peer (eccetto un elenco dibootstrapping)
Privacy delle operazioni
- L'indice (chi fornisce che cosa) è sostanzialmente pubblico
- La fruizione del servizio generalmente è HTTP (vedi privacy web)
- In alcuni casi (p.es. BitTorrent) i metadati contengono molte informazioni personali
- Potrebbero essere necessarie anche operazioni in cui non si è direttamente interessati
(In Svizzera p.es., dove è permesso il download di materiale protetto da copyright, è
vietato condividerlo)

Freenet
Un tentativo di realizzare un sistema di pubblicazione di contenuti resistente alle censure
- peer-to-peer e completamente decentralizzato(quindi di tipo nutella)
- i dati vengono criptati e replicati su molti nodi
- diventa estremamente difficile sapere chi ha che cosa
- i singoli nodi non hanno modo di sapere cosa mettono a disposizione

Architettura di Freenet
- Ogni contenuto _e identificato solo da un hash SHA-256 (non c'è supporto diretto alle
ricerche)
- Ogni nodo “conosce" solo un numero ristretto di altri nodi che può raggiungere
direttamente
- I contenuti vengono passati ai vicini (e posti in una cache locale), senza sapere se è la
destinazione finale
- key-based routing euristico

- Un nodo inserisce un file nella rete: a quel punto può anche disconnettersi, perchè il file
viene spezzato e conservato fra i peer attivi
- I contenuti più richiesti vengono inseriti più frequentemente nelle cache (mentre quelli
non richiesti tendono a sparire)
- Opennet (chiunque può connettersi) e Darknet (rete fra trusted node con topologia
manuale)

Potrebbero piacerti anche