Cercando di adattare il firewall centralizzato alla topologia di rete


11

Sto superando la nostra rete, il problema a cui continuo a tornare è: cercare di portare il livello 3 al core, pur avendo un firewall centralizzato.

Il problema principale che ho qui è che gli switch "mini core" che ho visto hanno sempre limiti ACL nell'hardware bassi, che anche alle nostre dimensioni attuali potremmo colpire rapidamente. Attualmente sto per (eventualmente) acquistare un paio di EX4300-32F per il core, ma ho esaminato altri modelli e altre opzioni della gamma ICX di Juniper e Brocade. Sembrano tutti avere gli stessi limiti ACL bassi.

Questo ha perfettamente senso in quanto gli switch core devono essere in grado di mantenere il routing della velocità del filo, quindi non voler sacrificare troppo attraverso l'elaborazione ACL. Quindi non posso eseguire da solo tutti i miei firewall sui core switch.

Tuttavia, realizziamo principalmente server completamente gestiti e avere un firewall centralizzato (con stato) aiuta molto con quella gestione, poiché non possiamo avere clienti che parlano direttamente tra loro. Vorrei mantenerlo in questo modo, se possibile, ma penso che la maggior parte delle reti ISP non farebbe questo genere di cose, quindi perché nella maggior parte dei casi sarebbe semplice fare il routing nel core.

Per riferimento, ecco la topologia che mi piacerebbe idealmente fare (ma non sono sicuro di dove adattare il FW ovviamente).

Rete

Soluzione Curente

In questo momento, abbiamo una configurazione router-on-a-stick. Questo ci consente di eseguire NAT, firewall stateful e routing VLAN in un unico punto. Molto semplice.

Potrei continuare con (approssimativamente) la stessa soluzione estendendo L2 fino alla "cima" della nostra rete: i router di frontiera. Ma poi perdo tutti i vantaggi del routing wire-speed che il core può offrirmi.

IIRC gli switch core possono fare 464 Gbps di routing mentre i miei router di frontiera saranno in grado di offrire forse 10 o 20 Gbps se sono fortunato. Questo non è tecnicamente un problema in questo momento, ma piuttosto un problema di crescita. Mi sento come se non progettassimo l'architettura per sfruttare la capacità di routing di base ora, sarà doloroso ripetere tutto quando saremo più grandi e dovremo sfruttare quella capacità. Preferirei farlo bene la prima volta.

Possibili soluzioni

Livello 3 per accedere

Ho pensato che forse avrei potuto estendere L3 agli switch di accesso, e quindi suddividere le regole del firewall in segmenti più piccoli che si sarebbero adattati ai limiti hardware degli ACL degli switch di accesso. Ma:

  • Per quanto ne so, questi non sarebbero ACL con stato
  • L3 to Access, per me, sembra molto più flessibile. Gli spostamenti del server o le migrazioni della VM verso altri cabinet sarebbero più dolorosi.
  • Se gestirò un firewall nella parte superiore di ogni rack (solo sei di essi), probabilmente voglio comunque l'automazione. Quindi a quel punto non è un gran salto automatizzare la gestione dei firewall a livello di host. Evitando così l'intero problema.

Firewall a ponte / trasparenti su ogni uplink tra access / core

Ciò dovrebbe comportare più box firewall e aumentare significativamente l'hardware richiesto. E potrebbe finire per essere più costoso rispetto all'acquisto di router core più grandi, anche usando semplici vecchi box Linux come firewall.

Router core giganti

Potrei acquistare un dispositivo più grande che può fare il firewall di cui ho bisogno e ha una capacità di routing molto più grande. Ma davvero non ho il budget per questo, e se sto cercando di fare un dispositivo fare qualcosa per cui non è progettato, probabilmente dovrò andare a una specifica molto più alta. di quanto avrei altrimenti.

Nessun firewall centralizzato

Dal momento che sto saltando attraverso i cerchi, forse questo non vale la pena. È sempre stata una buona cosa avere, e talvolta un punto di forza per i clienti che desiderano un firewall "hardware".

Ma sembra che avere un firewall centralizzato per la tua "intera" rete sia impossibile. Mi chiedo, quindi, quanto ISP più grandi possono offrire soluzioni firewall hardware ai clienti con server dedicati, quando hanno centinaia o addirittura migliaia di host?

