Il termine sicurezza è molto generico e può intendere diversi aspetti:

L’immagine illustra lo scenario nel quale abbiamo uno scambio di messaggi in chiaro sulla rete tra Alice e Bob che viene intercetttato da Trudy, un intruso.
Affinché Ailce e Bob possano scambiarsi messaggi in sicurezza, mantenendo i requisiti di confidenzialità, autenticazione e integrità, devono devono scambiarsi prima dei messaggi di controllo e soccessivamente dei messaggi di dati.
In intruso può infatti può:
Per rendere illegibile un messaggio gli si applica un algoritmo di cifratura.
In una comunicazione standard tra utenti, l’algoritmo di cifratura è standard e noto. La sicurezza infatti non sta nel funzionamento dell’algoritmo, ma dalla chiave di cifratura $K$ che viene utilizzata da ogni utente.

$m$ è il testo in chiaro, $K_A(m)$ è il messaggio m cifrato con la chiave $K_A$. Per ottenere il messaggio va decifrato con $m = K_B(K_A(m))$.
Trudy può ancora intercettare il messaggio, ma stavolta otterrà $K_A(m)$, che non ha un vero e proprio significato.
Prima di poter accedere al messaggio $m$ deve riuscire a decifrarlo in qualche modo.
Per valutare un algoritmo di cifratura si misura quanto è facile decifrarlo senza avere la chiave.
Esistono due approcci attraverso i quali è possibile decifrare un messaggio senza la chiave:
In questo assioma crittografico sia Alice che Bob possiedono la stessa chiave $K_S$ (per questo si dice simmetrica).
Per decidere la chiave comune si utilizza un cifrario.
Il più semplice cifrario è quello di sostituzione:
Si sostituisce un carattere con un altro
Un cifrario monoalfabetico sostituisce una lettera con un altra. Dato il semplice plaintext: abcdefghijklmnopqrstuvwxyz si può tradurre con il testo cifrato ciphertext: mnbvcxzasdfghjklpoiuytrewq.
In questo caso:
bob. i love you. alice
Diventa:
nkn. s gktc wky. mgsbc
La chiave di cifratura è quindi mappata da un set di 26 lettere per mappare 26 lettere, ottenendo $26! - 1$ possibili chiavi.
Un altro algoritmo più complesso è l’algoritmo a _$n$ cifrari di sostituzioni__
Per ogni simbolo si effettua una sostituzione seguendo un diverso cifrario. Il cifrario da utilizzare è otenuto a partire dalla posizione del carattere. La lettera alla posizione $i$ utilizzerà il cifrario alla posizione $i \% n$ nel cycling pattern
Dati $n$ cifrari con il seguente cycling pattern: $M_1, M_3, M_4, M_3, M_2$, cifrare una parola come dog verrà cifrata come : $M_1(d)M_3(o)M_4(g)$.
In questo caso la chiave corrisponde prorpio al numero di cifrari e al cyclic pattern utilizzato.
Questi tipi di cifrari soffrono del problema che nella lingua molte parole sono standard nei discorsi, così come il numero di parole sensate composte da poche lettere sono poche, ed è quindi possibile decifrare almeno quelle poche parole.
A quel punto, attraverso analisi statistiche è possibile riuscire a tradurre parti del messaggio, rendendo più semplice il decriptaggio di tutto il messaggio.
Esistono quindi altri tipi di cifratura più sicuri utilizzati. Il primo approccio è la cifratura basata su Stream. Questo approccio orientato allo stream, ogni bit viene cifrato per conto proprio.
Questo tipo di approccio è utilizzato per connessioni TLS, Bluetooth, cellulari 4G e 5G
Un altro approccio è la Cifratura a Blocchi. Queto approccio divide i messaggi in blocchi di dimensioni uguali (aggiungendo eventualmente padding all’ultimo blocco), e procede a criptare ogni blocco come un unità.
Esistono diversi algoritmi orientati al blocco:
DES (Data Encryption Standard)3DES (Triple Data Encryption Standard)AES (Advanced Encryption Standard)IDEA (International Data Encryption Algorithm)L’algoritmo DES ero lo standard americano, e si basa su una chiave simmetrica a 56-bit, basata su input a blocchi a 64-bit.
Una challenge di decriptazione dimostrò che per decriptare la chiave in brute force richiede meno di un giorno.
Allora si passò al 3DES che critpa tre volte un messaggio con tre diverse chiavi.
Dal 2001 lo standard è diventato l’AES, che processa dati in blocchi di 128bit utilizzando chiavi di 128, 192 o 256 bit .
È stato dimostrato che per decifrare in brute force un messaggio che con il DES ci vuole un 1s ci vuole circa 149 trilioni di anni, basandosi sulla tecnologia dell’epoca.
Dobbiamo capire come permettere a due entità di scambiarsi la chiave in modo sicuro.
Il metodo più semplice sarebbe quello di permettere ai due personaggi di incontrarsi di persona , cosa però non sempre possibile.
Un altro modo potrebbe essere quello di utilizzare una crittografia a chiave pubblica, ma vedremo più avanti che ha poco senso logico.
Il terzo approccio è quello di utilizzare un KDC (Key Distribution Center), un entità distribuita terza fidata che permette di fare da intermediario tra le entità.
Quando un entità $i$ si registra presso un KDC ottiene una chiave $K_{i-KDC}$, una chiave simmetrica che permette di comunicare in maniera sicura al KDC.
Quando si vuole comunicare con un nuovo utente $j$, si invia una richiesta cifrata al KDC: $K_{i-KDC}(i, j)$.
Questo risponde con un messaggio cifrato con $K_{i-KDC}$ contenente:
A questo punto $i$ deve occuparsi di inoltrare così com’è il tiket a $j$. Quando $j$ la riceve è in grado di decifrarla poiché utilizza la propria chiave e otterrà informazioni su $i$ e la nuova chiave da utilizzare per le comunicazioni con $i$.
Questo approccio risolve il problema della chiave simmetrica che prevede che due utenti debbano trovare un modo per collegarsi e comunicarsi la chiave.
Questo approccio è radicalmente diverso. Si basa su due chiavi:
Quando Alice vuole inviare un mesasggio a Bob un messaggio m utilizza come chiave di cifratura la chiave pubblica di Bob $K_B^+$, trasmettendo $K_B^+(m)$.
Quando Bob riceve il messaggio lo decifra con la propria chiave privata $K_B^-(K_B^+(m)) = m$
La crittografia a chiave pubblica, detta RSA (Rivest, Shamir, Adelson algorithm), dal punto di vista computazionale, è molto più complessa. Infatti DES è almeno 100 volte più veloce della RSA. Questo, su messaggi molto grandi, può comportare un overhead non trascurabile.
Inoltre RSA richiede delle chiavi $K^+$ e $K^-$ tali che:
\(K^-(K^+(m)) = m = K^+(K^-(m))\\
K^- \not\propto K^+\)
Per ottimizzare al meglio le comunicazioni in caso di messaggi grossi si utilizza un metodo ibrido con la chiave di sessione $K_S$:
RSA per scambiarsi la chiave di sessione $K_S$L’integrità della comunicazione, nota anche come autenticazione dei mesasaggi, permette di essere sicuro che i messaggi:
Prendiamo il caso più semplice, ovvero un singolo messaggio.
Prima di parlare di come viene garantita l’integrità della comunicazione, ripassiamo le funzioni hash.
Sono delle funzioni H che prendono in ingresso un input m e restituiscono una stringa di dimensioni finita H(m) nota come hash.
L’hash rappresenta, in qualche maniera, il messaggio originale.
Le funzioni hash devono avere delle proprietà:
H(m) non deve essere possibile ottenere m[m, H(m)] deve essere computazionalmente impossibile produrre m' != m tale che H(m) == H(m')La funzione di checksum ad esempio rispetta le proprietà di produrre stringhe di dimensioni fissate (16bit) e quella di ridurre i messaggi da tanti a pochi.
Tuttavia non è resistente alle collisioni.
Le stringhe Iou100.99BOB e Iou900.19BOB infatti producono la stesso output B2 C1 D2 AC.
Il checksum non è quindi un algoritmo che permette di rispettare l’integrità della comunicazione.
Altre funzioni di hashing utilizzate che non hanno questi problemi sono:
MD5: definita in RFC 1321 calcola digest di 128bit in 4 step.SHA-1: è lo standar americano e calcola digest su 160bitMACQuesto algoritmo rispetta i principi di autenticazione e di integrità, senza utilizzare alcuna crittografia.
Sulla destra possiamo vedere un immagine che riassume i passaggi che l’algoritmo introduce.
Quando un mittente manda un messagio m e vi aggiunge un segreto s, ottenendo m+s.
Prima di inviare il messaggio calcola anche H(m+s) con una funzione di hashing (come ad esempio SHA-1 o MD5) e lo appende al messaggio, ottenendo (m, H(m+s)).
Il destinatario otterrà quindi il mesasggio (m, h), e calcolerà quindi H(m+s), utilizzando anche lui il segreto s.
Se H(m+s) == h allora concluderà che tutto è andato bene.

