Nota:

Usa firewall di rete OCI per proxy di inoltro SSL e ispezione in entrata utilizzando la regola di decifrazione

Introduzione

Il servizio Oracle Cloud Infrastructure (OCI) Network Firewall è una soluzione firewall gestita basata su cloud che utilizza la tecnologia firewall di nuova generazione (NGFW) di Palo Alto Networks. Grazie alle funzionalità di firewall all'avanguardia basate sull'apprendimento automatico, il servizio Firewall di rete OCI offre una protezione di eccellente livello per i carichi di lavoro OCI, senza problemi da utilizzare all'interno dell'ecosistema OCI.

Il firewall di rete OCI ispeziona tutte le richieste, incluso il traffico cifrato TLS (Transport Layer Security), quando passa attraverso il firewall. In base alle regole dei criteri firewall definite dall'utente, il servizio può eseguire varie azioni, tra cui consenti, rifiuta, elimina, rileva le intrusioni o prevenzione. Grazie a queste solide funzioni, OCI Network Firewall è un potente strumento per proteggere i carichi di lavoro OCI da una vasta gamma di minacce alla sicurezza.

Obiettivi

L'obiettivo di questa esercitazione è fornire una guida completa all'implementazione del proxy di inoltro SSL e dell'ispezione in entrata utilizzando le regole di decifrazione nel firewall di nuova generazione in OCI Cloud.

Seguendo questa esercitazione, avrai una solida conoscenza del proxy di inoltro SSL e dell'ispezione in entrata utilizzando le regole di decifrazione e sarai in grado di applicare questa conoscenza per proteggere la tua infrastruttura di rete in OCI Cloud.

Prerequisiti

Nota: si consiglia di impostare un ambiente di test in OCI per provare le configurazioni dei firewall e le regole di decifrazione prima di implementarle in un ambiente di produzione.

Architettura

Architettura

Il criterio firewall di rete OCI è costituito da liste che includono:

Test di esempio

Per questa esercitazione, è stata creata una connessione SSH al computer Linux (nella subnet pubblica: 129.146.201.118) tramite Internet mediante una regola di sicurezza nei criteri firewall.

Ora è possibile utilizzare gli elenchi per creare regole di sicurezza per il firewall. Usando questa regola, abbiamo eseguito un SSH al computer Linux.

Comprendere la tecnologia di cifratura TLS/SSL

Nota:

TLS è un protocollo crittografico che fornisce la sicurezza end-to-end per tutti i dati inviati tra le applicazioni su Internet. La maggior parte degli scenari comuni riguarda la navigazione Web sicura. Tuttavia, può e deve essere utilizzato anche per altre applicazioni come e-mail, trasferimenti di file, video/audioconferenza, messaggistica istantanea e Voice-over-IP e così via.

È importante comprendere che TLS non protegge i dati sui sistemi finali. Garantisce la distribuzione sicura dei dati su Internet, evitando possibili intercettazioni e/o alterazioni del contenuto inviato (in transito). TLS viene in genere implementato su TCP per cifrare i protocolli Application Layer quali HTTP, FTP, SMTP e IMAP, sebbene possa essere implementato anche su UDP, DCCP e SCTP.

Per proteggere i dati, TLS si basa sulla tecnologia di crittografia per cifrare/decifrare i dati in transito inviati tramite Internet. Verranno trattati termini e concetti quali la crittografia simmetrica e asimmetrica, l'infrastruttura delle chiavi pubbliche (PKI, Public Key Infrastructure) e i certificati digitali X.509.

Per impostare, configurare e applicare il firewall di nuova generazione alla rete, è necessario comprendere il funzionamento delle connessioni TLS (ad esempio https), inclusa la configurazione e la distribuzione dei certificati digitali X.509.

Cifratura e tipi

L'idea alla base della crittografia è proprio quella di nascondere o nascondere (cifrare) le informazioni che vogliamo inviare da A a B in un "canale non sicuro". Un canale insicuro è un canale o un percorso in cui non possiamo garantire che nessuno intercetterà, rubarà o modificherà (vuota) le informazioni trasmesse da A a B e viceversa.

La crittografia ci permette di proteggere le informazioni che viaggiano attraverso un canale insicuro, crittografando (concelando) i dati originali verso la loro destinazione. Una volta ricevuto dal destinatario, il destinatario sarà in grado di decifrare i dati crittografati ricevuti al valore originale.

