Questo articolo è il terzo di una serie di articoli "Come prendere il controllo della tua infrastruttura di rete". Puoi trovare il contenuto di tutti gli articoli della serie e i link. qui.

Non ha senso parlare di una completa eliminazione dei rischi di sicurezza. In linea di principio, non possiamo ridurli a zero. Inoltre, è necessario comprendere che, nel tentativo di rendere la rete sempre più sicura, le nostre soluzioni diventano sempre più costose. È necessario trovare un compromesso ragionevole tra prezzo, complessità e sicurezza per la tua rete.

Ovviamente, il design della sicurezza è organicamente integrato nell'architettura generale e le soluzioni di sicurezza utilizzate influenzano la scalabilità, l'affidabilità, la gestibilità, ... della tua infrastruttura di rete, che deve essere presa in considerazione.

Ma, ricordo che ora non stiamo parlando della creazione di una rete. In conformità con i nostri requisiti iniziali abbiamo già scelto il design, l'hardware è stato selezionato e l'infrastruttura è stata creata; a questo punto dobbiamo, per quanto possibile, "vivere" e trovare soluzioni nel contesto dell'approccio precedentemente deciso.

Il nostro compito ora è identificare i rischi legati alla sicurezza a livello di rete e ridurli a un livello ragionevole.

Audit della sicurezza della rete

Se nella tua organizzazione sono stati implementati processi ISO 27k, l'audit di sicurezza e le modifiche alla rete devono essere organicamente integrati nei processi generali di questo approccio. Tuttavia, queste norme non riguardano specifiche soluzioni, configurazioni o design... Non ci sono consigli univoci, né standard che dictano in dettaglio come deve essere la tua rete, in questo sta la complessità e la bellezza di questa sfida.

Vorrei evidenziare alcuni possibili audit della sicurezza della rete:

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

Audit della configurazione hardware (hardening)

Sembra che, nella maggior parte dei casi, questo sia il miglior punto di partenza per l'audit e il miglioramento della sicurezza della tua rete. IMHO, è una buona dimostrazione della legge di Pareto (il 20% dello sforzo produce l'80% del risultato, mentre il restante 80% dello sforzo offre solo il 20% del risultato).

La sostanza è che di solito abbiamo raccomandazioni dai fornitori riguardo alle "best practices" di sicurezza durante la configurazione dell'hardware. Questo è chiamato "hardening".

Spesso si può anche trovare un questionario (o crearne uno da soli) basato su queste raccomandazioni, che ti aiuterà a determinare quanto la configurazione del tuo hardware soddisfi queste "best practices" e, in base ai risultati, apportare modifiche alla tua rete. Questo ti permetterà di ridurre in modo significativo i rischi per la sicurezza, in modo relativamente facile e senza costi.

Alcuni esempi per alcuni sistemi operativi Cisco.
Cisco IOS Configuration Hardening
Cisco IOS-XR Configuration Hardening
Cisco NX-OS Configuration Hardening
Cisco Baseline Security Check List
Sulla base di questi documenti può essere creato un elenco di requisiti per la configurazione di ciascun tipo di hardware. Ad esempio, per il Cisco N7K VDC, questi requisiti possono essere: così.

In questo modo possono essere creati file di configurazione per diversi tipi di hardware attivo nella tua infrastruttura di rete. Successivamente, manualmente o utilizzando l'automazione, puoi "caricare" questi file di configurazione. Come automatizzare questo processo sarà trattato più dettagliatamente in un'altra serie di articoli dedicati all'orchestrazione e all'automazione.

Audit del design della sicurezza

Di solito nella rete di un'azienda (enterprise network) sono presenti, in un modo o nell'altro, i seguenti segmenti:

DC (Servizi pubblici DMZ e data center intranet)
Accesso a Internet
Remote access VPN
WAN edge
Filiale
Campus (Office)
Core

I nomi sono tratti da Cisco SAFE un modello, ma non è necessario legarsi necessariamente a questi nomi e a questo modello. Vogliamo parlare dell'essenza e non perderci nelle formalità.

Per ciascuno di questi segmenti, i requisiti per il livello di sicurezza, i rischi e, di conseguenza, le soluzioni differiranno.

Esamineremo ciascuno di essi singolarmente per rilevare i problemi che potresti incontrare dal punto di vista del design della sicurezza. Certo, ripeto, che nemmeno questa articolo pretenda di essere esaustivo; raggiungere la completezza in questo tema veramente profondo e sfaccettato è difficile (se non impossibile), ma rispecchia la mia esperienza personale.

Non esiste una soluzione ideale (almeno per ora). Si tratta sempre di un compromesso. Ma è importante che la decisione di applicare un determinato approccio venga presa consapevolmente, con comprensione sia dei suoi vantaggi che dei suoi svantaggi.

Centro dati

Segmento più critico dal punto di vista della sicurezza.
E, come al solito, qui non esiste una soluzione universale. Tutto dipende fortemente dai requisiti della rete.

