Conntrack NEW na ACK pakete: čo to nepreukazuje

V logu firewallu je jeden riadok, ktorý ste nečakali: ACK paket, stav conntrack NEW, zdrojová adresa, ktorá nie je vaša, cieľový port otvorený. Pokušenie je prečítať to ako nové prichádzajúce spojenie, ktoré nikto neschválil. Čo riadok naozaj hovorí, je užšie: keď tento paket dorazil na tento hook, tracker nemal zodpovedajúci stav a paket niesol ACK. To sú dve fakty o dvoch rôznych veciach a ani jeden nie je úplný záznam podania ruky. Toto je poradie, ktorým prechádzam, kým urobím záver.

Začnite paketom, nie verdiktom

Oddeľte pozorovania skôr, než ich začnete vykladať. Príznaky TCP opisujú tento paket, stav trackeru opisuje, čo vedel na tomto hooku, a váš záznam opisuje len okno, ktoré ste zachytili.

Zmiešanie týchto troch je spôsob, akým sa z ACK stane „poskytovateľ niekoho pustil dnu“.

Čo NEW na hooku naozaj znamená

párovanie conntrack v iptables dokumentuje NEW ako paket, ktorý začína spojenie, alebo paket spojený so spojením, ktoré ešte nevidelo prevádzku v oboch smeroch. ESTABLISHED znamená, že tracker videl pakety v oboch smeroch. Ani jedna definícia nehovorí, že paket bol SYN, ani že dorazil bez histórie.

Tracker, ktorý začne sledovať tok v strede, klasifikuje ďalší paket podľa toho, čo pozná, a to môže byť nič. To je tvrdenie o pamäti trackeru, nie o úmysle vzdialeného hostiteľa.

Voľné sledovanie vysvetľuje väčšinu prekvapení s ACK

Jadro dokumentuje nf_conntrack_tcp_loose, čo trackeru umožňuje prevziať TCP spojenia, ktorých začiatok nevidel. Pri predvolenom nastavení môže byť ACK zo stredu toku prijatý ako etablovaný tok. Vypnite ho a ten istý paket bude pravdepodobnejšie klasifikovaný ako INVALID namiesto NEW. Oba výsledky opisujú pravidlá trackeru, nie históriu aplikácie.

Preto to nastavenie skontrolujte skôr, než na štítok postavíte teóriu.

Vylúčte nudné príčiny v tomto poradí

Väčšina udalostí NEW-na-ACK, ktoré som sledoval, skončila pri jednej z týchto a všetky sa dajú lacno overiť:

• Tabuľka conntrack bola vyčistená alebo bol tracker reštartovaný.
• Hostiteľ sa reštartoval alebo sa tok presunul do iného namespace či zariadenia.
• Asymetrické smerovanie poslalo SYN cestou, ktorú nezachytávate.
• NAT prepísal tuple, takže záznam už nezodpovedá tomu, čo ste prečítali.
• Zachytávanie začalo neskoro a začiatok nikdy nevidelo.

Každá z nich odstraňuje skoršie pakety z pohľadu trackeru a neskoršie necháva nedotknuté. Reštart alebo vyčistenie tabuľky sa najľahšie potvrdí z uptime a logov. Asymetrické smerovanie sa prejaví ako jednosmerné zachytávanie. NAT je tá záludná, pretože tuple, ktorý tracker uložil, nie je tuple vytlačený v logu.

Predtým, než budete pokračovať, zapíšte, ktoré z nich ste vylúčili a ako.

Prečítajte si tuple, rozhranie a hook

Záznam conntrack je kľúčovaný adresami, portami a protokolom, takže každý preklad mení, ktorý záznam zodpovedá. Zaznamenajte aj rozhranie a hook, pretože paket videný na nesprávnom rozhraní alebo po inom reťazci hovorí, že cesta nie je tá z diagramu. Keď udalosť zahŕňa VPN, rozhodnite, či sa pozeráte na vnútorný paket alebo na vonkajší nosič. Potom to porovnajte s tým, čo brána zalogovala pre rovnaký päťdielny tuple.

Dva protichodné pohľady na jeden tok sú užitočnejšie než ktorýkoľvek z nich samotný.

Kedy má zmysel eskalovať

Eskalujte, keď môžete ukázať službu, ktorá je dostupná a nemala by byť, spolu s tokom, politikou, ktorá to povolila, a dôkazmi z oboch strán. Nehláste poruchu poskytovateľa na základe jediného štítku stavu alebo jedného čiastočného zachytenia, pretože taká správa bude uzavretá vysvetlením, ktoré ste práve prečítali. Ak je služba naozaj vystavená, vlastník tejto hranice je správna osoba na opravu, a delegované mapovanie portov alebo nechcený poslucháč je pravdepodobnejšou príčinou než chyba.

Potom zatvorte medzeru vo viditeľnosti, ktorá dovolila, aby jeden paket vyzeral ako celá relácia.