L’autenticazione e l’autorizzazione del traffico di rete fanno parte dei pilastri di una rete Zero Trust, e in questo articolo discuterò come la crittografia venga applicata in questo ambito.
Indice degli argomenti
Crittografia contro autenticazione
La crittografia e l’autenticazione spesso vanno di pari passo, ma servono a scopi nettamente diversi.
Una crittografia applicata con tutti le precauzioni del caso garantisce riservatezza: la promessa che solo il destinatario potrà risalire al contenuto in chiaro dei dati cifrati; viceversa, l’autenticazione consente al destinatario di verificare che il messaggio è stato inviato proprio da colui o colei che afferma di essere il mittente (o il sistema mittente).
L’autenticazione ci fornisce un’altra proprietà interessante: per garantire che un messaggio sia effettivamente autentico, è necessario che il messaggio sia reso inalterabile ed essere in grado di convalidare il mittente.
Chiamata anche integrità, questa proprietà è essenziale per l’autenticazione dei messaggi.
La crittografia è possibile anche senza autenticazione, sebbene senza la convalida del mittente, un attacker è potenzialmente in grado di falsificare i messaggi, riproducendo messaggi precedenti inviati dal mittente reale: l’attacker potrebbe infatti modificare il testo cifrato, e il destinatario non avrebbe modo di saperlo.
Esistono numerosi vettori di attacco che giocano proprio sull’omissione o sulla cattiva gestione dell’autenticazione da parte delle applicazioni e delle reti; quindi, la mia (e non solo la mia) raccomandazione è quella di applicare sempre uno o più processi di autenticazione in cascata.
Autenticazione senza crittografia?
L’autenticità del messaggio è un requisito imprescindibile di una rete Zero Trust, e non è possibile progettare vere reti ZTS senza di essa.
Ma per quanto riguarda la crittografia?
La crittografia garantisce riservatezza, ma può anche diventare un fastidio ciclico: la risoluzione dei problemi tecnici (troubleshooting) diventa estremamente più difficile quando non è possibile decifrare il contenuto dei pacchetti di rete da analizzare.
Il rilevamento delle intrusioni informatiche diventa oneroso o addirittura impossibile se il traffico di rete non può essere ispezionato.
Esistono, quindi, alcuni motivi legittimi per evitare la crittografia in alcuni scenari.
Detto questo, occorre essere assolutamente certi che non ci interessi la riservatezza dei dati se scegliamo di non applicare della crittografia. Sebbene mantenere i dati non crittografati sia conveniente per i sysadmin, non è mai legittimo se i dati richiedono effettivamente riservatezza.
Ad esempio, consideriamo la seguente bozza di architettura di rete:
Si tratta di uno schema estremamente comune. Teniamo presente, tuttavia, che questa architettura cifra il traffico di rete solo in alcune aree, lasciando il resto in chiaro (a vantaggio dei sysadmin), tanto per ribadire che la riservatezza all’interno di un data center è importante tanto quanto dovrebbe esserla all’esterno.
Questi dati richiedono riservatezza, e infatti vengono cifrati durante il transito tra sedi periferiche o tra data center (DC-X) differenti, ma si tratta di una contraddizione diretta delle architetture Zero Trust, poiché questo approccio crea zone privilegiate nella rete.
Pertanto, addurre buone ragioni per non cifrare il traffico di rete è una strada molto tortuosa: in pratica sono rari i sistemi che non necessitano veramente di riservatezza, e oltre a tutto questo, risulta doverosa anche l’autenticazione.
Trustare il primo pacchetto
Il primo pacchetto di un traffico di rete spesso è oneroso: a seconda del tipo di connessione o del ciclo di vita del dispositivo, questo pacchetto può veicolare pochissima fiducia.
In genere sappiamo quali flussi aspettarci all’interno di un data center, ma nei sistemi rivolti ai clienti non abbiamo la medesima trasparenza: in genere su richiesta del cliente questi sistemi devono essere ampiamente raggiungibili, il che aumenta notevolmente i rischi di cyber security.
Possiamo utilizzare protocolli come l‘mTLS (la ‘m’ sta per mutual, ossia “TLS ad autenticazione reciproca”) per autenticare il dispositivo prima che gli sia consentito accedere al servizio; tuttavia, la superficie di attacco in questo scenario è ancora considerevole, così come le risorse rimangono ancora pubblicamente rilevabili.
Quindi, come consentire solo connessioni affidabili, eliminando silenziosamente tutte le altre, senza rispondere a un singolo pacchetto non autenticato? Questo scenario è noto come problema del primo pacchetto, e viene mitigato tramite un metodo chiamato preautenticazione, di cui uno schema ad alto livello è il seguente:
Un client in possesso della chiave di preautorizzazione invia un pacchetto firmato (il pacchetto SPA) per consentire l’avvio di una connessione TCP. Senza di esso, la connessione non prosegue.
Il metodo della preautenticazione
La preautenticazione può essere considerata come l’autorizzazione di una richiesta di autenticazione impostando un’aspettativa.
Spesso viene ottenuta cifrando e firmando una piccola porzione di dati e inviandola alla risorsa destinazione come pacchetto UDP. L’uso di UDP per la preautenticazione è importante poiché i pacchetti UDP progettualmente non ricevono una risposta.
Questa proprietà ci permette di “nasconderci”, esponendoci solo quando abbiamo ricevuto un pacchetto cifrato con la giusta chiave.
Dopo la ricezione passiva di un pacchetto di preautenticazione adeguatamente crittografato possiamo aspettarci che il mittente inizi l’autenticazione con noi, e potremo quindi creare dei varchi granulari nel firewall consentendo di parlare con il nostro solo al mittente, ma tramite TLS.
L’autenticazione a pacchetto singolo
Questa schema di preautenticazione è noto anche come Autorizzazione a pacchetto singolo (SPA, Single Packet Authorization).
SPA non è uno schema completo di autenticazione del dispositivo: semplicemente aiuta a mitigare il problema del primo pacchetto. Senza minimizzare la fondamentale importanza delle proprietà che otteniamo avvalendoci della preautenticazione, quest’ultima non dovrebbe essere sostituita con un protocollo di autenticazione reciproca come TLS o IKE, bensì usata in aggiunta alla mutua autenticazione.
SPA essenzialmente è un’evoluzione del Port Knocking (PK), e risolve molti dei suoi limiti pur conservando i suoi vantaggi principali.
Le limitazioni del PK includono una complessità generale nella protezione contro gli attacchi replay, mentre cifrari asimmetrici e schemi HMAC non sono solitamente in grado di supportare il PK in modo affidabile.
Tutte queste carenze vengono risolte da SPA. Allo stesso tempo, SPA nasconde i servizi dietro policy firewall di rilascio predefinite che acquisiscono passivamente i dati (solitamente tramite libpcap) e implementano operazioni crittografiche standard per l’autenticazione e la cifratura/decifratura dei pacchetti SPA.
I pacchetti SPA generabili tramite il software fwknop (il cui acronimo deriva da “FireWall KNock OPerator”, e giunto alla versione 2.6.11 nel momento in cui sto scrivendo) ad esempio, sfruttano HMAC per la crittografia autenticata (documentata nel modello Authenticated Encryption (AE)).
Sebbene l’utilizzo di un HMAC sia – ahimè – attualmente facoltativo in molte organizzazioni (ma abilitabile proprio in fwknop tramite l’opzione da riga di comando –use-hmac), lo raccomando caldamente per tre buone ragioni: senza un HMAC l’autenticazione crittograficamente forte non è possibile con fwknop a meno che non venga utilizzato GnuPG, ma anche allora dovrebbe essere comunque applicato un HMAC.
Un HMAC applicato dopo la crittografia protegge da attacchi crittoanalitici CBC-mode padding oracle, come l’attacco Vaudenay e le sue varianti. Il codice richiesto dal servizio fwknopd per verificare un HMAC è molto più contenuto di quello richiesto per decifrare un pacchetto SPA; quindi, un pacchetto SPA senza un HMAC adeguato non viene nemmeno inviato tramite le routine di decifratura.
L’ultimo motivo a cui accennavo è il motivo per cui un HMAC dovrebbe comunque essere utilizzato anche quando i pacchetti SPA vengono cifrati con GnuPG: poiché i dati SPA non vengono inviati tramite le funzioni libgpgme a meno che l’HMAC non effettui prima il check-out. GnuPG e libgpgme sono librerie di codice relativamente complesso, ergo limitare la capacità di un potenziale attacker di interagire con questo codice attraverso un’operazione HMAC contribuisce a mantenere una Security Posture più robusta.
La generazione di un HMAC per le comunicazioni SPA richiede una chiave dedicata oltre alla normale chiave di crittografia, ed entrambe possono essere generate con l’opzione –key-gen. Fwknop può cifrare i pacchetti SPA attraverso algoritmi di crittografia a blocchi come AES, oppure tramite GnuPG e la cifratura asimmetrica associata.
Se viene scelto il metodo di crittografia simmetrica, come al solito la chiave di crittografia viene condivisa tra il client e il server (aprire il file /etc/fwknop/access.conf per i dettagli).
La chiave di crittografia effettiva utilizzata per cifrare tramite AES viene generata tramite l’algoritmo di derivazione della chiave PBKDF1 standard, e viene impostata la modalità CBC.
Se viene scelto il metodo GnuPG, le chiavi di crittografia derivano dai keyring GnuPG.
Le applicazioni personali o le piccole installazioni potrebbero optare per AES poiché non richiede alcuno strumento GnuPG. AES è anche più performante per quanto riguarda il volume dei dati e il sovraccarico computazionale, tuttavia presenta alcuni svantaggi, praticamente tutti derivanti dal fatto che si tratta di un algoritmo simmetrico.
La crittografia simmetrica comporta problemi di distribuzione delle chiavi e, oltre una certa scala, questi scenari possono diventare insostenibili. Viceversa, sfruttare la crittografia di GnuPG risolve la maggior parte di questi problemi ed è la modalità operativa consigliata, nonostante sia meno performante della sua controparte.
L’implementazione di SPA tramite fwknop consta di sette campi obbligatori e tre campi facoltativi trasportati attraverso il suo payload. Tra questi figurano uno username, la richiesta di accesso stessa (quale porta ecc.), un timestamp e un checksum:
- 16 byte di dati casuali
- l’username locale
- il timestamp locale
- la versione di fwknop
- il tipo di messaggio SPA
- la richiesta d’accesso
- un digest del messaggio SPA (hashato di default tramite SHA-256)
Una volta che il client avrà generato il payload, quest’ultimo verrà cifrato, gli verrà aggiunto un HMAC (che progettualmente è opzionale, ma che in realtà aggiungerlo sempre è indubbiamente una best practice), e infine il pacchetto SPA verrà trasmesso.
Utilizzando un firewall per mantenere un approccio default drop, l’applicazione principale di fwknop sarà quella di proteggere servizi come OpenSSH con un ulteriore livello di sicurezza per rendere molto più difficile lo sfruttamento di vulnerabilità (sia 0-day che vulnerabilità pubbliche ancora prive di patch).
Con fwknop distribuito, chiunque dovesse utilizzare uno scanner di porte (come nmap ad esempio) per testare la presenza del daemon sshd, rimarrà deluso pure essendo effettivamente il servizio operativo sul server: la situazione non cambia se l’attacker desidera eseguire un brute forcing contro sshd o addirittura voglia sfruttare un exploit 0-day.
Il server di autorizzazione annusa passivamente i pacchetti SPA tramite libcap, ergo non esiste un “server” a cui connettersi nel senso tradizionale.
L’accesso a un servizio protetto viene concesso solo dopo che un pacchetto autenticato, opportunamente decifrato (e non riprodotto) viene monitorato da un client fwknop (nel seguente diagramma di rete, la sessione SSH può avvenire solo dopo che il pacchetto SPA viene sniffato):
Ricapitolando i benefici di fwknop e in generale dello schema SPA:
- può utilizzare algoritmi asimmetrici per la cifratura
- i pacchetti SPA vengono autenticatati con un HMAC rispettando il modello AE
- i pacchetti SPA non sono riproducibili
- SPA non può essere interrotto da banali attacchi di manipolazione delle sequenze
- SPA invia solo un singolo pacchetto sulla rete
- SPA è più veloce del più classico PK
Conclusioni
Giunti al termine di questa breve digressione su fwknop, risulta palese che SPA dovrebbe essere adottato come parte di una strategia complessiva di cyber security in grado di fornire protezione contro attacchi casuali e mirati alle reti, non pensando che sia una soluzione tecnica completa e autonoma.
Proprio in tal senso, nel prossimo articolo continueremo questo nostro viaggio nel mondo della ZTS analizzando i più diffusi modelli di rete adottati oggigiorno.
