Questo articolo è il terzo di un ciclo di articoli intitolato «Come controllare la propria infrastruttura di rete». È possibile trovare il contenuto di tutti gli articoli del ciclo e i link qui.

Non ha senso parlare di un'eliminazione totale dei rischi di sicurezza. In linea di principio, non possiamo ridurli a zero. È anche necessario comprendere che nel tentativo di rendere la rete sempre più sicura, le nostre soluzioni diventano progressivamente più costose. È fondamentale trovare un compromesso ragionevole tra costo, complessità e sicurezza per la vostra rete.

Certo, il design della sicurezza è organicamente integrato nell'architettura complessiva e le soluzioni di sicurezza utilizzate influenzano la scalabilità, l'affidabilità, la gestibilità della… infrastruttura di rete, che deve essere considerata.

Ma, ricordo che ora non stiamo parlando della creazione di una rete. Secondo i nostri parametri iniziali abbiamo già scelto il design, l'attrezzatura è stata selezionata e l'infrastruttura è stata creata, e in questa fase dobbiamo "vivere", per quanto possibile, e trovare soluzioni nel contesto dell'approccio precedentemente scelto.

Il nostro compito ora è identificare i rischi associati alla sicurezza a livello di rete e ridurli a dimensioni ragionevoli.

Audit della sicurezza di rete

Se nella vostra organizzazione sono stati implementati processi ISO 27k, l'audit della sicurezza e le modifiche alla rete devono essere armoniosamente integrate nei processi complessivi nell'ambito di questo approccio. Ma questi standard non riguardano specifiche soluzioni, non riguardano configurazioni o design… Non ci sono consigli inequivocabili, non ci sono standard che dettino dettagliatamente come dovrebbe essere la vostra rete; qui risiede la difficoltà e la bellezza di questo compito.

Vorrei evidenziare alcuni possibili audit della sicurezza della rete:

audit della configurazione dell'attrezzatura (hardening)
audit del design della sicurezza
audit degli accessi
audit dei processi

Audit della configurazione dell'attrezzatura (hardening)

Sembra che nella maggior parte dei casi questo sia il migliore punto di partenza per l'audit e il miglioramento della sicurezza della vostra rete. IMHO, è una buona dimostrazione della legge di Pareto (il 20% degli sforzi porta l'80% dei risultati, mentre il restante 80% degli sforzi porta solo il 20% dei risultati).

La sostanza è che di solito abbiamo raccomandazioni dai fornitori riguardo le «migliori pratiche» per la sicurezza quando si configura l'attrezzatura. Questo è chiamato “hardening”.

È possibile anche incontrare un questionario (o crearne uno da soli) basato su queste raccomandazioni, che vi aiuterebbe a determinare quanto la configurazione delle vostre attrezzature corrisponda a queste "best practices" e, in base ai risultati, apportare modifiche alla vostra rete. Questo vi permetterebbe di ridurre notevolmente i rischi per la sicurezza, in modo piuttosto semplice e senza costi.

Alcuni esempi per alcuni sistemi operativi Cisco.
Rafforzamento della Configurazione Cisco IOS
Rafforzamento della Configurazione Cisco IOS-XR
Rafforzamento della Configurazione Cisco NX-OS
Lista di Controllo della Sicurezza di Base Cisco
Sulla base di questi documenti, potrebbe essere creato un elenco di requisiti di configurazione per ogni tipo di attrezzatura. Ad esempio, per Cisco N7K VDC, questi requisiti potrebbero apparire così.

In questo modo, possono essere creati file di configurazione per diversi tipi di apparecchiature attive nella vostra infrastruttura di rete. Successivamente, manualmente o utilizzando l'automazione, potete "caricare" questi file di configurazione. Come automatizzare questo processo sarà trattato in un'altra serie di articoli dedicati all'orchestrazione e all'automazione.

Audit del design della sicurezza

Di solito, nella rete di un'impresa (enterprise network) si possono trovare, in un modo o nell'altro, i seguenti segmenti:

DC (DMZ dei servizi pubblici e centro dati intranet)
Accesso a Internet
VPN di accesso remoto
Edge WAN
Branch
Campus (Ufficio)
Core

I nomi sono tratti da Cisco SAFE modello, ma non è necessario, ovviamente, legarsi a questi nomi e a questo modello. Ciò che conta è parlare del contenuto senza perdersi nelle formalità.

