🥇Quando il Linux conntrack non è più il tuo alleato

Il tracciamento delle connessioni (“conntrack”) è una funzione fondamentale dello stack di rete del kernel Linux. Questo permette al kernel di monitorare tutte le connessioni di rete logiche o i flussi, identificando tutti i pacchetti che compongono ogni flusso, in modo che possano essere elaborati insieme in modo sequenziale.

Conntrack è una funzione importante del kernel, utilizzata in alcuni scenari chiave:

Il NAT si basa sulle informazioni fornite da conntrack, permettendo di gestire in modo uniforme tutti i pacchetti di un flusso. Ad esempio, quando un pod accede a un service Kubernetes, il bilanciatore di carico kube-proxy utilizza il NAT per indirizzare il traffico verso un pod specifico all'interno del cluster. Conntrack registra che per una connessione specifica, tutti i pacchetti destinati all'IP del service devono essere inviati allo stesso pod, e che i pacchetti restituiti dal pod backend devono essere inoltrati dal NAT nuovamente al pod da cui è arrivata la richiesta.
I firewall con tracciamento dello stato, come Calico, si basano sulle informazioni di conntrack per aggiungere il traffico “rispondente” alla whitelist. Questo ti consente di scrivere una politica di rete che dice: «permetti al mio pod di connettersi a qualsiasi IP remoto» senza dover scrivere una politica per autorizzare esplicitamente il traffico di risposta. (Senza questo, dovresti aggiungere una regola molto meno sicura che dice «permettere i pacchetti nel mio pod da qualsiasi IP».)

Inoltre, conntrack generalmente migliora le prestazioni del sistema (riducendo il tempo di CPU e la latenza dei pacchetti), poiché solo il primo pacchetto in un flusso
deve passare attraverso l'intero stack di rete per determinare cosa farne. Vedi il post “Confronto delle modalità di kube-proxy” per vedere un esempio di come funziona.

Tuttavia, conntrack ha le sue limitazioni…

Allora, dove è andato tutto storto?

La tabella conntrack ha una dimensione massima configurabile e, se si riempie, le connessioni iniziano solitamente a essere rifiutate o interrotte. Per gestire il traffico della maggior parte delle applicazioni, ci sono solitamente abbastanza spazi liberi nella tabella, e questo non diventa mai un problema. Tuttavia, ci sono alcuni scenari in cui vale la pena considerare l'uso della tabella conntrack:

Il caso più evidente è se il tuo server gestisce un numero straordinariamente elevato di connessioni attive contemporaneamente. Ad esempio, se la tua tabella conntrack è impostata su 128k record, ma hai > 128k connessioni simultanee, sicuramente incontrerai un problema!
Un caso meno ovvio è se il tuo server gestisce un numero molto elevato di connessioni al secondo. Anche se le connessioni sono brevi, continuano a essere tracciate da Linux per un certo periodo di tempo (di default 120s). Ad esempio, se la tua tabella conntrack è impostata su 128 mila record e stai tentando di gestire 1100 connessioni al secondo, esse supereranno la dimensione della tabella conntrack, anche se le connessioni sono molto effimere (128k / 120s = 1092 connessioni / s).

Ci sono diversi tipi di applicazioni di nicchia che rientrano in queste categorie. Inoltre, se hai molti antagonisti, riempire la tabella conntrack del tuo server con molte connessioni semi-aperto può essere utilizzato in un attacco di tipo "denial of service" (DOS). In entrambi i casi, conntrack può diventare un collo di bottiglia nel tuo sistema. In alcuni casi, modificare i parametri della tabella conntrack può essere sufficiente per soddisfare le tue esigenze — aumentando la dimensione o riducendo i timeout di conntrack (ma se lo fai in modo errato, incontrerai grandi difficoltà). Per altri casi sarà necessario bypassare conntrack per il traffico aggressivo.

Un esempio reale

Prendiamo un esempio concreto: un grande fornitore SaaS con cui abbiamo lavorato aveva una serie di server memcached su host (non macchine virtuali), ognuno dei quali gestiva oltre 50K connessioni brevi al secondo.

