Conntrack NEW na ACK paketu: šta to ne dokazuje

U logu firewall-a postoji red koji niste očekivali: ACK paket, conntrack stanje NEW, izvorišna adresa koja nije vaša, odredišni port otvoren. Iskušenje je pročitati ga kao novu dolaznu vezu koju niko nije odobrio. Ono što red zapravo kaže je uže: kada je taj paket stigao do ovog hook-a, tracker nije imao odgovarajuće stanje, a paket je nosio ACK. To su dvije činjenice o dvije različite stvari i nijedna nije potpuni zapis rukovanja. Evo reda kojim prolazim prije nego donesem zaključak.

Počnite od paketa, ne od presude

Razdvojite zapažanja prije nego ih protumačite. TCP zastavice opisuju ovaj paket, stanje trackera opisuje šta je znao na tom hook-u, a vaše snimanje opisuje samo prozor koji ste zabilježili.

Miješanje tih tri stvari je način na koji ACK postaje „provajder je nekoga pustio unutra“.

Šta NEW zapravo znači na hook-u

iptables conntrack podudaranje dokumentuje NEW kao paket koji započinje vezu ili onaj povezan s vezom koja još nije vidjela saobraćaj u oba smjera. ESTABLISHED znači da je tracker vidio pakete u oba smjera. Nijedna definicija ne kaže da je paket bio SYN, niti da je stigao bez historije.

Tracker koji počne posmatrati tok u sredini klasifikuje sljedeći paket prema onome što zna, a to može biti ništa. To govori o pamćenju trackera, ne o namjeri udaljenog hosta.

Labavo praćenje objašnjava većinu ACK iznenađenja

Kernel dokumentuje nf_conntrack_tcp_loose, što trackeru omogućava da preuzme TCP veze čiji početak nije vidio. Uz zadanu vrijednost postavke, ACK iz sredine toka može biti prihvaćen kao uspostavljen tok. Isključite je i isti paket će vjerovatnije biti klasifikovan kao INVALID umjesto NEW. Oba ishoda opisuju pravila trackera, ne historiju aplikacije.

Zato provjerite tu postavku prije nego na oznaci izgradite teoriju.

Isključite dosadne uzroke ovim redom

Većina NEW-na-ACK događaja koje sam pratio završila je na jednom od ovih, a sve ih je jeftino provjeriti:

• Conntrack tabela je očišćena ili je tracker restartovan.
• Host je restartovan ili se tok preselio u drugi namespace ili uređaj.
• Asimetrično rutiranje poslalo je SYN putem koji ne snimate.
• NAT je prepisao tuple, pa zapis više ne odgovara onome što ste pročitali.
• Snimanje je počelo kasno i nikada nije vidjelo početak.

Svaki od njih uklanja ranije pakete iz trackerovog vidokruga, a kasnije ostavlja netaknutima. Restart ili čišćenje tabele najlakše je potvrditi iz uptime-a i logova. Asimetrično rutiranje se vidi kao jednosmjerno snimanje. NAT je podmukao, jer tuple koji je tracker sačuvao nije tuple odštampan u logu.

Zapišite koje ste od ovih isključili i kako, prije nego nastavite.

Pročitajte tuple, interfejs i hook

Conntrack zapis se ključuje adresama, portovima i protokolom, pa svako prevođenje mijenja koji zapis odgovara. Zabilježite i interfejs i hook, jer paket viđen na pogrešnom interfejsu ili nakon drugog lanca govori da putanja nije ona sa dijagrama. Kada događaj uključuje VPN, odredite gledate li unutrašnji paket ili vanjski nosač. Zatim uporedite s onim što je gateway zabilježio za isti tuple od pet dijelova.

Dva pogleda na jedan tok koji se razilaze informativnija su od bilo kojeg samog.

Kada je vrijedno eskalirati

Eskalirajte kada možete pokazati uslugu do koje se može doći i ne bi trebalo, uz tok, politiku koja je to dozvolila i dokaze s oba kraja. Ne prijavljujte defekt provajdera na osnovu jedne oznake stanja ili jednog djelimičnog snimanja, jer će ta prijava biti zatvorena objašnjenjem koje ste upravo pročitali. Ako je usluga zaista izložena, vlasnik te granice je prava osoba da je popravi, a delegirano mapiranje portova ili neželjeni slušalac vjerovatniji su uzrok od greške.

Zatim zatvorite prazninu u vidljivosti koja je dopustila da jedan paket izgleda kao cijela sesija.