Serve o meno un firewall?

Sembrerebbe che la risposta sia ovvia, ma non è affatto così chiaro come potrebbe sembrare. E la tua scelta può essere influenzata non solo da il prezzo.

Esempio 1. Ritardi.
Se tra alcuni segmenti della rete la latenza bassa è un requisito fondamentale, come ad esempio nel caso di una borsa, allora tra questi segmenti non possiamo utilizzare i firewall. È difficile trovare studi sulla latenza nei firewall, ma solo pochissimi modelli di switch possono fornire latenze inferiori o dell'ordine di 1 microsecondo, quindi penso che se i microsecondi sono importanti per te, i firewall non fanno per te.

Esempio 2. Prestazioni.
La larghezza di banda dei migliori switch L3 è solitamente di un ordine superiore rispetto alla larghezza di banda dei firewall più performanti. Quindi, in caso di traffico ad alta intensità, dovrai probabilmente bypassare i firewall.

Esempio 3. Affidabilità.
I firewall, in particolare i moderni NGFW (Next-Generation FW), sono dispositivi complessi. Sono significativamente più complessi degli switch L3/L2. Offrono una grande quantità di servizi e opzioni di configurazione, quindi non sorprende che la loro affidabilità sia significativamente più bassa. Se la continuità del servizio è critica per la rete, dovrai probabilmente scegliere cosa garantisce una migliore disponibilità: la protezione tramite firewall o la semplicità di una rete basata su switch (o vari tipi di fabric) utilizzando normali ACL.

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

se hai deciso di non utilizzare firewall all'interno del data center, devi pianificare come limitare al massimo gli accessi perimetrali. Ad esempio, puoi aprire solo le porte necessarie da Internet (per il traffico dei clienti) e concedere accesso amministrativo al data center solo da host di salto. Su questi host di salto, esegui 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 caso, il routing deve essere configurato in modo che il traffico sensibile alla latenza o il traffico ad alta intensità circoli "internamente" a un segmento (nel caso di p002, del VRF) e non attraversi il firewall. Il traffico tra segmenti differenti continuerà comunque ad essere instradato attraverso il firewall. È inoltre possibile utilizzare il route leaking tra i VRF per evitare il reindirizzamento del traffico attraverso il firewall.
è anche possibile utilizzare il firewall in modalità trasparente e solo per quelle VLAN in cui questi fattori (latenza/performance) non sono significativi. Ma è necessario esaminare attentamente le limitazioni associate all'uso di questa modalità per ogni fornitore.
puoi considerare l'applicazione di un'architettura di service chain. Questo permetterà di instradare attraverso il firewall solo il traffico necessario. Teoricamente suona bene, 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 sembrava "grezza".

Livello di protezione

Ora bisogna rispondere alla domanda su quali strumenti desideri applicare per filtrare il traffico. Ecco alcune delle funzionalità che sono solitamente presenti nei NGFW (ad esempio, qui):

firewalling stateful (di default)
firewalling applicativo
prevenzione dalle minacce (antivirus, anti-spyware e vulnerabilità)
filtraggio URL
filtraggio dati (filtraggio dei contenuti)
blocco file (blocco dei tipi di file)
protezione dos

E anche non è tutto così chiaro. Sembrerebbe che più alto è il livello di protezione, meglio è. Ma devi anche considerare che

più funzionalità del firewall sopra elencate utilizzi, naturalmente sarà più costoso (licenze, moduli aggiuntivi).
l'uso di alcuni algoritmi può ridurre significativamente la larghezza di banda del firewall e aumentare anche la latenza, vedi ad esempio qui
come qualsiasi soluzione complessa, l'utilizzo di metodi di protezione complessi può ridurre l'affidabilità della tua soluzione, ad esempio, utilizzando il firewalling a livello di applicazione ho riscontrato il blocco di alcune applicazioni che funzionano normalmente (dns, smb).

Come al solito, devi trovare la soluzione ottimale per la tua rete.

Non è possibile rispondere in modo univoco alla domanda quali funzioni di protezione potrebbero essere necessarie. Innanzitutto, perché chiaramente dipende dai dati che stai trasmettendo o memorizzando e 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 in modo completo.

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

Segmentazione

Si tratta di 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 la sua ovvietà. È interessante la segmentazione tenendo conto di entità come le zone 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 attualmente richiesto del data center è riportato in p002 del progetto PSEFABRIC.

Dopo aver definito le parti logiche della tua rete, puoi descrivere come si muove il traffico tra i diversi segmenti, su quali dispositivi avverrà la filtrazione e con quali mezzi.

Se non c'è una chiara suddivisione logica nella tua rete e non sono formalizzate le regole di applicazione delle politiche di sicurezza per i diversi flussi di dati, significa che quando si apre un certo accesso ti trovi a dover affrontare questa questione, e con grande probabilità ogni volta la risolverai in modo diverso.

