Conntrack NEW på ein ACK-pakke: kva det ikkje provar

I brannmurloggen står det éi line du ikkje venta: ein ACK-pakke, conntrack-tilstand NEW, ei kjeldeadresse som ikkje er di, destinasjonsport open. Freistinga er å lese det som ei ny innkomande tilkopling som ingen har autorisert. Det lina faktisk seier er smalare: då den pakken nådde denne hooken, hadde trackaren ingen samsvarande tilstand, og pakken bar ein ACK. Det er to fakta om to ulike ting, og ingen av dei er ein fullstendig transkripsjon av eit handtrykk. Her er rekkjefølgja eg går gjennom før eg dreg ei slutning.

Start med pakken, ikkje domen

Skil observasjonane før du tolkar dei. TCP-flaggene skildrar denne pakken, tilstanden til trackaren skildrar kva han visste ved den hooken, og opptaket ditt skildrar berre vindauget du registrerte.

Å blande desse tre er måten ein ACK blir til «leverandøren slapp nokon inn».

Kva NEW eigentleg tyder ved hooken

Den iptables-conntrack-matchinga dokumenterer NEW som ein pakke som startar ei tilkopling, eller ein som høyrer til ei tilkopling som enno ikkje har sett trafikk i begge retningar. ESTABLISHED tyder at trackaren har sett pakkar begge vegar. Ingen av definisjonane seier at pakken var ein SYN, og ingen seier at han kom utan historikk.

Ein tracker som byrjar å observere ein straum midt i, klassifiserer neste pakke etter det han veit, og det kan vere ingenting. Det er ei utsegn om minnet til trackaren, ikkje om hensikta til den eksterne verten.

Laus sporing forklarer dei fleste ACK-overraskingane

Kjernen dokumenterer nf_conntrack_tcp_loose, som lèt trackaren plukke opp TCP-tilkoplingar han ikkje såg starten av. Med innstillinga på standardverdien kan ein ACK midt i ein straum bli teken opp som ein etablert straum. Slår du henne av, blir same pakke meir truleg klassifisert som INVALID i staden for NEW. Begge utfalla skildrar reglane til trackaren, ikkje historikken til applikasjonen.

Så sjekk den innstillinga før du byggjer ein teori på etiketten.

Utelukk dei keisame årsakene i denne rekkjefølgja

Dei fleste NEW-på-ACK-hendingane eg har jakta på enda i ein av desse, og alle er billege å sjekke:

• Conntrack-tabellen vart tømd, eller trackaren vart restarta.
• Verten vart restarta, eller straumen flytta til eit anna namespace eller ei anna eining.
• Asymmetrisk ruting sende SYN-en ut på ein stig du ikkje fangar opp.
• NAT skreiv om tuple-en, så oppføringa svarar ikkje lenger til det du las.
• Opptaket starta seint og såg aldri byrjinga.

Kvar av desse fjernar dei tidlegare pakkane frå synsfeltet til trackaren og lèt dei seinare vere intakte. Ein restart eller ei tømming av tabellen er lettast å stadfeste frå uptime og loggar. Asymmetrisk ruting viser seg som eit einvegssopptak. NAT er den lumske, fordi tuple-en trackaren lagra ikkje er tuple-en som er trykt i loggen.

Skriv ned kva av desse du utelukka, og korleis, før du går vidare.

Les tuple-en, grensesnittet og hooken

Ei conntrack-oppføring er nøkla på adresser, portar og protokoll, så kvar omsetjing endrar kva oppføring som svarar. Noter òg grensesnittet og hooken, fordi ein pakke sett på feil grensesnitt eller etter ei anna kjede fortel deg at stigen ikkje er den diagrammet viser. Når hendinga gjeld ein VPN, avgjer om du ser på den indre pakken eller den ytre beraren. Samanlikn deretter med det gatewayen logga for den same femdelte tuple-en.

To visningar av ein straum som er usamde er meir informative enn kvar av dei åleine.

Når det er verdt å eskalere

Eskaler når du kan vise ein teneste som er tilgjengeleg og ikkje burde vere det, med straumen, policyen som tillét det, og prov frå begge endar. Ikkje rapporter ein leverandørfeil på grunnlag av éin tilstandsetikett eller eitt delvis opptak, fordi den rapporten blir lukka med forklaringa du nettopp las. Viss tenesta verkeleg er eksponert, er eigaren av den grensa den rette personen til å rette det, og ein delegert portmapping eller ein utilsikta lyttar er ei meir truleg årsak enn ein feil.

Rett deretter opp synlegheitsgapet som lét éin pakke sjå ut som ei heil økt.