Qualcuno può pensare a un modo di risolvere questo problema? O qualcosa che mi è sfuggito del tutto o una variazione di una delle idee sopra?

AGGIORNAMENTO 2014-06-16:

Sulla base del suggerimento di @ Ron, mi sono imbattuto in questo articolo che spiega abbastanza bene il problema che sto affrontando e un buon modo per risolvere il problema.

A meno che non ci siano altri suggerimenti, direi che questo è ora un tipo di problema relativo alla raccomandazione di un prodotto, quindi suppongo che sia la fine.

http://it20.info/2011/03/the-93-000-firewall-rules-problem-and-why-cloud-is-not-just-orchestration/


Stai utilizzando VRF-Lite o MPLS nella rete? Di che marca sono gli switch core?
Daniel Dib,

@DanielDib Non sto ancora utilizzando VRF o MPLS, ma sto programmando di distribuirlo tra questo sito e un altro sito. Il marchio non è ancora definitivo (sto ancora scoprendo la lista degli acquisti) ... Ma in questo momento guardiamo principalmente Juniper EX4300-32F o Brocade ICX 6610-48-PE
Geekman

1
Ho votato per chiudere; Il motivo è che la domanda che stai ponendo approfondisce dettagli molto specifici per la tua soluzione come quale marca / modello del fornitore scegliere e vincoli di bilancio ecc., Come ciò cambierà l'offerta di prodotti per i tuoi clienti ... Tutto ciò non è adatto qui , quelle sono decisioni aziendali. Puoi chiedere quali sono i pro e i contro di ogni topologia, ma nessuno può davvero dirti cosa è meglio per te.
jwbensley,

1
Il mio due pence sulla tua situazione è; Hai preso in considerazione i firewall che supportano contesti come Cisco ASAs o che hanno anche solo i firewall virtuali? Avere alcuni host di macchine virtuali su cui è possibile attivare i firewall per ciascun cliente con due interfacce, una che si inserisce nella VLAN del cliente come gateway predefinito e l'altra che si inserisce in una VLAN pubblica rivolta verso i router periferici. Solo un pensiero (preferisco i firewall virtuali).
jwbensley,

2
Guarderei seriamente i firewall virtualizzati come Cisco ASA 1000V o Catbird (catbird.com). In questo modo, puoi posizionare un firewall su ogni server virtuale. Tieni gli elenchi di accesso lontani dal router principale.
Ron Trunk,

Risposte:


5

Sceglierei una delle due scelte:

Firewall virtuali per singolo tenant

Professionisti:

  • Scalabile orizzontalmente
  • Spin-up e spin-down
  • Relativamente immune alle future modifiche di topologia / progettazione
  • Completa separazione / isolamento del cliente

Contro:

  • A meno che non imposti un modello standard, ora hai n singoli firewall da gestire
  • Ora hai n singoli firewall da monitorare
  • Ora hai n singoli firewall da patchare

Chassis / cluster firewall di grandi dimensioni con istanza / contesto di routing per tenant

Distribuisci un grande firewall centrale (cluster) che pende dal lato del tuo core e usa un'istanza di instradamento interna ed esterna per instradare il traffico sopra e indietro (ad es .: gateway predefinito su Istanza interna è il firewall, gateway predefinito su il firewall è l'istanza esterna sul core e il valore predefinito per l'istanza esterna sono i bordi.)

Professionisti:

  • Casella singola da gestire e configurare
  • Scatola singola da monitorare
  • Scatola singola da applicare
  • Separazione del cliente

Contro:

  • Il costo del primo giorno sarà maggiore
  • Nessun ridimensionamento
  • A seconda della configurazione, il traffico tra clienti potrebbe iniziare il routing attraverso i router di frontiera

0

Quali core switch stai utilizzando? Le politiche vengono generalmente eseguite a livello di distribuzione, se si utilizza un design Core compresso, il core dovrebbe essere in grado di gestire le proprie esigenze. Inoltre, ti piace l'ispezione statefull o solo acls. Se hai qualche conformità che devi seguire, acls potrebbe non essere sufficiente.

Personalmente, andrei con un firewall, forse ne cerco uno che può essere raggruppato in modo da poterli raggruppare insieme e mantenere una base di regole gestita centralmente, come un firewall di origine incendio.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.