Esistono due tipi di cifratura: Symmetric e Asymmetric.

Cifratura simmetrica

Per cifrare/decifrare un blocco di dati, i motori di cifratura simmetrica utilizzano esattamente la stessa chiave per cifrare e decifrare i dati. In genere, questa opzione viene definita chiave master o segreto condiviso.

Cifratura chiave principale

Anche se sembra un modo semplice per ottenere la crittografia, il problema principale qui è distribuire la chiave master tra le due parti su un canale non sicuro. Questo processo di scambio di chiavi master verrà affrontato in questa esercitazione utilizzando tecniche diverse, inclusa una tecnica illustrata nella sezione seguente: Cifratura asimmetrica.

Alcuni algoritmi di cifratura simmetrica più comuni sono: AES128, AES256, Serpent, Camelia e così via.

Crittografia asimmetrica

Cifratura/crittografia asimmetrica che utilizza una coppia di chiavi correlate con una relazione speciale: qualsiasi dato cifrato con una delle chiavi di coppia può essere SOLO decifrato dall'altra chiave di coppia e l'altro modo.

Crittografia asimmetrica

In genere, le chiavi di coppia denominate chiave pubblica e chiave privata. La chiave pubblica può essere condivisa con tutti, mentre la chiave privata deve essere mantenuta segreta.

La cifratura asimmetrica risolve il problema della distribuzione delle chiavi utilizzando chiavi pubbliche per la cifratura e le chiavi private per la decifrazione (o viceversa). Il compromesso, tuttavia, è che i sistemi di cifratura asimmetrica sono molto lenti rispetto ai sistemi simmetrici e richiedono una potenza di elaborazione molto più elevata a causa delle lunghezze chiave notevolmente più lunghe.

Gli algoritmi di cifratura simmetrica sono molto più veloci e richiedono meno potenza di calcolo, ma il loro punto debole è la distribuzione della chiave, poiché la stessa chiave viene utilizzata per cifrare e decifrare le informazioni, tale chiave deve essere distribuita a chiunque deve accedere ai dati.

TLS utilizza la cifratura asimmetrica e simmetrica e non solo per la cifratura dei dati, ma per l'autenticazione delle parti coinvolte nella connessione. Qui è dove vengono eseguiti i certificati X.509.

Certificati X.509

Un certificato X.509 è un certificato digitale basato sullo standard ITU (International Telecommunications Union), ampiamente accettato, X.509 che definisce il formato dei certificati dell'infrastruttura a chiave pubblica (PKI). Un certificato X.509 viene progettato utilizzando una coppia di chiavi composta da una chiave pubblica correlata e una chiave privata. Come abbiamo già detto in precedenza, questa coppia di chiavi è esattamente la coppia di chiavi utilizzate nella crittografia asimmetrica, in cui ne scegliamo una pubblica e l'altra privata. Ricorda che qualsiasi operazione cifrata con una delle chiavi può essere decifrata solo dall'altra chiave e viceversa.

Come si può immaginare, la parte pubblica della coppia di chiavi, come suggerisce il nome, è pubblica e può essere distribuita frequentemente. La chiave privata deve essere kept sicura e spesso cifrata utilizzando una chiave master in modalità simmetrica di cifratura, in modo che nessuno possa utilizzarla anche se viene rubata.

Oltre alla chiave pubblica, il certificato X.509 contiene altre informazioni che rappresentano un'identità (nome host, organizzazione o individuo), pertanto il certificato x.509 associa questa identità alla chiave pubblica contenuta.

La struttura di un certificato digitale X.509 v3 è la seguente:

Certificato

Numero versione

Numero di serie

ID algoritmo firma

Nome emittente

Periodo di validità

A partire da

Fino a

Nome oggetto

Informazioni sulla chiave pubblica dell'oggetto

Algoritmo di chiave pubblica

Chiave pubblica dell'oggetto Questa è la chiave pubblica

Identificativo univoco dell'emittente (facoltativo)

Identificativo univoco oggetto (facoltativo)

Estensioni (facoltativo)

…

Algoritmo firma certificato

Firma del certificato