Lo standard più popolare di MAC oggi in utilizzo è HMAC [RFC 2104] che dopo aver generato (m, H(m+s)) performa un ulteriore hash per inviare H(m, H(m+s)).
È un tipo di attacco che avviene in due momenti diversi.
Inizialmente si copiano i messaggi che Alice invia e si salvano localmente.
Successivamente si inoltrano questi messaggi a Bob.
Questi messaggi, poiché non sono manomessi, passano il controllo del MAC, e possono essere dannosi. Infatti se venisse intercettata una richiesta di bonifico, questa potrebbe essere inoltrata ripetutamente da parte di Trudy.
Questo tipo di attacchi sfruttano una vulnerabilità di MAC, il fatto che si verifica chi produce il messaggio, ma non chi lo invia.
Infatti non vi sono verifiche di “freschezza” del messaggio, quindi che sia passato “poco tempo” tra la creazione del messaggio con l’invio del messaggio con la ricezione di esso.
Esistono diversi modi per implementare questo livello di sicurezza, uno ad esempio è quelle delle One-Time-Password, ovvero OTP.
A partire da un seed si generano pseudocasualmente ogni x secondi un nuovo codice c.
Quando un utente invia il messaggio si inserisce in m + s anche questo codice R provvedendo a fare l’hashing di H(m+s+R).
Chi riceve il messaggio provvederà anche lui a effettuare l’hash di m+s+R, avendo accesso al medesimo codice in quell’istante.
Se i due combaciano allora si ha la certezza che:
sOTP”, poiché hanno utilizzato lo stesso R generato da un algoritmo pseudocasuale nello stesso istante.La tecnica della firma digitale è una tecnica crittografica che ha lo stesso ruolo della firma cartacea, ovvero quello di stabilire che una persona è il creatore/proprietario di un documento, o che ne ha banalmente preso visione.
Una firma infatti:
m e non un altro m'MAC non garantisce le proprietà di non falsificabilità, verificatibilità e non ripudiabilità, anche se garantisce l’integrità.
Tuttavia la crittografia a chiave pubblica sì.
È possibile firmare un messaggio $m$ crittografandolo con la propria chiave privata, creando il messaggio criptato $K^-(m)$.
Precedentemente avevamo sottolieato la relazione: \(K^-(K^+(m)) = m = K^+(K^-(m))\)
Notiamo ora il motivo. Infatti:
La verifica infatti dimostra che chi ha firmato ha utilizzato la chiave privata della persona per la quale si è spacciato. Così possiamo dimostrare che:
Bob ha firmato il documentoBob ha firmato proprio m e non un altro documento diverso.Tuttavia avevamo anche detto che la crittografia di grandi messaggi richiede tanto overhead. Per risolvere ciò quello che si fa è firmare il digest della funzione di hash ottenuto dal messaggio. In questo modo abbiamo le garanzie della crittografia della chiave pubblica, ottimizzando le dimensioni attraverso le funzioni di hash.
Di seguito possiamo vedere come può avvenire l’invio e la ricezione di un messaggio.
Invio

