Quando il modulo conntrack di iptable tiene traccia degli stati dei pacchetti?
Per prima cosa deve memorizzare gli stati. Con qualche vecchio firewall BSD che ho usato, immagino fosse chiamato IPFW, ho usato per mettere una regola che saziava "tenere traccia dello stato del pacchetto in partenza", e questo è stato posto nella direzione in uscita delle interfacce. Quindi, un'altra regola sulla direzione in entrata che li confrontava con quegli stati che erano stati creati dalla regola nella direzione in uscita. Quindi c'erano 2 regole: (1) per popolare la tabella degli stati, questa era nella direzione in uscita e (2) per cercare la tabella degli stati, questa era nella direzione in entrata.
Ma con connntrack, lo vedo applicato alla catena INPUT, come questa regola:
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
Questo mi fa chiedere, cosa sta effettivamente facendo quella dichiarazione?
- Sta dicendo che inizierà a tracciare i pacchetti che corrispondono a quella regola inserendo le loro informazioni nella tabella degli stati?
- O sta dicendo che dispone già delle informazioni sugli stati e agirà contro i messaggi in entrata basati su di esse? (es. accettare se appartenevano a una connessione precedentemente accettata?). Ma, in questo caso, dove è stata popolata la tabella degli stati? Quale regola fa? O è senza regole e implicito?
Risposte
Presentazione introduttiva di Netfilter e conntrack
Prima lo schema obbligatorio sul flusso di pacchetti in Netfilter e General Networking:

