IOT E SICUREZZA 2 - NETWORK SECURITY - TOMMASO PECORELLA, PHD DPT. INGEGNERIA DELL'INFORMAZIONE - UNIV. FIRENZE 2 - NETWORK SECURITY
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
IoT e Sicurezza
Ottobre 2018
IoT e Sicurezza
2 – Network security
Tommaso Pecorella, PhD
Dpt. Ingegneria dell’Informazione - Univ. Firenze
This work is licensed under a Creative Commons
“Attribution-NonCommercial-ShareAlike 4.0 International”
license.
Firenze – Ottobre 2018
IoT e Sicurezza
Ottobre 2018
Outline
Attaccanti
Fisionomia dell’attaccante
Sicurezza – approccio sistematico
Security e Safety
Have a plan
Vulnerabilità
Vulnerabilità nel TCP/IP
ARP e NDP spoofing
SYN flooding
TCP Reset
DNS Poisoning
Strumenti di difesa
Firewalls
Intrusion Detection / Prevention Systems
1
IoT e Sicurezza
Ottobre 2018
Hackers
Il primo che dice la parola ‘Hacker’ verrà accompagnato alla porta.
E’ come dire ‘Ho la febbre perché ho preso un virus’.
Quale virus ? Influenza, Epatite, Ebola ?
A computer hacker is any skilled computer expert that uses their technical
knowledge to overcome a problem. While "hacker" can refer to any skilled com-
puter programmer, the term has become associated in popular culture with a "se-
curity hacker", someone who, with their technical knowledge, uses bugs or exploits
to break into computer systems.
Wikipedia
Il termine risale agli anni ’60
2
IoT e Sicurezza
Ottobre 2018
Attaccanti
Gli attaccanti si riconoscono dal cappello
• White hat – Effettua attacchi con scopi NON malevoli.
• Black hat – Effettua attacchi con scopi malevoli.
• Grey hat – Metà White, metà Black.
• Script kiddie – Attaccante senza specifiche skills, usa attacchi ‘preconfezionati’.
• Blue hat – Attaccante ‘interno’ all’azienda. Tester di sicurezza.
• Hacktivist – Attaccante con scopi sociali, ideologici, religiosi, politici, etc. Vuole
diffondere un messaggio.
• Nation state – Sperate di non esserne vittima.
I più pericolosi sono gli Script Kiddie – perché non sanno quello che fanno.
I più dannosi sono i Black hats – perché sanno quello che fanno.
I più costosi sono gli White hats – perché vi diranno cosa non va.
3
IoT e Sicurezza
Ottobre 2018
Cos’è la sicurezza
La sicurezza è un concetto apparentemente semplice.
• NIST Computer Security Handbook1 definisce la computer security come:
Protection afforded to an automated information system in order to attain the ap-
plicable objectives of preserving the Integrity, Availability, and Confidentiality of
system resources.
• Si possono definire 6 proprietà:
• Availability (Disponibilità);
• Authentication (Autenticazione);
• Confidentiality (Confidenzialità);
• Integrity (Integrità);
• Non repudiation (Non ripudiabilità);
• Access control (Controllo degli accessi).
1 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-12r1.pdf 4IoT e Sicurezza
Ottobre 2018
Availability – Disponibilità
• Il servizio deve essere disponibile;
• La disponibilità è molto difficile da garantire ⇒ è compito della pianificazione del
servizio;
• Gli attacchi di Denial of Service (DoS) minano la disponibilità del servizio.
• Gli attacchi DoS devono essere difficili da realizzare !
5IoT e Sicurezza
Ottobre 2018
Authentication – Autenticazione
• Occorre essere sicuri dell’identità dei soggetti;
• Verificare l’identità di un soggetto è complesso;
• Mantenere i dati di autenticazione segreti è ancora più complesso;
• Si usano firme digitali.
6IoT e Sicurezza
Ottobre 2018
Confidentiality - Confidenzialità
• I dati scambiati tra mittente e ricevente devono essere mantenuti segreti;
• Si possono sempre intercettare i dati su Internet (sniffing);
• Per avere confidenzialità si usa la crittografia.
7IoT e Sicurezza
Ottobre 2018
Integrity – Integrità
• I dati non devono essere alterati (durante la trasmissione);
• E’ possibile alterare un messaggio senza violare la cifratura ⇒ bit flipping attack;
• Per avere integrità si usano funzioni di hash.
8IoT e Sicurezza
Ottobre 2018
Non repudiation – Non ripudiabilità
• Non si può negare di aver mandato un messaggio;
• E’ importante quando si mandano documenti;
• Si usano le digital signature.
9IoT e Sicurezza
Ottobre 2018
Access control – Controllo degli accessi
• Assegnare i profili agli utenti e limitare gli accessi ai servizi agli utenti autorizzati;
• Bisogna prima avere un’autenticazione;
• Necessario per una buona politica di sicrezza;
• Limitare (e isolare) le conseguenze legali;
• Occorre usare tecniche di accounting.
10IoT e Sicurezza
Ottobre 2018
E’ questa la sicurezza ?
Per fortuna no
La “sicurezza” è in realtà una cosa un po’ più ampia.
Sicurezza in inglese si traduce con DUE termini: Security e Safety.
11IoT e Sicurezza
Ottobre 2018
Security e Safety
Security
1. The quality or state of being secure from danger, fear or anxiety, the prospect of being laid off (job security), etc.
2. Something given, deposited, or pledged to make certain the fulfillment of an obligation
3. An instrument of investment in the form of a document (as a stock certificate or bond) providing evidence of its ownership
4. Something that secures, e.g., measures taken to guard against espionage or sabotage, crime, attack, or escape – an
organization or department whose task is security
Safety
1. The condition of being safe from undergoing or causing hurt, injury, or loss
2. A device (as on a weapon or a machine) designed to prevent inadvertent or hazardous operation
...
http://www.merriam-webster.com/dictionary/safety
12IoT e Sicurezza
Ottobre 2018
Sicurezza e costi
E’ anche abbastanza chiaro che la sicurezza ha un costo in termini di:
1. Aumento della complessità del sistema.
2. Implementazione e manutenzione.
3. Operatività (certe cose non si possono fare, o si possono ma).
Prima di parlare di come rendere un sistema sicuro, occorre quindi sapere cosa deve
essere reso sicuro, perché e contro chi.
Un sistema di sicurezza eccessivo o di cui non si comprendano gli scopi è destinato a
essere de-implementato, quindi è inutile.
Serve un sistema per descrivere il cosa.
13IoT e Sicurezza
Ottobre 2018
Enterprise Architecture Framework
An Enterprise Architecture
Framework (EA Framework) is a
framework for an Enterprise
Architecture which defines how to
organize the structure and views
associated with an Enterprise
Architecture.’
E’ un concetto alieno.
Ma serve capirlo.
14IoT e Sicurezza
Ottobre 2018
Enterprise Architecture Framework
Gli EAF più usati sono:
• COBIT - Framework for IT Governance and Control
• TOGAF - the Open Group Architecture Framework
• DoDAF - United States Department of Defense Architectural Framework.
• MODAF - United Kingdom Ministry of Defence Architectural Framework.
• NAF - the NATO Architecture Framework
• SABSA a comprehensive framework for Enterprise Security Architecture and Service
Management.
In ambito civile TOGAF e COBIT sono tra i più usati. SABSA si può considerare un
“aggiunta”. Sembra estremamente utile ma è mal documentato.
15IoT e Sicurezza
Ottobre 2018
Enterprise Architecture Framework
Tutti gli EAF (quasi) adottano modelli
“iterativi” in cui ad ogni fase si
raffinano e precisano i concetti
precedenti.
Quasi tutti i Framework pongono
l’accento sui dati piuttosto che sulle
applicazioni e/o la tecnologia.
Si introduce quindi il concetto di
Asset.
16IoT e Sicurezza
Ottobre 2018
Asset
Si definisce asset una qualsiasi risorsa dell’Enterprise che abbia o rappresenti un valore
importante per l’Enterprise stesso.
Un asset può essere rappresentato da:
• Dati
• Componenti tecnologici (hardware)
• Componenti applicativi (applicazioni)
Un asset ha anche delle proprietà intrinseche e/o desiderate e/o imposte dalla legge (e.g.,
i dati personali sono sottoposti alla legge sulla Privacy).
Tali proprietà sono “esportate” agli asset che interagiscono con l’asset in questione.
Lo scopo della sicurezza è quello di proteggere gli asset.
17IoT e Sicurezza
Ottobre 2018
Risk management
Il Risk Management è un processo composto da:
1. identificazione
2. valutazione
3. riduzione del rischio a livelli accettabili
4. implementazione di contromisure per mantenere il livello di rischio definito
Quello che siamo abituati a pensare come “sicurezza” è svolto ai punti 3 e 4.
18IoT e Sicurezza
Ottobre 2018
Risk assessment methodologies
Il Risk assessment può essere qualitativo o quantitativo.
Qualitativo
Esempio: matrici importanza (influenza) / probabilità di occorrenza
Danno una visione semplice e sintetica dei possibili rischi
Quantitativo
Esempio:
• Asset value (AV)
• Annual rate of occurrence (ARO)
• Exposure factor (EF) (percentage)
• Single loss expectancy (SLE) = AV x EF
• Annual loss expectancy (ALE) = ALE = SLE x ARO
Quasi sempre sono stime troppo grossolane.
19IoT e Sicurezza
Ottobre 2018
Risk analysis model
Il Vulnerability Assessment è una parte chiave nel processo. 20IoT e Sicurezza
Ottobre 2018
Ricordarsi che...
Un Attacco:
1. non è mai fine a sé stesso,
2. sfrutta una vulnerabilità,
3. è rivolto ad un asset.
Un Asset:
1. ha sempre delle vulnerabilità,
2. ha un protection level e un sensitivity level,
3. si può proteggere con delle countermeasures.
Le contromisure non sono le protezioni contro le vulnerabilità (quelle sono tese ad
eliminare le vulnerabilità), sono... contromisure.
E.g.: se mi bloccano la mail mi faccio mandare un fax.
21IoT e Sicurezza
Ottobre 2018
Quindi...
Rendere ‘sicuro’ un sistema prevede di occuparsi di 3 aspetti:
1. Il sistema informatico;
2. La rete dati;
3. Gli applicativi.
Il tutto per rendere sicuri i dati.
Quello che vogliamo proteggere sono i dati (e l’operatività del sistema).
22IoT e Sicurezza
Ottobre 2018
Vulnerabilità
L’unico sistema senza vulnerabilità è un computer:
• Spento.
• Disassemblato.
• Le cui parti sono custodite in casseforti.
• E le casseforti sono in posti diversi.
• ... e probabilmente non basta.
Scherzo da programmatori
Ciascun programma contiene almeno un bug e almeno una istruzione di troppo.
Per induzione tutti i programmi possono essere ridotti a una sola istruzione. Sbagliata.
Per le vulnerabilità è lo stesso
Nessun programma è privo di vulnerabilità (con pochissime eccezioni)
23IoT e Sicurezza
Ottobre 2018
Vulnerabilità – origine
Esistono cinque motivi per avere delle vulnerabilità in un sistema:
• By design.
• By bad design.
• By bad implementation.
• By bad deployment.
• By {library, OS, etc.} update.
Ce ne potrebbero essere altri, ma questi sono i più comuni.
Scoprire una vulnerabilità è costoso. Meglio prevenire.
24IoT e Sicurezza
Ottobre 2018
Vulnerabilità by design
In questo caso la vulnerabilità è nota e accettata.
Si può avere una vulnerabilità by design quando il protocollo (o il sistema) non
funzionerebbe se si eliminasse la vulnerabilità.
Esempi:
• Protocolli di resource discovery.
• ARP / NDISC.
• NAT.
25IoT e Sicurezza
Ottobre 2018
Vulnerabilità by bad design
Si è fatto un errore nella progettazione del protocollo, non tenendo in conto aspetti cruciali.
Esempi:
• SAMBA (File sharing di Windows).
• Attacchi alla Speculative Execution nei processori.
• Errori nella sequenza di gestione delle eccezioni.
26IoT e Sicurezza
Ottobre 2018
Vulnerabilità by bad implementation
Si è fatto un errore nell’implementazione del protocollo (bugs).
Esempi:
• infiniti esempi...
• if / then / else non terminati.
• Copia di memoria non controllato.
• Input non controllato.
• etc.
27IoT e Sicurezza
Ottobre 2018
Vulnerabilità by bad deployment
Si è fatto un errore nel deployment del sistema.
Il sistema funziona in laboratorio e nel testbed, ma non sul campo.
Esempi:
• LAN non taggate.
• Ritardi e errori di rete non gestiti bene.
• Server che non rispondono nei tempi previsti (e errore nella gestione dell’eccezione).
• etc.
28IoT e Sicurezza
Ottobre 2018
Vulnerabilità by {library, OS, etc.} update
La vulnerabilità non è nell’applicazione, ma nella libreria.
Molti (troppi) sistemi si basano su librerie. Non sempre un aggiornamento delle librerie è
indolore.
Esempi:
• Funzioni dichiarate obsolete.
• Bug introdotti nelle librerie.
• Numeri casuali non più così casuali.
• etc.
29IoT e Sicurezza
Ottobre 2018
Vulnerabilità by bad implementation (o design)
Come si fa a trovare le vulnerabilità ?
Ne riparleremo, ma...
Alcune buone notizie:
1. Le vulnerabilità si pagano (in senso, venite pagati se ne trovate una).
Esempio: https://www.bugcrowd.com/bug-bounty-list/
2. Esistono dei database delle vulnerabilità note:
Common Vulnerabilities and Exposures (CVE) – https://cve.mitre.org
Common Weakness Enumeration (CWE) – https://cwe.mitre.org
Molte vulnerabilità vengono ‘chiuse’ in breve tempo. In molti altri casi esistono delle
tecniche di mitigazione (i.e., per evitare che la vulnerabilità venga usata).
In ogni caso è necessario sapere le vulnerabilità dei prodotti che si usano.
E’ uno sporco lavoro, ma qualcuno deve farlo.
30IoT e Sicurezza
Ottobre 2018
Vulnerabilità nei protocolli TCP/IP
Il TCP/IP non è esente da vulnerabilità.
Alcune sono by design, altre by bad (outdated) design.
Esempi:
• ARP e NDP spoofing.
• SYN Flooding.
• TCP Reset.
• DNS poisoning.
Sono solo alcuni esempi di vulnerabilità. Ne esistono molte altre.
31IoT e Sicurezza
Ottobre 2018
ARP e NDISC spoofing
ARP: Address Resolution Protocol (IPv4)
NDP: Neighbor Discovery Protocol (IPv6)
Sono due protocolli che assolvono allo stesso scopo:
Dato un indirizzo IP di un host, scoprire il suo indirizzo MAC.
Il funzionamento è simile: si manda un pacchetto Request in broadcast (IPv4) o multicast
(IPv6) e si aspetta una risposta.
L’attacco consiste nel rispondere al posto dell’host ‘vero’. La conseguenza è che l’host
attaccato (chi ha fatto la richiesta) manderà all’attaccante (che ha risposto) i pacchetti che
dovrebbe mandare alla destinazione legittima.
32IoT e Sicurezza
Ottobre 2018
ARP e NDISC spoofing – perché funziona (e perché non ci si può
difendere)
ARP e NDP sono pensati per essere veloci e reattivi.
Se un host cambia la sua scheda di rete (il suo indirizzo MAC) deve poter mandare un
messaggio unsolicited, altrimenti si dovrebbe aspettare che il mittente si accorga che c’è
qualcosa che non va (di solito parecchi secondi).
Quindi, ARP e NDP accettano risposte unsolicited, e prendono per buona l’ultima risposta
che ricevono.
E’ un caso di vulnerabilità by design.
Ci si protegge monitorando le risposte ARP e NDP nello switch.
Autenticare ARP e NDP funziona, ma si perdono alcune funzionalità della rete.
33IoT e Sicurezza
Ottobre 2018
SYN flooding
Il flag SYN in un pacchetto TCP serve a iniziare una sessione.
La sequenza ‘normale’ è SYN – SIN-ACK – ACK.
Quando si riceve un SYN si allocano delle risorse (buffer di trasmissione e ricezione,
contatori, etc.).
Cosa succede se un attaccante manda solo pacchetti con il flag di SYN ?
L’host attaccato consumerà le sue risorse (vengono liberate dopo un timeout molto lungo).
E’ una vulnerabilità by design.
Ci si protegge allocando solo un ‘cookie’, il che rende l’attacco molto più complesso.
34IoT e Sicurezza
Ottobre 2018
TCP Reset
Una connessione viene chiusa (legittimamente) mandano un pacchetto con il flag di
RESET attivo.
Problema: un host accetta qualsiasi pacchetto con un sequence number compreso tra
l’ultimo arrivato correttamente e il massimo che l’altro endpoint potrebbe trasmettere.
Dipende dalla dimensione della finestra (Window) del TCP, che a sua volta dipende dalla
velocità della connessione e dal Round Trip Time tra i due host.
Nota:
• Il sequence number è un numero a 32 bit.
• Una TCP Window può essere larga fino a 216 bytes.
• Con l’opzione TCP Window Scale si arriva a 216 214 bytes.
Per portare l’attacco basta mandare UN pacchetto con un numero di sequenza plausibile.
35IoT e Sicurezza
Ottobre 2018
TCP Reset
Supponiamo che la TCP Window sia 216 bytes.
Si manda un pacchetto, si incrementa il sequence number di 216 , si riprova.
Bastano 232 /216 = 216 = 65536 pacchetti.
Velocità # Pacchetti Tempo per una porta Tempo per 50 porte
56kbps (dialup) 216 (*50) 374 seconds (6 min.) 18700 (5.2 hours)
80kbps (DSL) 216 (*50) 262 seconds (4.3 min.) 13107 (3.6 hours)
256kbps (DSL) 216 (*50) 81 seconds (1 min.) 4050 (1.1 hours)
1.54kbps (T1) 216 (*50) 13.6 seconds 680 (11 minutes)
45mbps (DS3) 216 (*50) 1/2 second 25 seconds
155mbps (OC3) 216 (*50) 1/10 second 5 seconds
Con una TCP Window Scale massima bastano 232 /(216 214 ) = 4 pacchetti !
E’ la conseguenza di un Design reso obsoleto.
36IoT e Sicurezza
Ottobre 2018
DNS Poisoning
Normalmente i server DNS effettuano una ricerca ricorsiva fino a che:
• Si trova il sever autoritativo, o
• Si trova un server con una cache valida.
2
Root DNS 3
4
Local DNS 1
Authoritative DNS
37IoT e Sicurezza
Ottobre 2018
DNS Poisoning
E’ possibile ‘inquinare’ la cache di un server DNS, in modo che risponda con un record
falso.
Tralasciando la matematica, bastano pochi tentativi per inquinare una cache.
Vulnerability by bad deployment.
Il server DNS non dovrebbe:
1. Ricevere richieste dall’esterno,
2. Usare il protocollo DNS per comunicare con altri DNS (si deve usare il DNSSEC)
38IoT e Sicurezza
Ottobre 2018
Firewall
Un firewall serve a delimitare due (o più) zone di sicurezza all’interno di una rete.
• Rete interna (LAN) – alta sicurezza
• DeMilitarized Zone (DMZ) – media sicurezza
• Internet (WAN) – nessuna sicurezza
E’ una protezione perimetrale.
Agisce in base a regole, che devono essere decise in base alle esigenze degli utenti.
Tipicamente:
• LAN ⇒ WAN – Specifici protocolli (quasi tutti).
• LAN ⇒ DMZ – I protocolli in uso nei server della DMZ.
• WAN ⇒ DMZ – I protocolli in uso nei server della DMZ.
• Tutto il resto – Bloccato.
39IoT e Sicurezza
Ottobre 2018
Tipi Firewall
Esistono 3 tipi di firewall:
• Sateless Firewall – Non più usati.
• Stateful Firewall – Agiscono fino al L4 (TCP).
• L7 Firewall – Agiscono fino al livello applicativo.
Stateful Firewall
• Controllano tutte le connessioni TCP, UDP, etc.
• Sono in grado di bloccare la maggior parte degli attacchi.
L7 Firewall
• Controllano tutte le connessioni, fino al livello applicativo.
• Estremamente onerosi in termini di risorse.
• Non funzionano in caso di protocolli cifrati (tranne in alcuni casi).
• Necessitano di aggiornamenti continui.
40IoT e Sicurezza
Ottobre 2018
Posizionamento Firewall
Firewall singolo
• Più facile da configurare.
Due Firewalls (di marche
diverse)
• Più complesso da violare.
• ... e da configurare.
Normalmente basta un firewall
solo.
41IoT e Sicurezza
Ottobre 2018
Ridondanza del Firewall
Usare un firewall è bene, ma usarne due è meglio.
Alias: Il firewall è un Single Point of Failure. Ci sono due opzioni (più una)
Primary / Backup
• E’ semplice.
• Prestazioni costanti, ma uno dei firewall è inutilizzato.
Multi-primary
• Lievemente più complesso (di poco).
• Prestazioni degradano in base al numero di firewall attivi.
43IoT e Sicurezza
Ottobre 2018
Ridondanza del Firewall
Attenzione allo stato delle connessioni attive nel Firewall.
Un firewall Stateful (guess what) mantiene uno stato per ogni connessione attiva.
Se un Firewall si guasta le connessioni attive si interrompono.
Soluzione: State replication.
• Periodica.
• On-event.
Quale usare dipende dal tipo di connessioni che il Firewall gestisce.
44IoT e Sicurezza
Ottobre 2018
IDS / IPS
Gli Intrusion Detection Systems (IDS) e Intrusion Prevention Systems (IPS) sono sistemi
che analizzano il traffico di rete alla ricerca di pattern di traffico sospetti.
Differiscono dai Firewall in quanto non sono difese perimetrali. Servono a individuare
eventuali attacchi in corso.
Un IPS è un IDS interconnesso con un firewall – se evidenzia traffico anomalo lo blocca.
Sono molto più complessi di un Firewall, richiedono molte risorse, e sono soggetti a falsi
positivi / negativi.
45IoT e Sicurezza
Ottobre 2018
IDS / IPS
Esistono tre principali IDS/IPS Open Source:
• Snort: uno dei primi IDS, forse il più usato. E’ alla versione 3.
• Suricata: nasce come alternativa high-performance a Snort.
• Bro: nato per reti terabit. Fortemente orientato all’analisi distribuita.
46IoT e Sicurezza
Ottobre 2018
IDS / IPS – difficoltà
La difficoltà di un IDS / IPS sono le regole, ovvero i pattern che riconoscono il traffico
malevolo.
• Snort fornisce pattern aggiornati mensilmente e (su sottoscrizione) quindicinalmente.
• Suricata usa le stesse regole di Snort.
• Bro ha un linguaggio di definizione dei pattern completamente diverso.
Suggerimento: come primo approccio usate Snort (per provarlo). Poi analizzate bene il
vostro scenario.
Attenzione: Un IDS deve:
1. Essere invisibile.
2. Vedere il traffico.
In teoria un IDS dovrebbe avere una ‘probe’ su tutti i link.
47IoT e Sicurezza
Ottobre 2018
Domande ?
48Puoi anche leggere