La chiave pubblica è associata a un'identità rappresentata nel nome dell'oggetto, ovvero a una stringa con il seguente formato:

dove, Oggetto: C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.google.com

Questa identità appartiene quindi a Google, nel paese degli Stati Uniti, in California di stato e a un nome comune come *.google.com.

Possiamo utilizzare questo certificato per due scopi: distribuire la nostra chiave pubblica E autenticare la nostra identità ad altri utenti. Avendo questo in mente, qualsiasi computer/mobile/dispositivo là fuori, quando riceviamo il nostro certificato, possederà la nostra chiave pubblica e la nostra identità, quindi, sarà in grado di inviare informazioni cifrate utilizzando la chiave pubblica, e solo saremo in grado di decifrarlo (con la chiave privata). Inoltre, il certificato ha la nostra identità all'interno, quindi il dispositivo che lo riceve sarà in grado di fidarsi di questa identità e assicurarsi che stia scambiando informazioni con la giusta identità.

Come abbiamo detto in precedenza, la crittografia asimmetrica tramite chiavi pubbliche/private è molto più lenta della crittografia simmetrica (x4 o più) quindi non è fattibile. Inoltre, non abbiamo spiegato come il dispositivo che riceve il certificato possa davvero fidarsi dell'identità all'interno del certificato. Alla fine, il certificato X.509 è solo una parte del testo ricevuto su un canale non sicuro. Per fidarsi/autenticare un certificato ricevuto, è necessaria un'autorità di certificazione, un'organizzazione attendibile per firmare i certificati digitali. Un'autorità di certificazione verifica l'identità e la legittimità di una società o di una persona che ha richiesto un certificato e, in caso di esito positivo della verifica, CA emette un certificato firmato. Esempi di organizzazioni CA sono Oracle, VeriSign, D-Trust, DigiCert tra molti altri.

Quindi, dal punto di vista della crittografia, come funziona questo processo di firma? Ancora una volta, useremo la potenza della crittografia asimmetrica per questo, come segue:

Quindi, ora che abbiamo il nostro certificato X.509 pronto per agire. In che modo un computer/mobile/dispositivo che riceve questo certificato durante una connessione TLS può verificare se si tratta di un certificato X.509 valido? Ancora una volta, useremo la potenza della crittografia asimmetrica, come segue:

Ora che sappiamo di disporre di un certificato valido che includa il nome di dominio a cui si sta tentando di connettersi, ad esempio www.mycompanycomain.com (incluso nel nome comune o nei campi dei nomi alternativi del soggetto dal certificato), il computer/mobile/browser farà in modo che ci stiamo effettivamente connettendo al nome di dominio DNS (www.mycompanycomain.com) e non a un altro. Questa è una convalida obbligatoria in quanto chiunque può rubare il certificato X.509 e provare a utilizzarlo da un altro server di dominio DNS (www.myfakecompany.com e così via) e supererebbe il processo di convalida della firma CA.

Quindi, ora tutti i computer / dispositivi / dispositivi là fuori possono scaricare la chiave pubblica del nostro certificato e inviare dati crittografati in modo che solo noi possiamo decifrarlo. Poiché la crittografia asimmetrica è molto più lenta della crittografia simmetrica (x4 o più), non è fattibile. La soluzione deve utilizzare entrambi i metodi ed è qui che è richiesto il protocollo SSL/TLS.

Informazioni di base su TLS

TLS è un protocollo crittografico che fornisce la sicurezza end-to-end dei dati inviati tra le applicazioni su Internet. È per lo più familiare all'utente attraverso l'uso di questo strumento per la navigazione Web sicura, in particolare l'icona a forma di lucchetto visualizzata nei browser Web quando viene stabilita una sessione sicura.

TLS utilizza una combinazione di crittografia simmetrica e asimmetrica in quanto rappresenta un buon compromesso tra prestazioni e sicurezza durante la trasmissione dei dati in modo sicuro. Ricorda che la crittografia asimmetrica richiede 4 o più potenza computazionale rispetto alla crittografia simmetrica. Tuttavia, la crittografia simmetrica richiede la stessa chiave master in entrambi i lati della comunicazione per poter cifrare/decifrare il messaggio, in modo che l'obiettivo per l'uso della crittografia simmetrica sia, di essere in grado di scambiare il messaggio la chiave master (o il segreto condiviso) tra le due parti prima di un canale non sicuro e poi iniziare a usare questa chiave master per proteggere la comunicazione, cifrare/decifrare ogni messaggio inviato/ricevuto utilizzando il motore simmetrico scelto.

