Conntrack NEW sa isang ACK packet: ano ang hindi nito pinapatunayan

Sa log ng firewall may isang linyang hindi mo inaasahan: isang ACK packet, conntrack state na NEW, pinagmulang address na hindi sa iyo, bukas ang destinasyong port. Ang tukso ay basahin ito bilang bagong papasok na koneksyon na walang sinumang nag-authorize. Ang tunay na sinasabi ng linya ay mas makitid: nang makarating ang packet na iyon sa hook na ito, walang tugmang estado ang tracker, at may dalang ACK ang packet. Dalawang katotohanan iyon tungkol sa dalawang magkaibang bagay, at wala sa dalawa ang kumpletong transcript ng isang handshake. Ito ang pagkakasunod-sunod na dinaraanan ko bago magbigay ng konklusyon.

Magsimula sa packet, hindi sa hatol

Paghiwalayin ang mga obserbasyon bago ito bigyang-kahulugan. Inilalarawan ng mga flag ng TCP ang packet na ito, inilalarawan ng estado ng tracker ang alam nito sa hook na iyon, at ang iyong pagkuha ay naglalarawan lamang ng window na naitala mo.

Ang paghahalo ng tatlong iyon ang paraan kung paano nagiging “pinapasok ng provider ang isang tao” ang isang ACK.

Ano ang tunay na ibig sabihin ng NEW sa hook

pagtutugma ng conntrack sa iptables ay nagdodokumento ng NEW bilang packet na nagsisimula ng koneksyon, o isang konektado sa koneksyong hindi pa nakakita ng trapiko sa dalawang direksyon. Ang ESTABLISHED ay nangangahulugang nakakita ang tracker ng mga packet sa dalawang direksyon. Wala sa dalawang depinisyon ang nagsasabing SYN ang packet, o na dumating ito nang walang kasaysayan.

Ang tracker na nagsimulang magmasid ng daloy sa gitna ay inuuri ang susunod na packet ayon sa alam nito, at maaaring wala ito. Pahayag iyon tungkol sa memorya ng tracker, hindi tungkol sa layunin ng malayong host.

Ang maluwag na pagsubaybay ang nagpapaliwanag ng karamihan ng sorpresa sa ACK

Dinodokumento ng kernel nf_conntrack_tcp_loose, na nagpapahintulot sa tracker na kunin ang mga koneksyong TCP na hindi nito nakitang nagsimula. Kapag ang setting ay nasa default na halaga, ang ACK mula sa gitna ng daloy ay maaaring tanggapin bilang establisadong daloy. Patayin ito at ang parehong packet ay mas malamang na mauri bilang INVALID kaysa NEW. Ang dalawang kinalabasan ay naglalarawan ng mga patakaran ng tracker, hindi ng kasaysayan ng aplikasyon.

Kaya suriin ang setting na iyon bago bumuo ng teorya sa label.

Ibukod ang mga boring na dahilan sa ganitong pagkakasunod-sunod

Karamihan ng mga kaganapang NEW-on-ACK na sinubaybayan ko ay natapos sa isa sa mga ito, at lahat ay mura suriin:

• Na-flush ang talahanayan ng conntrack, o nag-restart ang tracker.
• Nag-reboot ang host, o lumipat ang daloy sa ibang namespace o device.
• Naglabas ang asymmetric routing ng SYN sa landas na hindi mo kinukuha.
• Muli naisulat ng NAT ang tuple, kaya hindi na tugma ang entry sa nabasa mo.
• Nahuli ang simula ng pagkuha at hindi nito nakita ang simula.

Ang bawat isa sa mga ito ay nag-aalis ng mga naunang packet mula sa paningin ng tracker at iniiwan ang mga nahuhuling buo. Ang restart o paglilinis ng talahanayan ang pinakamadaling kumpirmahin mula sa uptime at mga log. Ang asymmetric routing ay lumilitaw bilang pagkuha sa isang direksyon lamang. Ang NAT ang tuso, dahil ang tuple na itinago ng tracker ay hindi ang tuple na nakalimbag sa log.

Isulat kung alin sa mga ito ang ibinukod mo, at paano, bago magpatuloy.

Basahin ang tuple, interface at hook

Ang entry ng conntrack ay naka-key sa mga address, port at protocol, kaya binabago ng anumang salin kung aling entry ang tugma. Ilista rin ang interface at hook, dahil ang packet na nakita sa maling interface o pagkatapos ng ibang chain ay nagsasabi na ang landas ay hindi tulad ng nasa diagram. Kapag may kinalaman ang VPN sa kaganapan, magpasya kung tinitignan mo ang panloob na packet o ang panlabas na carrier. Pagkatapos ihambing sa naitala ng gateway para sa parehong tuple na limang bahagi.

Ang dalawang pananaw sa isang daloy na hindi nagkakasundo ay mas nagbibigay-kaalaman kaysa alinman sa dalawa nang mag-isa.

Kailan sulit na i-escalate

I-escalate kapag maipakita mo ang serbisyong naaabot at hindi dapat, kasama ang daloy, ang patakarang nagpahintulot nito at ebidensya mula sa dalawang dulo. Huwag mag-ulat ng depekto ng provider batay sa isang label ng estado o isang bahagyang pagkuha, dahil isasara ang ulat na iyon gamit ang paliwanag na kababasa mo lang. Kung tunay na nakalantad ang serbisyo, ang may-ari ng hangganang iyon ang tamang taong mag-aayos nito, at ang delegated port mapping o hindi sinasadyang listener ay mas malamang na dahilan kaysa bug.

Pagkatapos ay isara ang puwang sa visibility na nagpatingin sa isang packet na parang buong session.