Verifica nella ricezione

L’approccio della firma digitale attraverso la crittografia a chiave pubblica funziona, ma ha un grosso problema sottostante: “Come facciamo ad essere sicuri che la chiave pubblica di X sia davvero la chiave pubblica di X?”
Si introduce quindi una certificazione della chiave pubblica che permette di verificare senza alcun dubbio che una data chiave appartenga ad una specifica entità.
Questa certificazione è rilasciata da un entità terza, detta Certification Authority che per fornire il certificato richiede una registrazione dell’entità che desidera verificare la propria chiave pubblica.
A quel punto la CA rilascerà un certificato firmato con la propria firma digitale che garantisce che $K^+$ è la chiave pubblica dell’entità.
La verifica che la firma digitale sia autentica si verifica attraverso la chiave pubblica della CA, che è assunta nota a tutti.

A questo punto quando un utente vuole avere la chiave pubblica di un entità può richiedere direttamente alla CA la chiave pubblica dell’entità.
È il processo con il quale un entità prova la sua identità ad un altra entità.
Quando questo accade attraverso una rete non possiamo basarci sulle informazioni biometriche che invece utilizziamo quando incontriamo un’altra persona per strada, ma dobbiamo basarci sulle informazioni che un entità è in grado di fornirci per verificare la propria identità.
Non possiamo basarci su informazioni tendenzialmente note come nome, cognome, data di nascita, … Per avere la certezza che chi sta comunicando delle informazioni è necessario avere altre informazioni.
Un primo esempio è quello di una password, utilizzato nella posta elettronica per tanti anni, in quanto solo chi la crea ne è a conoscenza.
Il problema era che questo messaggio però viaggiava in chiaro, e quindi poteva essere tranquillamente sniffato (intercettato) da terzi che poteva riutilizzarlo, nei già nominati attacchi playback.
Possiamo quindi pensare di cifrare la password, ma anche questa è sniffabile, infatti non ci interessa la password vera e propria, ma il suo hash.
La soluzione può quindi essere quella di utilizzare un OTP e la cifratura a chiave pubblica.
Quando ci si autentica ad un altra entità, questa risponde con un OTP $R$.
Successivamente dovremo reinviarlo cifrandolo con la nostra chiave privata $K^-(R)$ e inviando la nostra chiave pubblica $K^+$.
L’entità verificherà la chiave pubblica, e verificherà che $K^+(K^-(R)) = R$, e che quindi siamo chi diciamo di essere.
Anche questo metodo ha delle vulnerabilità, in particolare un utente terzo può infatti fare da middlemen nella comunicazione fingendosi B con A e A con B.
La sicurezza è un servizio che può essere inserito in tutti i livelli del modello a strati di internet.
Vediamo quindi alcuni modi per implementare la sicurezza.
Se abbiamo un applicazione client/server che deve comunicare in maniera riservata, dobbiamo poter utilizzare una funzione come la send fornita dalla socket API che però implementa nativamente anche la sicurezza.
Queste funzioni si trovano nella libreria pgp (Pretty-Good-Privacy), disponibile pubblicamente su internet.
All’interno della libreria sono definite tutte una serie di funzioni che permettono di garantire la confidenzialità.
pgp implementa una tecnica di crittografia ibrida tra chiave simmetrica e chiave pubblica.
Per garantire la confidenzialità si genera una chiave di sessione che cifra il messaggio. Successivamente, nello stesso pacchetto, si cifra la chiave di sesione attraverso la chive pubblica del destinatario.
Quando il destinatario riceverà il messaggio decifra la chiave di sessione con la propria chiave privata, e utilizza questa per decifrare il messaggio.
A questo punto i due, qualora continuassero a comunicare, possono direttamente utilizzare la chiave simmetrica.

