Off-Path firewall with Traffic Engineering

Andrea Dainese
2 Marzo 2023
Post cover

Solitamente adotto un’architettura di rete semplice per due principali motivi.

  • Sono facili da diagnosticare/risolvere
  • Gli ingegneri successivi possono facilmente comprenderle e gestirle.

Con queste regole in mente, di solito installo firewall in linea, il che significa che il traffico viene instradato attraverso un firewall posizionato “sul percorso”:

Firewall in linea (diagramma L3)

A volte le cose si complicano e dobbiamo installare firewall “fuori percorso”, e il traffico viene instradato parzialmente attraverso il firewall:

Firewall fuori percorso (diagramma L3)

Ci sono molte ragioni per voler fare ciò.

  • Vogliamo testare un nuovo firewall
  • Non abbiamo abbastanza budget per un grande firewall per gestire l’intero traffico.
  • Dobbiamo escludere alcuni tipi di traffico sensibili alla latenza.

Nel 99% degli scenari, un firewall in linea va bene; vediamo come affrontare il restante 1%.

Connessione Internet locale

Requisito #1: Dobbiamo utilizzare la connessione Internet locale se disponibile e utilizzare la rete MPLS in caso contrario.

Risolvere questo requisito è facile: dobbiamo implementare un percorso predefinito statico condizionale. Il firewall viene utilizzato solo se la connessione Internet attraverso di esso funziona.

A seconda del modello del firewall, possiamo utilizzare funzionalità native e routing dinamico per eseguire la configurazione. Tuttavia, per il bene di questo post, vogliamo risolvere il requisito agendo solo sullo switch L3.

Gli ingegneri di rete sono abituati a implementare una sonda ICMP, raggiungendo 8.8.8.8, per testare la connessione Internet. Ho letto anche documenti ufficiali che lo suggeriscono, ma è una pratica sbagliata perché Google applica limiti di frequenza:

Vogliamo implementare due sonde DNS utilizzando almeno due diversi server DNS OpenDNS.

ip sla 1
 dns www.cisco.com name-server 208.67.222.222 source-ip 192.168.1.1
 timeout 5000
 frequency 10
ip sla schedule 1 life forever start-time now
ip sla 2
 dns www.google.com name-server 208.67.220.220 source-ip 192.168.1.1
 timeout 5000
 frequency 10
ip sla schedule 2 life forever start-time now
track 1 ip sla 1 reachability
track 2 ip sla 2 reachability

I fornitori DNS possono limitare la frequenza delle richieste con tipi di record insoliti, query duplicate eccessive, record DNS eccessivi o inviate da IP client maligni per aggiungere entropia alle nostre richieste ai server dei nomi. Poiché utilizziamo una frequenza di 10 s, possiamo presumere che sia sicuro.

Dobbiamo anche accoppiare le sonde sopra usando l’operatore logico OR

track 3 list boolean or
 object 1
 object 2
 delay down 12 up 30

Per evitare flapping, abbiamo introdotto un ritardo prima di cambiare lo stato.

Infine, abbiamo configurato il percorso predefinito statico associato alla sonda.

ip route 0.0.0.0 0.0.0.0 192.168.1.254 track 3

Percorso Internet attivo e di backup (diagramma L3)

Con questa configurazione, il traffico verso Internet viene instradato attraverso il firewall se la connessione Internet tramite il firewall stesso funziona. Altrimenti, viene utilizzato il percorso predefinito dalla rete MPLS.

Attenzione deve essere posta al tempo di convergenza, specialmente quando la connessione Internet locale va giù.

Filtraggio del firewall fuori percorso

Requisito #2: Dobbiamo filtrare selettivamente alcune conversazioni di rete. Non possiamo inoltrare tutto al firewall perché non dispone di sufficiente larghezza di banda o risorse computazionali.

Risolvere questo requisito richiede PBR o routing basato su criteri. Usiamo PBR quando abbiamo bisogno di fare un’eccezione al routing normale. Vogliamo selezionare, in base al protocollo, all’indirizzo IP di origine/destinazione e alla porta, flussi di rete da instradare attraverso il firewall. Il firewall è configurato “a bastone”, il che significa che viene utilizzata un’unica interfaccia per ricevere e trasmettere il traffico di rete consentito.

Firewall fuori percorso con flussi (diagramma L3)

Dobbiamo definire il traffico di rete da filtrare utilizzando un ACL.

ip access-list extended FILTERED
 permit ip 192.168.20.0 0.0.0.255 any
 permit ip any 192.168.20.0 0.0.0.255

Dobbiamo corrispondere sia al traffico in ingresso che in uscita. Una mappa di route instrada il traffico attraverso il firewall.

route-map FILTERED permit 10
 match ip address FILTERED
 set ip next-hop verify-availability 192.168.1.254

In una configurazione firewall non ad alta disponibilità, possiamo implementare il PBR condizionale:

route-map FILTERED permit 10
 match ip address FILTERED
 set ip next-hop verify-availability 192.168.1.254 1 track 11

Infine, dobbiamo applicare la mappa di route a qualsiasi interfaccia L3, escludendo l’interfaccia dove è posizionato il firewall:

interfaccia Ethernet0/1
 ip policy route-map FILTERED
interfaccia Ethernet0/2
 ip policy route-map FILTERED

Con questa configurazione, il traffico in ingresso corrispondente alla ACL viene instradato verso il firewall.

Conclusioni

Anche in questo caso, questo design non dovrebbe essere utilizzato a meno che non esistano requisiti specifici. Tuttavia, funziona bene. Gli strumenti di automazione dovrebbero essere presi in considerazione per gestire correttamente ambienti di grandi dimensioni. Più è dipendente dall’uomo, più errori (e interruzioni) si verificheranno.