L'aritmetica della state table: dimensionare un firewall per i flood, non per le medie

Chiedete alla maggior parte delle persone quanto grande debba essere un firewall e vi risponderanno in banda. Sotto attacco, la banda è raramente ciò che finisce per primo. Finisce la state table: l'elenco delle connessioni che il firewall sta tracciando, che ha una dimensione fissa, si riempie al ritmo con cui arrivano le nuove connessioni, e si svuota solo alla velocità consentita dai timeout. Capite quell'aritmetica e potrete dimensionare un firewall per il giorno in cui conta invece che per il giorno medio.

Perché lo stato finisce prima della banda

Quando la tabella è piena, le nuove connessioni vengono scartate, legittime o no, anche se i link sono quasi inattivi.

Due tipi di traffico riempiono una tabella in fretta:

• SYN flood. Ogni SYN con sorgente falsificata crea una voce half-open che non si completerà mai.
• UDP verso servizi pubblici. DNS, NTP, server di gioco, VoIP e servizi simili vedono un numero enorme di scambi brevi da molte sorgenti, e ciascuno può creare una propria voce.

L'aritmetica

Il numero di voci a regime in una tabella è, con buona approssimazione:

entries = new flows per second x seconds each entry lives

È la legge di Little, ed è tutto il gioco. Supponete che un flood arrivi a 50.000 nuovi SYN al secondo, e che le voci TCP half-open vivano 30 secondi. La tabella ha bisogno di 1.500.000 voci solo per l'attacco, prima che arrivi un singolo utente reale. Tagliate quel timeout a 5 secondi durante il flood e lo stesso attacco ne richiede 250.000. Stesso firewall, stessa memoria, una differenza di sei volte fatta da un solo timer.

Quindi ci sono solo tre leve: una tabella più grande (memoria), vite più brevi (timeout), e meno voci per flusso (non tracciare affatto lo stato dove non serve). Usatele tutte e tre.

Leva uno: dimensionate la tabella di proposito

Calcolate quanta memoria la piattaforma alloca per voce di stato, decidete quanta della RAM del firewall siete disposti a dare allo stato, e impostate il massimo a partire da lì, invece di convivere con un default scelto per un piccolo ufficio. Poi allertate ben prima che la tabella sia piena.

Su OPNsense e sui firewall basati su pf i numeri in tempo reale sono a un comando di distanza:

pfctl -si | grep -A4 "State Table"
pfctl -sm | grep states

Leva due: timeout adattivi e SYN cookie

I timeout statici sono un compromesso tra l'essere gentili con i client lenti e il sopravvivere a un flood. I timeout adattivi eliminano il compromesso: man mano che la tabella si riempie oltre una soglia di partenza, tutti i timeout si riducono linearmente, fino a zero a una soglia finale. Nei giorni normali i timer restano generosi; sotto pressione le voci scadono in fretta. In termini di pf:

set limit states 2000000
set timeout { adaptive.start 1200000, adaptive.end 2200000 }

Aggiungete i SYN cookie, idealmente in una modalità adattiva che si accende solo quando la tabella supera una soglia. Con i cookie, il firewall risponde a un SYN senza creare stato e costruisce una voce solo quando il client completa l'handshake, cosa che una sorgente falsificata non fa mai. Questo trasforma l'attacco più efficiente contro un firewall stateful in traffico che il firewall nota appena.

Leva tre: non tracciate ciò che non ha bisogno di essere tracciato

Per i servizi UDP ad alto volume, tracciare ogni scambio non compra quasi nulla: il servizio risponde da una porta nota, e le regole sono semplici. Una coppia di regole stateless (permetti in ingresso verso la porta del servizio, permetti in uscita da essa) non crea alcuna voce, quindi un flood UDP non può esaurire la tabella per conto di un server DNS o NTP. Mantenete la gestione stateful per il TCP e per tutto ciò in cui il traffico di ritorno deve essere strettamente legato a una richiesta in uscita.

Mantenete lo stato attraverso un guasto

Il dimensionamento è metà del lavoro; l'altra metà è non perderlo tutto quando un nodo si guasta. In una coppia attivo e standby, CARP sposta gli indirizzi virtuali sullo standby, e pfsync replica la state table tra i nodi di continuo, su un link dedicato dove possibile. Quando il nodo attivo muore, lo standby conosce già ogni connessione established, così le sessioni continuano invece di far riconnettere ogni utente. Testatelo: avviate un download lungo o una sessione SSH attraverso la coppia, spegnete il nodo attivo e guardatela proseguire.

Due abitudini pratiche aiutano. Applicate le modifiche di tuning prima allo standby, verificate, poi fate il failover e modificate l'altro nodo; e distribuite l'elaborazione dei pacchetti sui core della CPU con un numero di thread adatto a ogni appliance, così un singolo core occupato non diventa il vero limite.

Ordinate il ruleset per decisioni economiche

Un flood costa meno se scartato presto. Mettete per prime le decisioni grossolane ed economiche: una block list combinata di threat intelligence, poi i blocchi per paese, poi i range di hosting noti per abusi, e solo allora le regole di permesso per host. Date a ogni alias e regola il nome dell'host che protegge, così il ruleset si documenta da solo e le regole vecchie si possono rimuovere con sicurezza.

Controllate il vostro firewall

• Qual è il limite della state table, e qual è il picco di oggi in percentuale di quel limite?
• C'è un allarme ben sotto il limite?
• I timeout adattivi sono configurati, e i SYN cookie sono disponibili sotto carico?
• I servizi UDP ad alto volume sono gestiti in modo stateless?
• In una coppia HA, lo stato è sincronizzato, e avete testato un failover con sessioni attive?
• Sapete cosa farebbe alla tabella un attacco a dieci volte il vostro ritmo normale di connessioni? Fate la moltiplicazione.

I nostri firewall perimetrali ad Atene girano come coppie stateful costruite e tarate così, modificate solo attraverso la loro API. Se volete aiuto per fare l'aritmetica sul vostro, siamo lieti di sederci con voi.

Parla con un ingegnere

Related (rows[1])

Correlati: Firewall perimetrali gestiti · Come cambiamo le cose: disciplina delle modifiche di rete · Monitoraggio della rete ed evidenze