Quando il modulo conntrack di iptable tiene traccia degli stati dei pacchetti?

Soluzione 1:

Presentazione introduttiva di Netfilter e conntrack

Prima lo schema obbligatorio sul flusso di pacchetti in Netfilter e reti generali:

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 della scatola dai 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 è abbastanza sfocato. Puoi semplicemente considerare conntrack come parte integrante di Netfilter.

Nello schema che descrive i vari passaggi attraversati da un pacchetto puoi 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 viene dichiarato UNTRACKED nella tabella grezza), una nuova tupla bidirezionale di conntrack voce (protocollo, quindi informazioni specifiche sulla famiglia e sul protocollo:sorgente iniziale e porta, destinazione iniziale e porta, sorgente e porta della risposta, destinazione e porta della risposta (queste ultime due sono in genere opposte, a meno che non siano coinvolti NAT o qualche strano protocollo, come echo reply matching echo request for 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:passaggio da NEW a ESTABLISHED se prima non era così).
• se per qualche motivo specifico il pacchetto non può corrispondere a un flusso esistente nonostante ne abbia le caratteristiche (es:un pacchetto TCP in ritardo ricevuto dopo una ritrasmissione già avviata con successo, quindi essere fuori finestra per quanto riguarda la sequenza e il SACK valori) il pacchetto verrà etichettato come INVALID.
• ci sono alcuni altri casi come RELATED:si tratta di pacchetti non parte del flusso stesso ma relativi a un nuovo flusso che può essere associato a un altro flusso esistente (ad esempio:nel database). Due esempi sono un errore ICMP creato dalla ricezione di un pacchetto (es:porta UDP irraggiungibile) o quando uno speciale helper del protocollo come il modulo del kernel nf_conntrack_ftp , che è un plugin per conntrack sottosistema, rileva che un pacchetto fa parte del flusso di dati separato associato ai comandi FTP PASV/EPSV o PORT/EPRT eseguiti sul flusso di comandi (sulla porta 21).

Rispondere alla domanda

Detto questo, ecco le risposte ai tuoi due punti:

• nello spazio dei nomi di rete principale conntrack inizia a tracciare le connessioni non appena i suoi moduli (inclusi eventuali sottomoduli specifici del protocollo pertinenti) vengono caricati. Per gli spazi dei nomi di rete non iniziali (contenitori...) ciò richiede anche che qualche altro sottosistema vi faccia riferimento (come iptables dell'OP conntrack di o usando una volta il comando conntrack descritto in seguito). Questa è l'impostazione predefinita e un pacchetto deve essere specificamente contrassegnato come UNTRACKED prima il conntrack subsystem vede che questo pacchetto non deve essere tracciato. Su Linux ci sono solo pochi casi in cui non sarebbe necessario il tracciamento, ma ovviamente il firewall stateful e il NAT stateful/dinamico non saranno più disponibili (il NAT steless che potrebbe anche richiedere l'uso di UNTRACKED in primo luogo, può ancora essere done, ma non con iptables . tc o nftables Potere). Per evitare conntrack gestire alcuni pacchetti, questo tipo di iptables può essere utilizzata la regola (es: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 filter/INPUT e raggiunge questa regola:

   iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
  

  Gli iptables modulo kernel specifico di xt_conntrack interroga il conntrack sottosistema (gestito dai vari moduli del kernel rilevanti nf_conntrack* ) e chiede informazioni sullo stato di questo pacchetto nel suo database di ricerca. Se la risposta è RELATED o ESTABLISHED il pacchetto corrisponde e procede al verdetto di ACCETTAZIONE. In realtà il risultato è già memorizzato nella cache nel pacchetto la prima volta che è stata eseguita la ricerca (di solito da conntrack ) quindi questa è una "ricerca" economica. Si tratta quindi di una regola generica per gestire flussi già accettati in precedenza. Questi flussi possono essere inizialmente accettati nelle regole che menzionano esplicitamente -m conntrack --ctstate NEW o semplicemente regole che non lo menzionano ma poste dopo questa regola generica (ma tieni presente lo stato INVALID, che di solito dovrebbe essere DROPATO prima di farlo).

• aggiungendo un punto:la gestione dei pacchetti in entrata e in uscita è abbastanza simmetrica tra PREROUTING e OUTPUT (anche se non sembrano simmetrici):conntrack interfacce in PREROUTING così come in OUTPUT (e in pochi altri posti, considerando NAT funziona con conntrack , ad eccezione del suo primo pacchetto nello stato NEW che attraversa iptables 's nat tavolo). 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 ha bisogno dello stesso iptables generico regola sia in filtro/OUTPUT che in filtro/INPUT, per consentire il passaggio dei pacchetti di risposta in uscita del traffico in entrata già accettato.

Informazioni aggiuntive

Esistono strumenti dedicati per interagire con conntrack tabelle di ricerca del sottosistema da conntrack-tools.

• conntrack :per interrogare, eliminare o aggiornare il contenuto delle tabelle di ricerca gestite da conntrack .

  Alcuni esempi.

  Puoi elencare tutte le voci tracciate (che possono essere grandi senza filtri aggiuntivi) con:

  conntrack -L
  

  Se il tuo sistema sta eseguendo NAT (ad es. un router davanti a una LAN privata o esegue VM e container) puoi usare --any-nat , --src-nat o --dst-nat per visualizzare solo risp. tutti i NAT, tutti i NAT di origine (masquerade) o tutti i NAT di destinazione (in genere per le porte inoltrate):

  Monitoraggio in tempo reale di conntrack eventi:

  conntrack -E
  

• conntrackd :un demone i cui due scopi principali sono (conntrack) la contabilità e le statistiche del flusso o la sincronizzazione dello stato del cluster del firewall stateful ad alta disponibilità.

Soluzione 2:

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 tracciamento delle connessioni o creano nuove voci di tracciamento delle connessioni 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 net.netfilter.nf_conntrack sysctl.

La tua seconda alternativa è cosa succede. Le informazioni sullo stato vengono registrate dalla funzione Conntrack e la regola IPTables consulta semplicemente la tabella Conntrack per informazioni.