Per garantire invece l’integrità e l’autenticazione possiamo utilizzare la firma digitale.
Il mittente firmerà digitalmente il messaggio inviando un pacchetto contenente:
Il destinatario decifrerà il messaggio utilizzando la chiave pubblica del mittente e confronterà l’hash decifrato con quello generato.

Per avere tutti i vantaggi è sufficiente fare i passaggi descritti prima per quanto riguarda l’integrità e l’autenticazione e poi garantendo la confidenzialità.
Questo metodo permette al programmatore di implementare i servizi richiesti solo se necessari.
Tuttavia uno svantaggio di questo approccio è il problema della portabilità. Se infatti avessimo più applicazioni che hanno necessità delle stesse garanzie, il programmatore sarebbe costretto a riscrivere il codice ogni volta, o perlomeno, di raccogliere il codice in una libreria da dover ogni volta includere.
TLSÈ un protocollo di sicurezza costruito tra il livello di trasporto TCP e il livello applicazione che fornisce:
Prima di TLS era utilizzato il protocollo SSL (Secure Socket Layer) che però è stato depreccato nel 2015.
È un protocollo di sicurezza supportato da quasi tutti i browser e web server, ed è rappresentato dalle comunicazioni alla porta 443 tramite https.
Vediamo adesso una versione semplificata del protocollo TLS.
Sicuramente avremo questi passaggi:
Dopo aver stabilito una connessione TCP, si inzia con l’handshake del TLS.
Si invia innanzitutto il messaggio di hello, al quale l’altro risponde con il proprio certificato della chiave pubblica.
Dopo aver verificato il certificato si genera un master secret $MS$ e lo si cifra con la chiave pubblica dell’altro.
Quando il destinatario di questo messaggio lo riceverà lo decifrerà con la propria chiave privata.