Per ciascuno di questi segmenti, i requisiti di sicurezza, i rischi e, di conseguenza, le soluzioni varieranno.

Esamineremo ciascuno di essi separatamente in merito ai problemi con cui potreste dover affrontare dal punto di vista del design della sicurezza. Sicuramente, come ripeto, questo articolo non ha la pretesa di essere esaustivo, raggiungere la completezza in questo tema davvero profondo e complesso è difficile (se non impossibile), ma riflette la mia esperienza personale.

Non ci sono soluzioni perfette (perlomeno al momento). Si tratta sempre di un compromesso. Ma è importante che la scelta di applicare un approccio piuttosto che un altro sia fatta consapevolmente, comprendendo sia i suoi pro che i suoi contro.

Centro Dati

Il segmento più critico dal punto di vista della sicurezza.
E, come al solito, anche qui non c'è una soluzione universale. Tutto dipende fortemente dalle esigenze della rete.

È necessario un firewall o no?

Sembra semplice, ma la risposta non è affatto così chiara come potrebbe sembrare. E la tua scelta potrebbe essere influenzata non solo da il prezzo.

Esempio 1. Ritardi.
Se tra alcuni segmenti di rete un basso ritardo è un requisito fondamentale, come nel caso di una borsa valori, allora non potremo utilizzare firewall tra questi segmenti. È difficile trovare ricerche sui ritardi nei firewall, ma solo pochi modelli di switch possono fornire ritardi inferiori o circa 1 microsecondo, quindi, penso che se i microsecondi sono significativi per te, i firewall non fanno per te.

Esempio 2. Prestazioni.
La larghezza di banda dei migliori switch L3 è generalmente di un ordine di grandezza superiore rispetto alla larghezza di banda dei firewall più performanti. Pertanto, in caso di traffico altamente intensivo, dovrai anche molto probabilmente bypassare i firewall.

Esempio 3. Affidabilità.
I firewall, soprattutto i moderni NGFW (Next-Generation FW), sono dispositivi complessi. Sono significativamente più complessi degli switch L3/L2. Offrono un gran numero di servizi e possibilità di configurazione, quindi non sorprende che la loro affidabilità sia notevolmente inferiore. Se la continuità del servizio è critica per la rete, dovrai forse scegliere ciò che garantirà la migliore disponibilità: la protezione tramite firewall o la semplicità di una rete costruita su switch (o vari tipi di fabbriche) utilizzando ACL standard.

Nel caso degli esempi sopra citati, probabilmente (come al solito) dovrai trovare un compromesso. Dai un’occhiata alle seguenti soluzioni:

se hai deciso di non utilizzare firewall all'interno del data center, devi pensare a come limitare al massimo gli accessi perimetrali. Ad esempio, puoi aprire solo le porte necessarie da Internet (per il traffico dei client) e concedere accessi amministrativi al data center solo da host di accesso. Su questi host, eseguire tutti i controlli necessari (autenticazione/autorizzazione, antivirus, registrazione, …)
puoi utilizzare una suddivisione logica della rete del data center in segmenti, simile allo schema descritto in PSEFABRIC. esempio p002. In questo modo, la routing deve essere impostata in modo tale che il traffico sensibile alla latenza o il traffico ad alta intensità circoli «all'interno» di un segmento (nel caso di p002, VRF) e non passi attraverso il firewall. Il traffico tra segmenti diversi continuerà invece a passare attraverso il firewall. È anche possibile utilizzare il route leaking tra i VRF per evitare che il traffico venga reindirizzato attraverso il firewall.
È inoltre possibile utilizzare il firewall in modalità trasparente e solo per le VLAN in cui questi fattori (latenza / prestazioni) non sono significativi. Ma è necessario esaminare attentamente i vincoli associati all'uso di questa modalità per ogni fornitore.
Potete considerare l'implementazione di un'architettura di service chain. Questo permetterà di indirizzare attraverso il firewall solo il traffico necessario. Teoricamente sembra bello, ma non ho mai visto questa soluzione in produzione. Abbiamo testato la service chain per Cisco ACI / Juniper SRX / F5 LTM circa 3 anni fa, ma a quel tempo questa soluzione ci è sembrata «grezza».

Livello di protezione