Spesso la segmentazione si basa solo sulle zone di sicurezza FW. Quindi devi rispondere alle seguenti domande:

quali zone di sicurezza ti servono
quale livello di protezione desideri applicare a ciascuna di queste zone
il traffico intra-zone sarà consentito per impostazione predefinita
se no, quali politiche di filtrazione del traffico saranno applicate all'interno di ciascuna delle zone
quali politiche di filtrazione del traffico saranno applicate per ogni coppia di zone (source/destination)

TCAM

Spesso si riscontra il problema della TCAM (Ternary Content Addressable Memory) insufficiente, sia per la routizzazione che per gli accessi. IMHO, questo è uno dei problemi più importanti nella scelta dell'hardware, quindi bisogna trattarlo con la dovuta cautela.

Esempio 1. TCAM della Forwarding Table.
Consideriamo Palo Alto 7k firewall.
Vediamo che la dimensione della forwarding table IPv4* = 32K
Questo numero di rotte è totale per tutti i VSYS.
Supponiamo che secondo il tuo design tu abbia deciso di utilizzare 4 VSYS.
Ognuno di questi VSYS è collegato tramite BGP a due PE della rete MPLS che stai utilizzando come BB. Pertanto, i 4 VSYS si scambiano tutte le rotte specifiche tra di loro e hanno una forwarding table con set di rotte approssimativamente identici (ma con NH diversi). Poiché ogni VSYS ha 2 sessioni BGP (con impostazioni identiche), ogni rotta ricevuta tramite MPLS ha 2 NH e, di conseguenza, 2 registrazioni FIB nella Forwarding Table. Se si suppone che questo sia l'unico firewall nel data center e debba conoscere tutte le rotte, significa che il numero totale di rotte nel nostro data center non può superare 32K/(4 * 2) = 4K.
Ora, se 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 della routizzazione dobbiamo utilizzare rotte host. Ma questo significa che nei 2 data center avremo non più di 4096 possibili host e, naturalmente, potrebbe non essere sufficiente.

Esempio 2. TCAM ACL.
Se intendi filtrare il traffico sui commutatori L3 (o altre soluzioni che utilizzano commutatori L3, ad esempio, Cisco ACI), nella scelta dell'hardware devi prestare attenzione alla TCAM ACL.
Supponiamo che tu voglia controllare gli accessi sugli SVI interface Cisco Catalyst 4500. Allora, come si può vedere da di questo articolo, per il controllo del traffico in uscita (così come di quello in entrata) sulle interfacce puoi utilizzare solo 4096 righe di TCAM. Ciò, utilizzando il TCAM3, ti darà circa 4000 righe ACE (righe ACL).

Nel caso tu abbia incontrato il problema di TCAM insufficiente, la prima cosa da considerare è certamente l'ottimizzazione. Ad esempio, nel caso di problemi con le dimensioni della Forwarding Table, dovresti considerare l'aggregazione delle rotte. In caso di problemi con le dimensioni della TCAM per gli accessi, l'audit degli accessi, la rimozione delle registrazioni obsolete e sovrapposte, oltre a riesaminare la procedura di apertura degli accessi (che sarà trattata dettagliatamente nel capitolo dedicato all'audit degli accessi).

High Availability

La questione è se utilizzare HA per i firewall o installare due unità indipendenti "in parallelo" e nell'eventualità di un guasto di una di esse instradare il traffico attraverso l'altra?

A prima vista, la risposta sembra ovvia – utilizzare HA. La ragione per cui questa questione è comunque sollevata è che, purtroppo, le teoriche e pubblicitarie percentuali di disponibilità del 99 e qualche numero decimale si rivelano nella pratica ben diverse. L'HA è una cosa logicamente abbastanza complessa e su diverse attrezzature, e con diversi fornitori (non ci sono state 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. Tuttavia, c'è una probabilità non trascurabile che entrambi i nodi si guastino contemporaneamente, oltre al rischio che l'aggiornamento non proceda così senza intoppi 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 un guasto doppio, i tuoi rischi sono significativamente inferiori (poiché hai 2 firewall indipendenti), ma poiché le sessioni non sono sincronizzate, ogni volta che si verifica un passaggio tra questi firewall perderai traffico. Certo, puoi usare un firewall stateless, ma in tal caso il senso di utilizzare un firewall viene in gran parte meno.

Pertanto, se a seguito di un audit scopri firewall isolati e stai pensando di aumentare l'affidabilità della tua rete, l'HA è certamente una delle soluzioni raccomandate, ma dovresti anche considerare gli svantaggi associati a questo approccio e, forse, per la tua rete, sarà più appropriata un'altra soluzione.

Facilità di gestione (managability)

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

Ma, se hai molti data center e molti firewall, questa questione si pone su un altro piano. E la questione non riguarda solo la configurazione, ma anche