Quando entrambi avranno lo stesso $MS$ si generano quattro chiavi:
Queste chiavi vengono generati attraverso una funzione di derivazione di chiavi (KDF) che utilizza come seed il $MS$ e altri dati per generare le chiavi.
Per cifrare i dati inviati all’interno di un flusso si divide il flusso in una serie di record composti da:
Ogni record viene quindi cifrato utilizzando la chiave simmetrica e solo dopo viene passato al layer TCP.
Questi record sono susciettibili a attacchi di re-ordering da un eventuale man-in-the-middle e a attacchi di replay.
Per proteggere questi record quello che si fa è:
MAC anche a partire dal numero di sequenza del TLS per proteggere dal re-orderingnonce (come la 2FA) per proteggere da attacchi di replay.Per evitare attacchi di tipo truncation, nei quale un agressore crea un finto messsaggio di chiusura terminando la connessione tra gli host, si rende sicuro anche il messaggio di chiusura.
In particolare si inserisce nei vari record un nuovo campo types che è settato a 0 se il record scambia dati o 1 se è un record di chiusura.
In questo caso il MAC viene generato dall’unione di dati, tipo e numero di sequenza.
Il TLS fornisce un API che tutti possono utilizzare.
Il protocollo QUIC incorpora TLS su UDP e forma, insieme a una versione ridotta di HTTP/2, HTTP3.
Nel TLS si utilizzano diversi strumenti, raccolti in una cipher suite:
KDF).MACDi questi algoritmi ne esistono un infinità di implementazioni, ma è necessario che gli host che partecipano alla comunicazione utilizzano gli stessi algoritmi.
Nell’ultima versione sono disponibili “solo” 5 cipher suite, ma è comunque necessario sceglierne una.
Per far si che server e client concordino sulla suite da utilizzare, il client inserisce nel messaggio di hello:
Il server allora scelgierà tra le suite proposte dal client (tipicamente il server le conosce tutte) rispondendo con il proprio certificato e il proprio nonce per garantire che questi messaggi di scambio, che ricordiamo essere mandati in chiaro, non siano stati manipolati.
IPsecIl protocollo IP sec permette di fornire cifrature a livello datagram per garantire autenticazione, identità e confidenzialità sia per il traffico dell’utente che per il controllo del traffico.
Questo può essere implementato in due modi:
Molte istituzioni spesso richiedono l’installazione di una rete privata per motivi di sicurezza, ma questa scelta è molto costosa, poiché richiede l’acquisto di router, link e la creazione di una infrastruttura DNS ad hoc.
In particolare, qualora l’organizzazione avesse più uffici distaccati, qeusta unica rete privata diventa quasi impossibile da realizzare.
Attraverso le VPN si sviluppa questa rete privata attraverso comunicazioni attraverso internet.
Quando un datagramma esce dalla rete locale dell’headquarters il gateway router convertirà il datagramma IPv4 in un datagramma IPsec, inoltrandolo su internet attraverso il tunneling.
Per chiunque intercetti il datagramma questo si presenta come un normale messaggio, quando in realtà il payload, se decifrato, rappresenta il reale datagram.
Quando questo messaggio arriverà ad al gateway router del branch office o all’OS del dispositivo della salesperson, questi decifreranno il payload e forniranno il payload decifrato al livello superiore.

