Questo articolo è il terzo di una serie di articoli "Come assumere il controllo della propria infrastruttura di rete". È possibile trovare il contenuto di tutti gli articoli della serie e i collegamenti .
Non ha senso parlare di eliminare completamente i rischi per la sicurezza. In linea di principio non possiamo ridurli a zero. Dobbiamo anche capire che mentre ci sforziamo di rendere la rete sempre più sicura, le nostre soluzioni stanno diventando sempre più costose. È necessario trovare un compromesso tra costo, complessità e sicurezza che abbia senso per la tua rete.
Naturalmente, la progettazione della sicurezza è organicamente integrata nell'architettura complessiva e le soluzioni di sicurezza utilizzate influiscono sulla scalabilità, affidabilità, gestibilità, ... dell'infrastruttura di rete, di cui bisogna tenere conto.
Ma lascia che ti ricordi che ora non stiamo parlando di creare una rete. Secondo il ns abbiamo già scelto il progetto, selezionato le attrezzature e creato l'infrastruttura, e in questa fase, se possibile, dovremmo “vivere” e trovare soluzioni nel contesto dell'approccio scelto in precedenza.
Il nostro compito ora è identificare i rischi associati alla sicurezza a livello di rete e ridurli a un livello ragionevole.
Controllo della sicurezza della rete
Se la tua organizzazione ha implementato i processi ISO 27k, gli audit di sicurezza e le modifiche alla rete dovrebbero integrarsi perfettamente nei processi complessivi di questo approccio. Ma questi standard non riguardano ancora soluzioni specifiche, né configurazione, né progettazione... Non ci sono consigli chiari, nessuno standard che stabilisca in dettaglio come dovrebbe essere la vostra rete, questa è la complessità e la bellezza di questo compito.
Vorrei evidenziare diversi possibili controlli di sicurezza della rete:
- audit della configurazione delle apparecchiature (hardening)
- verifica della progettazione della sicurezza
- controllo degli accessi
- verifica del processo
Audit della configurazione dell'apparecchiatura (rafforzamento)
Sembra che nella maggior parte dei casi questo sia il miglior punto di partenza per verificare e migliorare la sicurezza della tua rete. IMHO, questa è una buona dimostrazione della legge di Pareto (il 20% dello sforzo produce l'80% del risultato e il restante 80% dello sforzo produce solo il 20% del risultato).
Il punto è che di solito riceviamo consigli dai fornitori riguardo alle “migliori pratiche” per la sicurezza durante la configurazione delle apparecchiature. Questo si chiama “indurimento”.
Spesso puoi anche trovare un questionario (o crearne uno tu stesso) basato su queste raccomandazioni, che ti aiuterà a determinare quanto la configurazione della tua attrezzatura è conforme a queste "migliori pratiche" e, in base al risultato, ad apportare modifiche alla tua rete . Ciò ti consentirà di ridurre significativamente i rischi per la sicurezza in modo abbastanza semplice, praticamente a costo zero.
Diversi esempi per alcuni sistemi operativi Cisco.
Sulla base di questi documenti è possibile creare un elenco dei requisiti di configurazione per ciascun tipo di apparecchiatura. Ad esempio, per un VDC Cisco N7K potrebbero essere questi i requisiti .
In questo modo è possibile creare file di configurazione per diversi tipi di apparecchiature attive nella propria infrastruttura di rete. Successivamente, manualmente o utilizzando l'automazione, è possibile "caricare" questi file di configurazione. Come automatizzare questo processo verrà discusso in dettaglio in un'altra serie di articoli sull'orchestrazione e l'automazione.
Verifica della progettazione della sicurezza
In genere, una rete aziendale contiene i seguenti segmenti in una forma o nell'altra:
- DC (DMZ dei servizi pubblici e data center Intranet)
- Accesso ad Internet
- VPN di accesso remoto
- Bordo WAN
- Branch di società
- Campus (ufficio)
- Nucleo
Titoli tratti da modello, ma non è necessario, naturalmente, attaccarsi proprio a questi nomi e a questo modello. Tuttavia, voglio parlare dell'essenza e non impantanarmi nelle formalità.
Per ciascuno di questi segmenti, i requisiti di sicurezza, i rischi e, di conseguenza, le soluzioni saranno diversi.
Esaminiamo ciascuno di essi separatamente per i problemi che potresti incontrare dal punto di vista della progettazione della sicurezza. Naturalmente, ripeto ancora una volta, questo articolo non pretende in alcun modo di essere completo, cosa non facile (se non impossibile) da ottenere in un argomento così profondo e sfaccettato, ma riflette la mia esperienza personale.
Non esiste una soluzione perfetta (almeno non ancora). È sempre un compromesso. Ma è importante che la decisione di utilizzare un approccio o un altro sia presa consapevolmente, comprendendone sia i pro che i contro.
Banca dati
Il segmento più critico dal punto di vista della sicurezza.
E, come al solito, anche qui non esiste una soluzione universale. Tutto dipende fortemente dai requisiti di rete.
È necessario un firewall oppure no?
Sembrerebbe che la risposta sia ovvia, ma non tutto è così chiaro come potrebbe sembrare. E la tua scelta può essere influenzata non solo prezzo.
Esempio 1. Ritardi.
Se tra alcuni segmenti di rete è necessaria una bassa latenza, come ad esempio nel caso di uno scambio, allora non potremo utilizzare firewall tra questi segmenti. È difficile trovare studi sulla latenza nei firewall, ma pochi modelli di switch possono fornire una latenza inferiore o dell'ordine di 1 mksec, quindi penso che se i microsecondi sono importanti per te, allora i firewall non fanno per te.
Esempio 2. Prestazioni.
Il throughput dei migliori switch L3 è solitamente un ordine di grandezza superiore al throughput dei firewall più potenti. Pertanto, in caso di traffico ad alta intensità, molto probabilmente dovrai anche consentire a questo traffico di aggirare i firewall.
Esempio 3. Affidabilità.
I firewall, in particolare i moderni NGFW (Next-Generation FW), sono dispositivi complessi. Sono molto più complessi degli interruttori L3/L2. Forniscono un gran numero di servizi e opzioni di configurazione, quindi non sorprende che la loro affidabilità sia molto inferiore. Se la continuità del servizio è fondamentale per la rete, potrebbe essere necessario scegliere cosa porterà a una migliore disponibilità: la sicurezza con un firewall o la semplicità di una rete costruita su switch (o vari tipi di strutture) che utilizzano ACL regolari.
Nel caso degli esempi precedenti, molto probabilmente (come al solito) dovrai trovare un compromesso. Guarda alle seguenti soluzioni:
- se si decide di non utilizzare firewall all'interno del data center, è necessario pensare a come limitare il più possibile l'accesso attorno al perimetro. Ad esempio, puoi aprire solo le porte necessarie da Internet (per il traffico client) e l'accesso amministrativo al data center solo dagli host jump. Sugli host jump, eseguire tutti i controlli necessari (autenticazione/autorizzazione, antivirus, logging, ...)
- è possibile utilizzare una partizione logica della rete del data center in segmenti, simile allo schema descritto in PSEFABRIC . In questo caso il routing deve essere configurato in modo tale che il traffico sensibile al ritardo o ad alta intensità vada "all'interno" di un segmento (nel caso di p002, VRF) e non passi attraverso il firewall. Il traffico tra i diversi segmenti continuerà a passare attraverso il firewall. È inoltre possibile utilizzare il route leaking tra VRF per evitare di reindirizzare il traffico attraverso il firewall
- È possibile utilizzare un firewall anche in modalità trasparente e solo per quelle VLAN dove questi fattori (latenza/prestazioni) non sono significativi. Ma è necessario studiare attentamente le restrizioni associate all'uso di questa mod per ciascun fornitore
- potresti prendere in considerazione l'utilizzo di un'architettura di catena di servizi. Ciò consentirà solo al traffico necessario di passare attraverso il firewall. Sembra carino in teoria, ma non ho mai visto questa soluzione in produzione. Abbiamo testato la catena di servizi per Cisco ACI/Juniper SRX/F5 LTM circa 3 anni fa, ma a quel tempo questa soluzione ci sembrava “grezza”.
Livello di protezione
Ora devi rispondere alla domanda su quali strumenti desideri utilizzare per filtrare il traffico. Ecco alcune delle funzionalità solitamente presenti in NGFW (ad esempio, ):
- firewall con stato (impostazione predefinita)
- firewall dell'applicazione
- prevenzione delle minacce (antivirus, anti-spyware e vulnerabilità)
- Filtro URL
- filtraggio dei dati (filtraggio dei contenuti)
- blocco dei file (blocco dei tipi di file)
- protezione
E non tutto è nemmeno chiaro. Sembrerebbe che maggiore è il livello di protezione, meglio è. Ma devi considerare anche questo
- Naturalmente, più si utilizzano le funzioni firewall sopra indicate, più costoso sarà (licenze, moduli aggiuntivi)
- l'uso di alcuni algoritmi può ridurre significativamente il throughput del firewall e anche aumentare i ritardi, vedere ad esempio
- come ogni soluzione complessa, l'uso di metodi di protezione complessi può ridurre l'affidabilità della soluzione, ad esempio, quando si utilizza il firewall dell'applicazione, ho riscontrato il blocco di alcune applicazioni funzionanti abbastanza standard (dns, smb)
Come sempre, devi trovare la soluzione migliore per la tua rete.
È impossibile rispondere in modo definitivo alla domanda su quali funzioni di protezione possano essere necessarie. In primo luogo, perché ovviamente dipende dai dati che stai trasmettendo o archiviando e cercando di proteggere. In secondo luogo, in realtà, spesso la scelta degli strumenti di sicurezza è una questione di 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 quella di utilizzare le offerte di diverse aziende. Ad esempio, puoi abilitare l'antivirus sul firewall, ma anche utilizzare la protezione antivirus (di un altro produttore) localmente sugli host.
Segmentazione
Stiamo parlando della segmentazione logica della rete del data center. Ad esempio, anche la suddivisione in VLAN e sottoreti è una segmentazione logica, ma non la prenderemo in considerazione per la sua ovvietà. Interessante segmentazione che tiene conto di entità come zone di sicurezza FW, VRF (e loro analoghi in relazione a vari fornitori), dispositivi logici (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...
Viene fornito un esempio di tale segmentazione logica e della progettazione del data center attualmente richiesta .
Dopo aver definito le parti logiche della tua rete, puoi quindi descrivere come il traffico si sposta tra i diversi segmenti, su quali dispositivi verrà eseguito il filtraggio e con quali mezzi.
Se la tua rete non ha una partizione logica chiara e le regole per applicare le politiche di sicurezza per i diversi flussi di dati non sono formalizzate, ciò significa che quando apri questo o quell'accesso, sei costretto a risolvere questo problema, e con un'alta probabilità tu lo risolverà ogni volta in modo diverso.
Spesso la segmentazione si basa solo sulle zone di sicurezza del FW. Successivamente è necessario rispondere alle seguenti domande:
- di quali zone di sicurezza hai bisogno
- quale livello di protezione vuoi applicare a ciascuna di queste zone
- il traffico intrazona sarà consentito per impostazione predefinita?
- in caso contrario, quali politiche di filtraggio del traffico verranno applicate all'interno di ciascuna zona
- quali politiche di filtraggio del traffico verranno applicate per ciascuna coppia di zone (sorgente/destinazione)
TCAM
Un problema comune è l'insufficienza del TCAM (Ternary Content Addressable Memory), sia per l'instradamento che per gli accessi. IMHO, questo è uno dei problemi più importanti nella scelta dell'attrezzatura, quindi è necessario trattare questo problema con il grado di cura appropriato.
Esempio 1. Tabella di inoltro TCAM.
Diamo un'occhiata firewall
Vediamo che la dimensione della tabella di inoltro IPv4* = 32K
Inoltre, questo numero di percorsi è comune a tutti i VSYS.Supponiamo che in base al tuo progetto decidi di utilizzare 4 VSYS.
Ciascuno di questi VSYS è connesso tramite BGP a due PE MPLS del cloud che utilizzi come BB. Pertanto, 4 VSYS scambiano tra loro tutti i percorsi specifici e hanno una tabella di inoltro con approssimativamente gli stessi insiemi di percorsi (ma NH diversi). Perché ogni VSYS ha 2 sessioni BGP (con le stesse impostazioni), quindi ogni percorso ricevuto tramite MPLS ha 2 NH e, di conseguenza, 2 voci FIB nella tabella di inoltro. Se presupponiamo che questo sia l'unico firewall nel data center e debba conoscere tutti i percorsi, ciò significherà che il numero totale di percorsi nel nostro data center non può essere superiore a 32K/(4 * 2) = 4K.Ora, se assumiamo di avere 2 data center (con lo stesso design) e vogliamo utilizzare VLAN “allungate” tra data center (ad esempio per vMotion), allora per risolvere il problema del routing, dobbiamo utilizzare i percorsi host . Ma questo significa che per 2 data center non avremo più di 4096 host possibili e, ovviamente, questo potrebbe non bastare.
Esempio 2. TCAM ACL.
Se prevedi di filtrare il traffico sugli switch L3 (o altre soluzioni che utilizzano switch L3, ad esempio Cisco ACI), quando scegli l'attrezzatura dovresti prestare attenzione all'ACL TCAM.
Supponiamo di voler controllare gli accessi sulle interfacce SVI del Cisco Catalyst 4500. Allora, come si può vedere da , per controllare il traffico in uscita (così come quello in entrata) sulle interfacce, è possibile utilizzare solo 4096 linee TCAM. Che quando si utilizza TCAM3 ti darà circa 4000mila ACE (linee ACL).
Se ti trovi di fronte al problema di un TCAM insufficiente, allora, prima di tutto, ovviamente, devi considerare la possibilità di ottimizzazione. Quindi, in caso di problemi con la dimensione della tabella di inoltro, è necessario considerare la possibilità di aggregare i percorsi. In caso di problemi con le dimensioni del TCAM per gli accessi, verificare gli accessi, rimuovere i record obsoleti e sovrapposti ed eventualmente rivedere la procedura per l'apertura degli accessi (sarà discusso in dettaglio nel capitolo sul controllo degli accessi).
Alta disponibilità
La domanda è: dovrei usare l'HA per i firewall o installare due box indipendenti “in parallelo” e, se uno di essi fallisce, instradare il traffico attraverso il secondo?
Sembrerebbe che la risposta sia ovvia: usa HA. Il motivo per cui questa domanda si pone ancora è che, sfortunatamente, le percentuali teoriche e pubblicitarie di accessibilità, 99 e diversi decimali, nella pratica si rivelano tutt'altro che rosee. L'HA è logicamente una cosa piuttosto complessa e su apparecchiature diverse e con fornitori diversi (non c'erano eccezioni), abbiamo riscontrato problemi, bug e interruzioni del servizio.
Se utilizzi HA, avrai la possibilità di disattivare i singoli nodi, passare da uno all'altro senza interrompere il servizio, il che è importante, ad esempio, quando si effettuano aggiornamenti, ma allo stesso tempo hai una probabilità lontana da zero che entrambi i nodi si romperà allo stesso tempo, e anche che l'aggiornamento successivo non andrà liscio come promesso dal venditore (questo problema può essere evitato se si ha l'opportunità di testare l'aggiornamento su apparecchiature di laboratorio).
Se non usi l'HA, dal punto di vista del doppio fallimento i tuoi rischi sono molto più bassi (poiché hai 2 firewall indipendenti), ma poiché... le sessioni non sono sincronizzate, quindi ogni volta che passi da un firewall all'altro perderai traffico. Ovviamente è possibile utilizzare il firewall stateless, ma in questo caso si perde in gran parte lo scopo dell'utilizzo di un firewall.
Pertanto, se a seguito dell'audit hai scoperto firewall solitari e stai pensando di aumentare l'affidabilità della tua rete, allora l'HA, ovviamente, è una delle soluzioni consigliate, ma dovresti anche tenere conto degli svantaggi associati con questo approccio e, forse, specifico per la tua rete, un'altra soluzione sarebbe più adatta.
Gestibilità
In linea di principio, l’HA riguarda anche la controllabilità. Invece di configurare 2 dispositivi separatamente e affrontare il problema di mantenere sincronizzate le configurazioni, le gestisci come se avessi un unico dispositivo.
Ma forse hai molti data center e molti firewall, quindi questa domanda si pone a un nuovo livello. E la domanda non riguarda solo la configurazione, ma anche
- configurazioni di backup
- aggiornamenti
- aggiornamenti
- monitoraggio
- registrazione
E tutto questo può essere risolto mediante sistemi di gestione centralizzata.
Quindi, ad esempio, se stai utilizzando i firewall di Palo Alto, allora è una soluzione del genere.
Per essere continuato.
Fonte: habr.com