Ora è necessario rispondere alla domanda su quali strumenti si desidera utilizzare per filtrare il traffico. Ecco alcune delle possibilità che di solito sono presenti negli NGFW (ad esempio, qui):

firewalling stateful (per impostazione predefinita)
firewalling delle applicazioni
prevenzione delle minacce (antivirus, anti-spyware e vulnerabilità)
filtraggio URL
filtraggio dati (filtraggio dei contenuti)
blocco file (blocco dei tipi di file)
protezione dos

E non è tutto così chiaro. Sembra che, maggiore è il livello di protezione, meglio è. Ma è necessario tenere anche conto che

maggiore è il numero delle funzioni sopra menzionate del firewall che si utilizzano, naturalmente, sarà più costoso (licenze, moduli aggiuntivi).
l'uso di alcuni algoritmi può ridurre significativamente la capacità del firewall e aumentare le latenze, si veda ad esempio qui
come qualsiasi soluzione complessa, l'uso di metodi di protezione complessi può ridurre l'affidabilità della vostra soluzione, ad esempio, con l'uso di application firewalling ho riscontrato il blocco di alcune applicazioni standard funzionanti (dns, smb).

Come al solito, è necessario trovare la soluzione ottimale per la propria rete.

Non è possibile rispondere in modo univoco alla questione su quali funzioni di protezione potrebbero essere necessarie. In primo luogo, perché dipende dai dati che stai trasferendo o memorizzando e che stai cercando di proteggere. In secondo luogo, in realtà, spesso la scelta dei mezzi di protezione è una questione di fede e fiducia nel fornitore. Non conosci gli algoritmi, non sai quanto siano efficaci e non puoi testarli completamente.

Pertanto, nei segmenti critici, una buona soluzione potrebbe essere l'utilizzo di offerte da diverse aziende. Ad esempio, puoi attivare un antivirus sul firewall, ma anche utilizzare una protezione antivirus (di un altro produttore) localmente sugli host.

Segmentazione

Si tratta di una segmentazione logica della rete del data center. Ad esempio, la suddivisione in VLAN e sottoreti è anch'essa una segmentazione logica, ma non la considereremo per ovvie ragioni. È interessante la segmentazione tenendo conto di entità come le aree di sicurezza FW, VRF (e i loro equivalenti per diversi fornitori), dispositivi logici (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, …), …

Un esempio di tale segmentazione logica e di un design di data center attualmente richiesto è riportato in p002 del progetto PSEFABRIC.

Definendo le parti logiche della tua rete, puoi quindi descrivere come si muove il traffico tra i diversi segmenti, su quali dispositivi verrà effettuata la filtrazione e con quali mezzi.

Se nella tua rete non c'è una chiara suddivisione logica e non sono formalizzate le regole per l'applicazione delle politiche di sicurezza per i diversi flussi di dati, significa che, quando apri l'accesso a qualcosa, dovrai affrontare questa questione e, con grande probabilità, lo farai ogni volta in modo diverso.

Spesso la segmentazione si basa solo sulle aree di sicurezza FW. Dovrai quindi rispondere alle seguenti domande:

quali aree di sicurezza ti servono
quale livello di protezione vuoi applicare a ciascuna di queste aree
il traffico intra-zona sarà autorizzato per impostazione predefinita
se no, quali politiche di filtrazione del traffico verranno applicate all'interno di ciascuna delle aree
quali politiche di filtrazione del traffico verranno applicate a ciascuna coppia di aree (sorgente/destinazione)

TCAM

Spesso si verifica il problema della mancanza di TCAM (Ternary Content Addressable Memory), sia per il routing che per gli accessi. IMHO, questo è uno dei problemi più importanti nella scelta dell'hardware, quindi è necessario affrontare questa questione con il giusto grado di attenzione.