Esistono due principali protocolli che permettono l’IPsec:
AH): fornisce autenticazione della sorgente e integrità dei dati, ma non implementa la confidenzialità della comunicazione. È definito in [RFC 4302]ESP): fornisce autenticazione del sorgente, integrità dei dati e confidenzialità della comunicazione sfruttando il tunneling. È definito in [RFC 4303].Tra i due quello più ampiamente utilizzato è ESP.
ESPIPsec introduce la security association (SA), ovvero una associazione per garantire i servizi di sicurezza tra due punti (tipicamente tra gateway routers) in modo unidirezionale.
Per ottenere una comunicazione bidirezionale si avranno due SA.
IPsec è quindi un protocollo connection-oriented, a differenza di IP che è connectionless.

Per funzionare la SA, sia il router R1 che il router R2 devono mantenere alcune informazioni:
SPI): identificatore a 32bit della SASASAQueste informazioni sono utilizzate da R1 per cifrare i messaggi uscenti e da R2 per decifrarli.
Quando si cifra un datagram gli si appende per prima cosa un ESP trailer.
All’interno del trailer si trovano tre campi:
Questo datagram viene cifrato con la chiave specificata dalla SA.
A questo punto si appende in cima a questo datagramma cifrato un ESP header che contiene:
SPI: per indicare quale SA si sta utilizzandoSA e viene incrementato ad ogni datagramma inviatoL’unione tra ESP header e il datagram cifrato viene chiamato enchilada.
A partire dall’enchilada viene generato un MAC di autenticazione utilizzando la chiave e l’algoritmo specificato nel SA.
A questo punto si appende il MAC alla fine dell’enchilada formando il nuovo payload.
Alla fine si crea un nuovo header IP con i classici campi IPv4 e si appende alla cima del messaggio, creando il nuovo messaggio.

Il datagram IPsec è visto dalla rete come un normalissimo IP datagram.
L’incapsulamento però modifica le informazioni di trasporto del datagramma. In particolare, mentre nell’header del messaggio originale è presente l’indirizzo IP sorgente del router di uscita (ipotizzando un architettura NAT), l’indirizzo IP contenuto nell’header del IPsec datagram sarà quello del tunneled gateway router, ovvero il router che si occupano di (de)incapsulare il datagramma.
Inoltre, per discriminare i datagrammi IPsec con protocollo ESP da quelli TCP, UDP, SMTP si inserisce il valore 50 all’interno del protocol number.
Le informazioni relative ad una SA sono conservate in entrambi gli endpoint, in particolare in due database:
SPD): indica per un dato datagramma se è necessario utilizzare IPsec a partire da alcune informazioni del datagram (indirizzi sorgente/destinatario, numero di protocollo, …)SAD): conserva lo stato delle SA e le relative informazioni su come processare un dato datagramma, sia in invio (criptaggio) che in arrivo (decriptaggio)In parole povere SAD indica come inoltrare un pacchetto e SPD cosa fare per instradarlo correttamente.
Un firewall:
Isola la rete interna di un’organizzazione dal resto di internet, permettendo il passaggio solamente ad alcuni pacchetti bloccando gli altri