TLS, immagine hacker

Per scambiare una chiave master su un canale non sicuro, TLS utilizzerà due tecniche differenti che seguono lo stesso obiettivo, per scambiare in modo sicuro la chiave master/segreto condiviso in un canale non sicuro:

La metodo RSA si basa sull'utilizzo della potenza della cifratura asimmetrica (chiave privata e pubblica) per scambiare la chiave master su un canale non sicuro.

DHE/ECDHE utilizzerà calcoli matematici per generare la stessa chiave master tra due parti su un canale non sicuro. Entrambe le parti si scambieranno determinate informazioni benigne che saranno mescolate con le loro informazioni privilegiate mentre viaggia su un canale insicuro e possono essere catturate senza alcun rischio. Al termine della negoziazione, entrambi i calcoli matematici delle due parti finiscono sullo stesso segreto comune o chiave master. Ulteriori informazioni https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

Queste due metodologie di scambio delle chiavi si svolgono durante un processo denominato TLS handshake.

TLS handshake non mascherato

Un handshake SSL/TLS è una negoziazione tra due parti di una rete, ad esempio un browser e un server Web, per stabilire i dettagli della connessione. Durante questa negoziazione, le due parti effettueranno l'autenticazione (mediante certificati X509), aggiungeranno una suite di cifratura (come verrà scambiata la chiave master e quali motori di crittografia verranno utilizzati, ad esempio AES256 e 128, con hashing ad esempio SHA1, 2 e così via) e infine, quando si verifica l'autenticazione (certificato valido ricevuto) e si concorda su come stabilire un canale sicuro, avremo un canale sicuro da entrambe le parti. Questi sono i passi effettivi:

Handshake TLS

Nel grafico precedente, si utilizza RSA (chiave privata/pubblica) per scambiare la chiave master (o il segreto condiviso) da utilizzare nel motore di cifratura simmetrica concordato (ad esempio AES256 ) durante la negoziazione della suite di cifratura. Se fosse utilizzato DHE/ECDHE, invece di usare chiave pubblica e privata per scambiare la chiave master, entrambe le parti utilizzerebbero calcoli DHE, scambiando materiale benigno, per finire per calcolare lo stesso risultato in entrambe le parti. Tale risultato diventerà la chiave master (segreta condivisa) da utilizzare per la cifratura simmetrica.

Task 1: utilizzare il firewall di rete OCI per il proxy di inoltro SSL e l'ispezione in entrata utilizzando la regola di decifrazione

  1. Crea due certificati autofirmati utilizzando openssl sia per il traffico in uscita che per l'ispezione in entrata utilizzando SSL aperto sul computer Linux. Aggiornare il computer Linux per considerare attendibile il certificato.

    creazione di certificati con firma automatica

  2. Crea un vault in OCI.

    Vault

  3. Dopo la creazione del vault, creare una chiave. Il contenuto del segreto deve essere nel seguente formato.

    {

"caCertOrderedList":

[

"-----BEGIN CERTIFICATE

-----END CERTIFICATE-----\n"

],

"certKeyPair":

{

"cert" : "-----BEGIN CERTIFICATE

-----END CERTIFICATE----\n",

"key": "-----BEGIN RSA PRIVATE KEY

-----END RSA PRIVATE KEY----\n"

}

}

  4. Aggiungere il segreto mappato nel criterio firewall di rete.

    1. Scegliere il tipo di segreto mappato come proxy di inoltro SSL o ispezione in entrata SSL.

    2. Scegliere il vault creato.

    3. Scegliere il segreto.

    4. Aggiungere il segreto mappato.

      Segreto mappato

  5. Creare un profilo di decifrazione.

    1. Scegliere SSL Forward Proxy e controllare le opzioni di verifica del certificato server oppure scegliere l'ispezione SSL in entrata e controllare i controlli della modalità non supportata necessari per il traffico in uso.

      decrittazione in avanti del profilo

      profilo di decrittazione in entrata

    2. Aggiungere un profilo di decifrazione.

      Aggiunta del profilo di decrittazione

  6. Creare una regola di decifrazione.

    1. Selezionare gli indirizzi IP di origine dalla lista di indirizzi IP creata nel criterio o scegliere uno qualsiasi.

    2. Selezionare gli indirizzi IP di destinazione dalla lista di indirizzi IP creata nel criterio o scegliere uno qualsiasi.

      Indirizzo IP di destinazione

    3. Selezionare Azione per decifrare il traffico con proxy di inoltro SSL, in entrata SSL o senza decifrazione.

    4. Scegliere il profilo di decifrazione e il segreto mappato.

      Scelta del profilo di decrittazione