Hanno sperimentato con la configurazione di conntrack, aumentando le dimensioni delle tabelle e riducendo il tempo di tracciamento, ma la configurazione era inaffidabile, il consumo di RAM è aumentato notevolmente, il che era un problema (nell'ordine dei GB!), e le connessioni erano così brevi che conntrack non produceva il suo consueto guadagno nelle performance (riduzione dell'uso della CPU o dei ritardi nei pacchetti).

Come alternativa, si sono rivolti a Calico. Le policy di rete di Calico consentono di non utilizzare conntrack per determinati tipi di traffico (utilizzando l'opzione doNotTrack per le policy). Questo ha fornito loro il livello di prestazioni necessario, oltre a un ulteriore livello di sicurezza fornito da Calico.

A cosa si deve rinunciare per bypassare conntrack?

Le policy di rete do-not-track di solito devono essere simmetriche. Nel caso di un fornitore SaaS: le loro applicazioni operavano all'interno di una zona protetta e quindi, tramite la policy di rete, potevano mettere in whitelist il traffico di altre applicazioni specifiche a cui era consentito l'accesso a memcached.
La policy do-not-track non considera la direzione della connessione. Pertanto, nel caso di un attacco a un server memcached, si potrebbe teoricamente tentare di connettersi a uno qualsiasi dei client memcached, se utilizza la porta sorgente corretta. Tuttavia, se hai definito correttamente la policy di rete per i tuoi client memcached, questi tentativi di connessione verranno comunque rifiutati dal lato client.
La policy do-not-track si applica a ogni pacchetto, a differenza delle normali policy che si applicano solo al primo pacchetto di un flusso. Questo potrebbe aumentare l'uso delle risorse CPU per ogni pacchetto, poiché è necessario applicare la policy per ogni pacchetto. Ma per connessioni di breve durata, questo costo viene bilanciato dalla riduzione delle risorse necessarie per gestire conntrack. Ad esempio, nel caso di un fornitore SaaS, il numero di pacchetti per ogni connessione era molto ridotto, quindi l'ulteriore costo delle risorse CPU per applicare le policy a ogni pacchetto era giustificato.

Iniziamo i test

Abbiamo effettuato un test su un pod con un server memcached e numerosi pod client memcached, eseguiti su nodi remoti, in modo da poter avviare un numero molto elevato di connessioni al secondo. Il server con il pod del server memcached aveva 8 core e 512k voci nella tabella conntrack (dimensione standard configurata per l'host).
Abbiamo misurato la differenza di prestazioni tra: senza policy di rete; con una policy Calico normale; e con la policy Calico do-not-track.

Per il primo test, abbiamo impostato il numero di connessioni fino a 4.000 al secondo, quindi abbiamo potuto concentrarci sulla differenza di consumo della CPU. Non ci sono state sostanziali differenze tra l'assenza di politiche e la politica ordinaria, ma la politica do-not-track ha aumentato il consumo della CPU di circa il 20%:

Nel secondo test, abbiamo avviato il numero massimo di connessioni che i nostri clienti potevano generare e abbiamo misurato il numero massimo di connessioni al secondo che il nostro server memcached poteva gestire. Come previsto, nel caso di "senza politiche" e "politica ordinaria" entrambi hanno raggiunto il limite conntrack di oltre 4.000 connessioni al secondo (512k / 120s = 4.369 connessioni/s). Con la politica do-not-track, i nostri clienti hanno inviato 60.000 connessioni al secondo senza alcun problema. Siamo certi che avremmo potuto aumentare questo numero collegando un numero maggiore di clienti, ma riteniamo che queste cifre siano già sufficienti per illustrare il messaggio di questo articolo!

Conclusione

Il conntrack è una funzione importante del kernel. Fa egregiamente il suo lavoro. Spesso viene utilizzato da componenti chiave del sistema. Tuttavia, in alcuni scenari specifici, il sovraccarico dovuto al conntrack supera i benefici normali che offre. In questo scenario, le politiche di rete di Calico possono essere utilizzate per disabilitare selettivamente l'uso del conntrack aumentando nel contempo il livello di sicurezza della rete. Per tutto il resto del traffico, il conntrack continua a essere il tuo alleato!