NEW di conntrack su un pacchetto ACK: cosa non dimostra

Nel log del firewall c’è una riga che non ti aspettavi: un pacchetto ACK, stato conntrack NEW, un indirizzo di origine che non è il tuo, porta di destinazione aperta. La tentazione è leggerla come una nuova connessione in ingresso che nessuno ha autorizzato. Quello che la riga dice davvero è più stretto: quando quel pacchetto ha raggiunto questo hook, il tracker non aveva uno stato corrispondente, e il pacchetto portava un ACK. Sono due fatti su due cose diverse, e nessuno dei due è la trascrizione completa di una stretta di mano. Questo è l’ordine che seguo prima di trarre una conclusione.

Parti dal pacchetto, non dal verdetto

Separa le osservazioni prima di interpretarle. I flag TCP descrivono questo pacchetto, lo stato del tracker descrive ciò che sapeva a quell’hook, e la tua cattura descrive solo la finestra che hai registrato.

Confondere queste tre cose è come un ACK diventa «il fornitore ha fatto entrare qualcuno».

Cosa significa davvero NEW all’hook

La corrispondenza conntrack di iptables documenta NEW come un pacchetto che avvia una connessione, o uno associato a una connessione che non ha ancora visto traffico in entrambe le direzioni. ESTABLISHED significa che il tracker ha visto pacchetti in entrambe le direzioni. Nessuna delle due definizioni dice che il pacchetto fosse un SYN, né che sia arrivato senza cronologia.

Un tracker che inizia a osservare un flusso a metà classifica il pacchetto successivo in base a ciò che sa, e questo può essere nulla. È un’affermazione sulla memoria del tracker, non sull’intenzione dell’host remoto.

Il tracciamento lasco spiega la maggior parte delle sorprese con ACK

Il kernel documenta nf_conntrack_tcp_loose, che consente al tracker di rilevare connessioni TCP di cui non ha visto l’inizio. Con l’impostazione al valore predefinito, un ACK a metà flusso può essere adottato come flusso stabilito. Disattivala e lo stesso pacchetto sarà più probabilmente classificato come INVALID invece che NEW. Entrambi gli esiti descrivono le regole del tracker, non la cronologia dell’applicazione.

Quindi controlla quell’impostazione prima di costruire una teoria sull’etichetta.

Escludi le cause noiose in questo ordine

La maggior parte degli eventi NEW su ACK che ho inseguito è finita in una di queste, e tutte sono economiche da verificare:

• La tabella conntrack è stata svuotata, o il tracker è stato riavviato.
• L’host è stato riavviato, o il flusso si è spostato su un altro namespace o dispositivo.
• L’instradamento asimmetrico ha fatto uscire il SYN da un percorso che non stai catturando.
• NAT ha riscritto la tupla, quindi la voce non corrisponde più a ciò che hai letto.
• La cattura è iniziata tardi e non ha mai visto l’inizio.

Ognuna di queste rimuove i pacchetti precedenti dalla vista del tracker lasciando intatti i successivi. Un riavvio o uno svuotamento della tabella è il più facile da confermare con l’uptime e i log. L’instradamento asimmetrico si vede come una cattura unidirezionale. NAT è il più subdolo, perché la tupla che il tracker ha salvato non è quella stampata nel log.

Annota quali di queste hai escluso, e come, prima di andare avanti.

Leggi la tupla, l’interfaccia e l’hook

Una voce conntrack è indicizzata per indirizzi, porte e protocollo, quindi qualsiasi traduzione cambia quale voce corrisponde. Annota anche l’interfaccia e l’hook, perché un pacchetto visto sull’interfaccia sbagliata o dopo una catena diversa ti dice che il percorso non è quello del diagramma. Quando l’evento riguarda una VPN, decidi se stai guardando il pacchetto interno o il portatore esterno. Poi confronta con ciò che il gateway ha registrato per la stessa tupla a cinque elementi.

Due viste di uno stesso flusso che non concordano sono più informative di ciascuna da sola.

Quando vale la pena escalare

Escala quando puoi mostrare un servizio raggiungibile che non dovrebbe esserlo, con il flusso, la politica che lo ha consentito e prove da entrambe le estremità. Non segnalare un difetto del fornitore sulla base di una sola etichetta di stato o di una cattura parziale, perché quella segnalazione verrà chiusa con la spiegazione che hai appena letto. Se il servizio è davvero esposto, il proprietario di quel confine è la persona giusta per correggerlo, e una mappatura delle porte delegata o un ascoltatore involontario è una causa più probabile di un bug.

Poi chiudi la lacuna di visibilità che ha lasciato che un pacchetto sembrasse un’intera sessione.