Una volta aggiornato il criterio con la regola di decifrazione, è possibile collegarlo al firewall.

Task 2: collegare un criterio al firewall

Durante la creazione del firewall di rete, sarà possibile scegliere il criterio da collegare al firewall.

Allegato NetworkFirewall

È stata creata una regola di decifrazione per decifrare il traffico tramite il proxy di inoltro SSL e una per l'ispezione SSL in entrata. Come indicato per la connessione SSL in uscita, tutto il traffico dalla nostra subnet pubblica verrà indirizzato a OCI Network Firewall e tramite OCI Network Firewall, sta passando da Internet Gateway a Internet.

Per le ispezioni in entrata, il gateway Internet passa attraverso l'HOP successivo come firewall e poi accedendo al nostro computer Linux nella subnet pubblica.

In base alla regola di decifrazione, per l'indirizzo IP di origine viene utilizzato Hub-Linux-Machine e per qualsiasi indirizzo IP di destinazione, il traffico deve essere decifrato dal proxy di inoltro SSL e per le connessioni in entrata per l'origine come qualsiasi e la destinazione come Hub-Linux-Machine. Deve decifrare il traffico con l'ispezione SSL in entrata.

Regole di descrizione

Nota: per qualsiasi traffico che colpisce il firewall, controlla prima le regole di decifrazione e poi le regole di sicurezza.

Domanda: come posso identificare che la regola di decifrazione è attiva per il traffico che colpisce il firewall?

Risposta: questo valore può essere visualizzato nelle metriche con un nome di conteggio accessi della regola di decifrazione associato al firewall.

Ogni volta che il computer Linux tenta di raggiungere i siti Web https su Internet o per qualsiasi connessione in entrata al computer Linux su https, il conteggio delle ricorrenze della regola di decifrazione aumenta.

Metrica firewall di rete

Task 3: utilizzare la regola di decifrazione con una regola di sicurezza per consentire o negare il traffico

Aggiungendo al caso d'uso riportato sopra, vediamo in che modo la regola di decifrazione può essere utilizzata con una regola di sicurezza per consentire o negare il traffico. Come accennato all'inizio del test case potremmo utilizzare liste per consentire o negare il traffico.

Qui è già stata creata una regola di decifrazione per il proxy di inoltro SSL e l'ispezione SSL in entrata. Ai fini del test, è stata creata una regola di sicurezza per le connessioni in uscita dal computer Hub Linux a Internet per consentire l'accesso a *.oracle.com.

Nota: per impostazione predefinita, a tutto il traffico viene negato l'accesso al firewall della rete OCI. È necessario creare una regola per il traffico che deve essere consentito.

Elenco URL:

Elenco URL

Regola di sicurezza:

Regola di sicurezza

Ora cosa accadrà quando il computer Linux tenta di accedere a *.oracle.com su Internet tramite il firewall di rete OCI.

Domanda: come si vede la regola in corso per il traffico?

Risposta: è possibile visualizzarla nei log di OCI Network Firewall.

Per oracle.com

Log firewall di rete 1

Per qualsiasi altro URL:

Log firewall di rete 2

Conferme

Autori - Luis Catalán Hernández (Esperto di rete cloud OCI e Multi Cloud), Sachin Sharma (Esperto di cloud senior OCI)

Altre risorse di apprendimento

Esplora altri laboratori su docs.oracle.com/learn o accedi a contenuti di formazione gratuiti sul canale YouTube di Oracle Learning. Inoltre, visitare education.oracle.com/learning-explorer per diventare Explorer di Oracle Learning.

Per la documentazione sul prodotto, visitare il sito Oracle Help Center.