Attraverso il firewall è possibile prevenire diversi tipologie di attacchi:
DoS): quando un aggressore stabilisce un numero elevato di finte connessioni TCP terminando le risorse del server. In questo modo non è più possibile stabilire vere connessioniEsistono tre tipi di firewall:
Nei primi due casi la rete interna è connessa a quella esterna attraverso il router firewall
SI effettua un filtro sui singoli pacchetti, e si prende la decisione in base alle informazioni contenute in esso, come:
TCP/UDP, porta di destinazioneTCP,SYN, ACKAd esempio possiamo scegliere di bloccare tutti i datagrammi che hanno protocol number = 17 (protocollo UDP) che hanno porta sorgente e/o destinataria 23. In questo modo tutti i pacchetti UDP o le applicazioni telnet vengono droppati dal router.
Per impostare queste regole si utilizza una Access Control List ACL, che non è altro he una tabella di regole che vengono applicate con politica top-to-bottom (si analizzano dalla prima a scendere e si applica la prima regola che corrisponde al pacchetto in questione).
Un esempio di ACL “pessimistica”:
| Action | IP source | IP dest | Protocol | Source Port | Dest Port | Flag bit |
|---|---|---|---|---|---|---|
ALLOW |
222.22/16 |
!(222.22/16) |
TCP |
>1023 |
80 |
any |
ALLOW |
!(222.22/16) |
222.22/16 |
TCP |
80 |
>1023 |
ACK |
ALLOW |
222.22/16 |
!(222.22/16) |
UDP |
>1023 |
53 |
— |
ALLOW |
!(222.22/16) |
222.22/16 |
UDP |
53 |
>1023 |
— |
DENY |
ALL |
ALL |
ALL |
ALL |
ALL |
ALL |
In questo tipo di tabella tutti i pacchetti che non sono previsti dalle regole vengono rifiutati.
Un altro approccio più “ottimistico” è quello di ammettere tutti i pacchetti tranne quelli previsti dalle regole.
È uno strumento da utilizzare con cautela poiché permette l’accesso anche a pacchetti che “non hanno senso”, come pacchetti con campi corretti (dest port = 80, ACK = 1) che però non appartengono ad alcuna connessione TCP attiva
Questo tipo di firewall tiene traccia di tutte le connessioni TCP, tracciano di valori di SYN e FIN filtrando le informazioni attraverso un timeout.
Per fare ciò espande la propria ACL:
| Action | IP source | IP dest | Protocol | Source Port | Dest Port | Flag bit | Check Connection |
|---|---|---|---|---|---|---|---|
ALLOW |
222.22/16 |
!(222.22/16) |
TCP |
>1023 |
80 |
any |
|
ALLOW |
!(222.22/16) |
222.22/16 |
TCP |
80 |
>1023 |
ACK |
X |
ALLOW |
222.22/16 |
!(222.22/16) |
UDP |
>1023 |
53 |
— | |
ALLOW |
!(222.22/16) |
222.22/16 |
UDP |
53 |
>1023 |
— | X |
DENY |
ALL |
ALL |
ALL |
ALL |
ALL |
ALL |
Questo tipo di firewall filtra i pacchetti a livello applicazione oltre che analizzando i campi IP/TCP/UDP.
Potremo infatti avere la necessità di garantire un certo tipo di servizi solo ad alcuni utenti.
Se ad esempio volessimo consentire le connessioni SSH solo ad un certo numero di utenti, possiamo installare un application gateway.
Quando un utente proverà a stabilire una connessione SSH, questa verrà rediretta sull’application gateway che esaminerà se l’utente può o meno effettuare questa azione.
Se l’utente ne ha la facoltà, sarà il gateway ad aprire la connessione con l’esterno agendo da middleman.
I firewall e i gateway non sono perfetti e non controllano tutti i parametri.
Un esempio immediato è il fatto che il filtraggio dei pacchetti considera solo gli header dei singoli pacchetti, senza controllare i payload né le correlazioni tra di essi.
Per poter implementare questo tipo di sicurezza esistono dei Sistemi di Rilevamento delle Intrusioni (Intrusion Detection System - IDS).
Questi dispositivi effettuano un ispezione profonda dei pacchetti, controllando il contenuto ed esaminando le correlazioni tra pacchetti multipli, riuscendo a prevedere port scanning, network mapping e DoS attack.
Putroppo possono soffrire di allucinazioni, ma è l’unico modo per poter riuscire ad avere delle sicurezza.
A differenza delle operazini del firewall queste operazioni sono molto pesanti e introducono un importante overhead.
Quello che si fa quindi è avere un firewall che filtra i pacchetti. Successivamente si collega il router firewall ad un application gateway attraverso un router che è anche connesso alla Zona Demilitarizzata.
Nella zona demilitarizzata si trovano tutte quelle risorse che necessitano di comunicare con il mondo esterno, e per le quali non ha senso stabilire delle regole stringenti (posta elettronica, DNS, …)