Esempio 1. Tabella di inoltro TCAM.
Esaminiamo Palo Alto 7k firewall.
Possiamo vedere che la dimensione della tabella di inoltro IPv4* = 32K
Inoltre, questo numero di route è totale per tutti i VSYS.
Supponiamo che, secondo il vostro progetto, abbiate deciso di utilizzare 4 VSYS.
Ognuno di questi VSYS è collegato via BGP a due PE dell'infrastruttura MPLS che state utilizzando come BB. Così, 4 VSYS si scambiano tutte le route specifiche tra di loro e hanno una tabella di inoltro con insiemi di route approssimativamente uguali (ma con NH diversi). Poiché ogni VSYS ha 2 sessioni BGP (con impostazioni identiche), ogni route ricevuta tramite MPLS ha 2 NH e, di conseguenza, 2 registrazioni FIB nella Tabella di Inoltro. Se si suppone che questo sia l'unico firewall nel data center e che debba conoscere tutte le route, questo significherebbe che il numero totale di route nel nostro data center non può superare 32K/(4 * 2) = 4K.
Ora, supponiamo di avere 2 data center (con lo stesso design) e vogliamo utilizzare VLAN “estese” tra i data center (ad esempio, per vMotion), per risolvere il problema del routing dobbiamo utilizzare route host. Ma questo significa che nei 2 data center avremo non più di 4096 host possibili e, naturalmente, questo potrebbe non essere sufficiente.

Esempio 2. TCAM ACL.
Se intendete filtrare il traffico sui commutatori L3 (o su altre soluzioni che utilizzano commutatori L3, ad esempio, Cisco ACI), dovete prestare attenzione a TCAM ACL nella scelta dell'hardware.
Supponiamo di voler controllare gli accessi sugli interfaccia SVI dei Cisco Catalyst 4500. Allora, come si può vedere da di questo articolo,, per controllare il traffico in uscita (così come quello in ingresso) sulle interfacce potete utilizzare solo 4096 righe TCAM. Questo, utilizzando TCAM3, vi darà circa 4000 ACE (righe ACL).

Nel caso in cui si verifichi un problema di insufficienza di TCAM, prima di tutto è necessario considerare l'ottimizzazione. Ad esempio, in caso di problemi con la dimensione della Forwarding Table, si dovrebbe valutare la possibilità di aggregare i percorsi. Se ci sono problemi con la dimensione del TCAM per gli accessi, è necessario effettuare un audit degli accessi, rimuovere le voci obsolescenti e sovrapposte e forse rivedere la procedura di apertura degli accessi (questo sarà trattato in dettaglio nel capitolo dedicato all'audit degli accessi).

Alta Disponibilità

La domanda è: utilizzare l'HA per i firewall oppure installare due apparecchiature indipendenti 'in parallelo' e, nel caso di un guasto di una di esse, reindirizzare il traffico attraverso la seconda?

A prima vista, la risposta è ovvia: utilizzare l'HA. Il motivo per cui questa domanda emerge è che, sfortunatamente, il teorico e pubblicizzato 99 e qualche cifra dopo la virgola di percentuale di disponibilità nella pratica si rivela ben lontano dall'essere così ideale. L'HA è un concetto logicamente piuttosto complesso e su diverse attrezzature e con diversi vendor (senza eccezioni) abbiamo riscontrato problemi, bug e interruzioni del servizio.

Utilizzando l'HA, avrai la possibilità di spegnere nodi singoli e passare tra di essi senza interrompere il servizio, il che è importante, ad esempio, durante gli aggiornamenti, ma hai una probabilità tutt'altro che nulla che entrambe le nodi si guastino contemporaneamente, così come il fatto che un ulteriore aggiornamento potrebbe non procedere così agevolmente come promesso dal fornitore (questo problema può essere evitato se hai la possibilità di testare l'aggiornamento su attrezzature di laboratorio).

Se non utilizzi l'HA, dal punto di vista di una rottura doppia, i tuoi rischi sono notevolmente inferiori (poiché hai 2 firewall indipendenti), ma poiché le sessioni non sono sincronizzate, ogni volta che c'è un passaggio tra questi firewall perderai traffico. Certo, si può utilizzare il firewalling stateless, ma in tal caso il senso dell'uso del firewall si perde in gran parte.

Pertanto, se a seguito dell'audit hai scoperto firewall isolati e stai pensando di aumentare l'affidabilità della tua rete, l'HA è sicuramente una delle soluzioni raccomandate, ma devi anche considerare i contro legati a questo approccio e, forse, per la tua rete un'altra soluzione potrebbe essere più adatta.

Facilità di gestione (managability)

In linea di principio, l'HA riguarda anche la gestibilità. Invece di configurare 2 box separatamente e risolvere il problema della sincronizzazione delle configurazioni, le gestisci in gran parte come se avessi un unico dispositivo.

Ma, forse, hai molti data center e molti firewall, allora questa questione si pone a un nuovo livello. E la questione non riguarda solo la configurazione, ma anche