Netfilter è il framework di filtraggio dei pacchetti che si inserisce nel resto dello stack di rete (rappresentato dalla "decisione di instradamento" e da altre parti bianche con bordi arrotondati). Netfilter fornisce hook e API per altri sottosistemi e "client". Tra queste parti ci sono conntrack (il tracker di connessione) e iptables (o nftables ). La separazione tra Netfilter e conntrack è piuttosto confusa . Puoi semplicemente considerare conntrack come parte integrante di Netfilter.
Nello schema che descrive i vari passaggi attraversati da un pacchetto si può vedere che a un certo punto (tra raw / PREROUTING e mangle / PREROUTING, o tra raw / OUTPUT e mangle / OUTPUT) il pacchetto attraversa conntrack .
A questo punto, conntrack cercherà nelle proprie tabelle di ricerca (un mini database di ricerca conservato nella memoria del kernel):
- se le caratteristiche di questo pacchetto non vengono trovate (e se non dichiarate UNTRACKED nella tabella grezza), una nuova voce di tupla bidirezionale conntrack (protocollo, quindi informazioni specifiche sulla famiglia e sul protocollo: sorgente e porta iniziali, destinazione e porta iniziali, sorgente e porta di risposta destinazione della risposta e porta (quelle ultime due sono solitamente inverse, a meno che non siano coinvolti NAT o alcuni protocolli strani, come la risposta echo che corrisponde alla richiesta echo per ICMP)) che descrive il flusso viene creato con lo stato NEW.
- se corrisponde (in qualsiasi direzione) a una voce precedente ed è compatibile con lo stato di questo flusso, lo stato del flusso potrebbe essere alterato (ad esempio: passare da NEW a ESTABLISHED se non era il caso prima).
- se per qualche motivo specifico il pacchetto non può corrispondere a un flusso esistente nonostante abbia le sue caratteristiche (es: un pacchetto TCP in ritardo ricevuto dopo una ritrasmissione già avviata con successo, quindi essere fuori dalla finestra per quanto riguarda la sequenza e i valori SACK) il il pacchetto verrà contrassegnato come INVALID.
- ci sono alcuni altri casi come RELATED: si tratta di pacchetti che non fanno parte del flusso stesso ma relativi a un nuovo flusso che può essere associato ad un altro flusso esistente (es .: nel database). Due esempi sono un errore ICMP creato dalla ricezione di un pacchetto (es: porta UDP non raggiungibile) o quando uno speciale helper di protocollo come il modulo del kernel
nf_conntrack_ftp
, che è un plugin per il sottosistema conntrack , rileva che un pacchetto fa parte del flusso di dati separato associato con i comandi FTP PASV / EPSV o PORT / EPRT eseguiti sul flusso di comandi (sulla porta 21).
Affrontare la domanda
Detto questo, ecco le risposte ai tuoi due proiettili:
nello spazio dei nomi della rete principale conntrack inizia a tracciare le connessioni non appena i suoi moduli (inclusi eventuali sotto-moduli specifici del protocollo) vengono caricati. Per gli spazi dei nomi di rete non iniziali (contenitori ...) questo richiede anche che qualche altro sottosistema faccia riferimento ad esso (come il modulo conntrack iptables di OP o usando una volta il comando
conntrack
descritto più avanti). Questa è l'impostazione predefinita e un pacchetto deve essere specificamente contrassegnato come UNTRACKED prima che il sottosistema conntrack lo veda affinché questo pacchetto non venga tracciato. Su Linux ci sono solo pochi casi in cui non sarebbe necessario il tracciamento, ma ovviamente il firewall con stato e il NAT con stato / dinamico non saranno più disponibili (NAT steless che potrebbe anche richiedere di utilizzare UNTRACKED in primo luogo, può ancora essere fatto, ma non con iptables . tc o nftables possono). Per evitare che conntrack gestisca alcuni pacchetti, è possibile utilizzare questo tipo di regola iptables (ad esempio: porta 80 / tcp):iptables -t raw -A PREROUTING -p tcp --dport 80 -j CT --notrack iptables -t raw -A OUTPUT -p tcp --sport 80 -j CT --notrack
Quando il pacchetto attraversa il filtro / INPUT e raggiunge questa regola:
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
Il modulo del kernel specifico di iptables
xt_conntrack
interroga il sottosistema conntrack (gestito dai vari moduli del kernel rilevantinf_conntrack*
) e chiede lo stato di questo pacchetto nel suo database di ricerca. Se la risposta èRELATED
oESTABLISHED
il pacchetto corrisponde e si procede al verdetto ACCETTO. In realtà il risultato è già memorizzato nella cache del pacchetto la prima volta che è stata eseguita la ricerca (di solito da conntrack ) quindi questa è una "ricerca" economica. Questa è quindi una regola generica per gestire flussi già accettati in precedenza. Questi flussi possono essere inizialmente accettati in regole che menzionano esplicitamente-m conntrack --ctstate NEW
o semplicemente regole che non lo menzionano ma posizionati dopo questa regola generica (ma tieni presente lo stato INVALID, che di solito dovrebbe essere DROPed prima di farlo).aggiungendo un punto elenco: la gestione dei pacchetti in entrata e in uscita è abbastanza simmetrica tra PREROUTING e OUTPUT (anche se quelli non sembrano simmetrici): le interfacce conntrack in PREROUTING così come in OUTPUT (e in pochi altri posti, considerando che NAT è lavorando con conntrack , eccetto per il suo primo pacchetto nello stato NEW che attraversa la tabella nat di iptables ). Questo potrebbe essere leggermente diverso dalla descrizione che hai scritto su IPFW. Se un server che esegue applicazioni limita anche i flussi in uscita, molto probabilmente necessita della stessa regola iptables generica sia in filter / OUTPUT che in filter / INPUT, per consentire il passaggio dei pacchetti di risposta in uscita del traffico in entrata già accettato.
Informazioni aggiuntive
Ci sono strumenti dedicati per interagire con le tabelle di ricerca del sottosistema conntrack da conntrack-tools .
conntrack: per interrogare, cancellare o aggiornare il contenuto delle tabelle di ricerca gestite da conntrack .
Qualche esempio.
Puoi elencare tutte le voci tracciate (che possono essere grandi senza filtri aggiuntivi) con:
conntrack -L
Se il tuo sistema sta facendo NAT (es. Un router davanti a una LAN privata, o esegue VM e container) puoi usare
--any-nat
,--src-nat
o--dst-nat
solo per visualizzare resp. tutto NAT, tutto NAT di origine (mascherato) o tutto NAT di destinazione (in genere per le porte inoltrate):Monitoraggio in tempo reale degli eventi conntrack :
conntrack -E
conntrackd: un daemon i cui due scopi principali sono la contabilità e le statistiche del flusso (conntrack) o la sincronizzazione dello stato del cluster del firewall con stato ad alta disponibilità .
Il monitoraggio della connessione è una funzione separata di Netfilter e non è configurato con IPTables.

Nell'immagine ci sono due conntrack
passaggi nel percorso INPUT e uno nel percorso OUTPUT. Questi passaggi associano i singoli pacchetti alle connessioni esistenti tracciate nella tabella di tracciabilità della connessione o creano nuove voci di tracciabilità della connessione nella tabella.
La funzionalità Conntrack è un modulo del kernel Linux ed è spesso inclusa nel kernel nella configurazione predefinita.
Il funzionamento di Conntrack può essere regolato regolando i net.netfilter.nf_conntrack
valori di sysctl.
La tua seconda alternativa è ciò che accade. Le informazioni sullo stato vengono registrate dalla funzione Conntrack e la regola IPTables consulta semplicemente la tabella Conntrack per informazioni.