Conntrack NEW na paketu ACK: česa to ne dokazuje

V dnevniku požarnega zidu je ena vrstica, ki je niste pričakovali: paket ACK, stanje conntrack NEW, naslov vira, ki ni vaš, ciljna vrata odprta. Skušnjava je, da bi jo prebrali kot novo dohodno povezavo, ki je nihče ni odobril. Kar vrstica v resnici pove, je ožje: ko je ta paket prispel do tega hooka, sledilnik ni imel ustreznega stanja, paket pa je nosil ACK. To sta dve dejstvi o dveh različnih stvareh in nobeno ni popoln zapis rokovanja. To je vrstni red, ki ga prehodim, preden sklepam.

Začnite s paketom, ne z razsodbo

Ločite opažanja, preden jih tolmačite. Zastavice TCP opisujejo ta paket, stanje sledilnika opisuje, kaj je vedel na tem hooku, vaš zajem pa opisuje le okno, ki ste ga posneli.

Mešanje teh treh je način, kako ACK postane »ponudnik je koga spustil noter«.

Kaj NEW na hooku v resnici pomeni

ujemanje conntrack v iptables dokumentira NEW kot paket, ki začne povezavo, ali paket, povezan s povezavo, ki še ni videla prometa v obe smeri. ESTABLISHED pomeni, da je sledilnik videl pakete v obe smeri. Nobena definicija ne pravi, da je bil paket SYN, niti da je prispel brez zgodovine.

Sledilnik, ki začne opazovati tok na sredini, razvrsti naslednji paket po tem, kar ve, in to je lahko nič. To je trditev o spominu sledilnika, ne o nameri oddaljenega gostitelja.

Ohlapno sledenje pojasni večino presenečenj z ACK

Jedro dokumentira nf_conntrack_tcp_loose, kar sledilniku omogoča, da prevzame povezave TCP, katerih začetka ni videl. Pri privzeti vrednosti je ACK iz sredine toka lahko sprejet kot vzpostavljen tok. Izklopite to in isti paket bo verjetneje razvrščen kot INVALID namesto NEW. Oba izida opisujeta pravila sledilnika, ne zgodovine aplikacije.

Zato preverite to nastavitev, preden na oznako zgradite teorijo.

Izključite dolgočasne vzroke v tem vrstnem redu

Večina dogodkov NEW-na-ACK, ki sem jim sledil, se je končala z enim od teh, vsi pa so poceni za preverjanje:

• Tabela conntrack je bila izpraznjena ali je bil sledilnik znova zagnan.
• Gostitelj se je znova zagnal ali se je tok preselil v drug namespace ali napravo.
• Asimetrično usmerjanje je poslalo SYN po poti, ki je ne zajemate.
• NAT je prepisal tuple, zato vnos ne ustreza več temu, kar ste prebrali.
• Zajem se je začel pozno in začetka ni nikoli videl.

Vsak od njih odstrani zgodnejše pakete iz vidnega polja sledilnika in poznejše pusti nedotaknjene. Znova zagon ali praznjenje tabele je najlažje potrditi iz uptime in dnevnikov. Asimetrično usmerjanje se pokaže kot enosmerni zajem. NAT je zahrbtni, ker tuple, ki ga je sledilnik shranil, ni tuple, natisnjen v dnevniku.

Zapišite, katere od teh ste izključili in kako, preden nadaljujete.

Preberite tuple, vmesnik in hook

Vnos conntrack je ključen po naslovih, vratih in protokolu, zato vsak prevod spremeni, kateri vnos se ujema. Zabeležite tudi vmesnik in hook, ker paket, viden na napačnem vmesniku ali po drugi verigi, pove, da pot ni tista s sheme. Ko dogodek vključuje VPN, se odločite, ali gledate notranji paket ali zunanji nosilec. Nato primerjajte s tem, kar je prehod zabeležil za isti petdelni tuple.

Dva nasprotujoča si pogleda na isti tok so bolj poučna kot kateri koli od njiju sam.

Kdaj se izplača stopnjevati

Stopnjujte, ko lahko pokažete storitev, ki je dosegljiva in ne bi smela biti, skupaj s tokom, politiko, ki je to dovolila, in dokazi z obeh koncev. Ne poročajte o napaki ponudnika na podlagi ene oznake stanja ali enega delnega zajema, ker bo to poročilo zaprto z razlago, ki ste jo pravkar prebrali. Če je storitev res izpostavljena, je lastnik te meje prava oseba, da to popravi, in delegirano preslikavo vrat ali nenamerni poslušalec je verjetnejši vzrok kot hrošč.

Nato zaprite vrzel v vidnosti, ki je pustila, da je en paket izgledal kot cela seja.