Conntrack NEW na ACK paketu: co to neprokazuje

V logu firewallu je jeden řádek, který jste nečekali: ACK paket, stav conntrack NEW, zdrojová adresa, která není vaše, cílový port otevřený. Pokušení je číst to jako nové příchozí spojení, které nikdo neschválil. Co řádek skutečně říká, je užší: když tento paket dorazil na tento hook, tracker neměl žádný odpovídající stav a paket nesl ACK. To jsou dvě fakta o dvou různých věcech a ani jedno z nich není úplný záznam handshaku. Toto je pořadí, kterým procházím, než udělám závěr.

Začněte paketem, ne verdiktem

Oddělte pozorování, než je začnete vykládat. Příznaky TCP popisují tento paket, stav trackeru popisuje, co věděl na tomto hooku, a váš záznam popisuje jen okno, které jste zachytili.

Smícháním těchto tří věcí se z ACK stane „poskytovatel někoho pustil dovnitř“.

Co NEW na hooku skutečně znamená

párování conntrack v iptables dokumentuje NEW jako paket, který začíná spojení, nebo paket spojený se spojením, které ještě nevidělo provoz v obou směrech. ESTABLISHED znamená, že tracker viděl pakety v obou směrech. Žádná z definic neříká, že paket byl SYN, ani že dorazil bez historie.

Tracker, který začne sledovat tok uprostřed, klasifikuje další paket podle toho, co zná, a to může být nic. To vypovídá o paměti trackeru, ne o záměru vzdáleného hostitele.

Volné sledování vysvětluje většinu překvapení s ACK

Jádro dokumentuje nf_conntrack_tcp_loose, což trackeru umožňuje převzít TCP spojení, u kterých neviděl začátek. Při výchozím nastavení může být ACK z prostředku toku přijat jako navázaný tok. Vypněte to a stejný paket bude pravděpodobněji klasifikován jako INVALID místo NEW. Oba výsledky popisují pravidla trackeru, ne historii aplikace.

Proto to nastavení zkontrolujte dřív, než na nálepce postavíte teorii.

Vylučte nudné příčiny v tomto pořadí

Většina událostí NEW na ACK, které jsem sledoval, skončila u jedné z těchto a všechny se dají levně ověřit:

• Tabulka conntrack byla vyčištěna nebo byl tracker restartován.
• Hostitel se restartoval nebo se tok přesunul do jiného namespace či zařízení.
• Asymetrické směrování poslalo SYN cestou, kterou nezachytáváte.
• NAT přepsal tuple, takže záznam už neodpovídá tomu, co jste přečetli.
• Zachytávání začalo pozdě a začátek nikdy nevidělo.

Každá z nich odstraňuje dřívější pakety z pohledu trackeru a pozdější nechává nedotčené. Restart nebo vyčištění tabulky se nejsnáze potvrdí z uptime a logů. Asymetrické směrování se projeví jako jednosměrné zachytávání. NAT je ta záludná, protože tuple, který tracker uložil, není tuple vytištěný v logu.

Než půjdete dál, zapište, které z nich jste vyloučili a jak.

Přečtěte tuple, rozhraní a hook

Záznam conntrack je klíčovaný adresami, porty a protokolem, takže každý překlad mění, který záznam odpovídá. Zaznamenejte i rozhraní a hook, protože paket viděný na špatném rozhraní nebo po jiném řetězci říká, že cesta není ta z diagramu. Když událost zahrnuje VPN, rozhodněte, zda se díváte na vnitřní paket, nebo na vnější nosič. Poté to porovnejte s tím, co brána zalogovala pro stejný pětidílný tuple.

Dva pohledy na jeden tok, které si odporují, jsou užitečnější než kterýkoli z nich samotný.

Kdy má smysl eskalovat

Eskalujte, když můžete ukázat službu, která je dostupná a neměla by být, spolu s tokem, politikou, která to povolila, a důkazy z obou stran. Nehláste závadu poskytovatele na základě jediné nálepky stavu nebo jednoho částečného zachycení, protože takové hlášení bude uzavřeno vysvětlením, které jste právě přečetli. Pokud je služba skutečně vystavená, vlastník této hranice je správná osoba, která to opraví, a delegované mapování portů nebo nechtěný posluchač je pravděpodobnější příčinou než chyba.

Poté zavřete mezeru ve viditelnosti, která dovolila, aby jeden paket vypadal jako celá relace.