NEW de conntrack en un paquet ACK: què no demostra

Al registre del tallafoc hi ha una línia que no esperaves: un paquet ACK, estat de conntrack NEW, una adreça d’origen que no és la teva, port de destinació obert. La temptació és llegir-ho com una connexió entrant nova que ningú no ha autoritzat. El que diu realment la línia és més estret: quan aquell paquet va arribar a aquest hook, el rastrejador no tenia cap estat coincident, i el paquet portava un ACK. Són dos fets sobre dues coses diferents, i cap dels dos no és una transcripció completa d’una encaixada de mans. Aquest és l’ordre que segueixo abans de treure una conclusió.

Comença pel paquet, no pel veredicte

Separa les observacions abans d’interpretar-les. Les banderes TCP descriuen aquest paquet, l’estat del rastrejador descriu què sabia en aquell hook, i la teva captura descriu només la finestra que has enregistrat.

Confondre aquestes tres coses és com un ACK es converteix en «el proveïdor ha deixat entrar algú».

Què vol dir realment NEW al hook

La concordança de conntrack d’iptables documenta NEW com un paquet que inicia una connexió, o un d’associat a una connexió que encara no ha vist trànsit en les dues direccions. ESTABLISHED vol dir que el rastrejador ha vist paquets en les dues direccions. Cap de les dues definicions no diu que el paquet fos un SYN, ni que arribés sense historial.

Un rastrejador que comença a observar un flux a mig camí classifica el paquet següent segons el que sap, que pot ser res. Això parla de la memòria del rastrejador, no de la intenció de l’amfitrió remot.

El seguiment lax explica la majoria de sorpreses amb ACK

El nucli documenta nf_conntrack_tcp_loose, que permet al rastrejador recollir connexions TCP de les quals no ha vist l’inici. Amb el paràmetre al valor per defecte, un ACK de mig flux es pot adoptar com un flux establert. Desactiva’l i el mateix paquet serà més probablement classificat com a INVALID en lloc de NEW. Tots dos resultats descriuen les regles del rastrejador, no l’historial de l’aplicació.

Per tant, comprova aquest paràmetre abans de construir una teoria sobre l’etiqueta.

Descarta les causes avorrides en aquest ordre

La majoria d’esdeveniments NEW sobre ACK que he perseguit van acabar en una d’aquestes, i totes són barates de comprovar:

• S’ha buidat la taula de conntrack, o el rastrejador s’ha reiniciat.
• L’amfitrió s’ha reiniciat, o el flux s’ha traslladat a un altre namespace o dispositiu.
• L’encaminament asimètric ha enviat el SYN per un camí que no estàs capturant.
• NAT ha reescrit la tuple, així que l’entrada ja no coincideix amb el que has llegit.
• La captura va començar tard i no va veure mai el començament.

Cadascuna d’aquestes treu els paquets anteriors de la vista del rastrejador i deixa intactes els posteriors. Un reinici o un buidatge de la taula és el més fàcil de confirmar amb l’uptime i els registres. L’encaminament asimètric es veu com una captura unidireccional. NAT és el més astut, perquè la tuple que el rastrejador ha desat no és la tuple impresa al registre.

Anota quines d’aquestes has descartat, i com, abans de continuar.

Llegeix la tuple, la interfície i el hook

Una entrada de conntrack es clau per adreces, ports i protocol, així que qualsevol traducció canvia quina entrada coincideix. Anota també la interfície i el hook, perquè un paquet vist a la interfície equivocada o després d’una cadena diferent et diu que el camí no és el del diagrama. Quan l’esdeveniment implica una VPN, decideix si mires el paquet intern o el portador extern. Després compara-ho amb el que la passarel·la ha registrat per a la mateixa tuple de cinc parts.

Dues vistes d’un sol flux que no coincideixen són més informatives que qualsevol de les dues per separat.

Quan val la pena escalar

Escala quan puguis mostrar un servei que és accessible i no hauria de ser-ho, amb el flux, la política que ho va permetre i proves d’ambdós extrems. No informis d’un defecte del proveïdor basant-te en una etiqueta d’estat o una captura parcial, perquè aquest informe es tancarà amb l’explicació que acabes de llegir. Si el servei realment està exposat, el propietari d’aquesta frontera és la persona adequada per arreglar-ho, i un mapatge de ports delegat o un oient no desitjat és una causa més probable que un error.

Després tanca la bretxa de visibilitat que va permetre que un sol paquet semblés una sessió sencera.