Conntrack NEW på en ACK-pakke: hva det ikke beviser

I brannmurloggen står det én linje du ikke forventet: en ACK-pakke, conntrack-tilstand NEW, en kildeadresse som ikke er din, destinasjonsport åpen. Fristelsen er å lese det som en ny innkommende tilkobling som ingen har autorisert. Det linjen faktisk sier er smalere: da den pakken nådde denne hooken, hadde trackeren ingen samsvarende tilstand, og pakken bar en ACK. Det er to fakta om to forskjellige ting, og ingen av dem er en fullstendig transkripsjon av et håndtrykk. Her er rekkefølgen jeg går gjennom før jeg trekker en konklusjon.

Start med pakken, ikke dommen

Skill observasjonene før du tolker dem. TCP-flaggene beskriver denne pakken, trackerens tilstand beskriver hva den visste ved den hooken, og opptaket ditt beskriver bare vinduet du registrerte.

Å blande disse tre er måten en ACK blir til «leverandøren slapp noen inn».

Hva NEW egentlig betyr ved hooken

Den iptables-conntrack-matchingen dokumenterer NEW som en pakke som starter en tilkobling, eller en som hører til en tilkobling som ennå ikke har sett trafikk i begge retninger. ESTABLISHED betyr at trackeren har sett pakker begge veier. Ingen av definisjonene sier at pakken var en SYN, og ingen sier at den kom uten historikk.

En tracker som begynner å observere en strøm midt i, klassifiserer neste pakke etter det den vet, og det kan være ingenting. Det er en uttalelse om trackerens hukommelse, ikke om den eksterne vertens hensikt.

Løs sporing forklarer de fleste ACK-overraskelsene

Kjernen dokumenterer nf_conntrack_tcp_loose, som lar trackeren plukke opp TCP-tilkoblinger den ikke så starten av. Med innstillingen på standardverdien kan en ACK midt i en strøm bli adoptert som en etablert strøm. Slå den av, og samme pakke blir mer sannsynlig klassifisert som INVALID i stedet for NEW. Begge utfallene beskriver trackerens regler, ikke applikasjonens historikk.

Så sjekk den innstillingen før du bygger en teori på etiketten.

Utelukk de kjedelige årsakene i denne rekkefølgen

De fleste NEW-på-ACK-hendelsene jeg har jaktet på endte i en av disse, og alle er billige å sjekke:

• Conntrack-tabellen ble tømt, eller trackeren ble restartet.
• Verten ble restartet, eller strømmen flyttet til et annet namespace eller en annen enhet.
• Asymmetrisk ruting sendte SYN-en ut på en sti du ikke fanger opp.
• NAT skrev om tuple-en, så oppføringen samsvarer ikke lenger med det du leste.
• Opptaket startet sent og så aldri begynnelsen.

Hver av disse fjerner de tidligere pakkene fra trackerens synsfelt og lar de senere være intakte. En restart eller en tømming av tabellen er lettest å bekrefte fra uptime og logger. Asymmetrisk ruting viser seg som et enveisopptak. NAT er den snedige, fordi tuple-en trackeren lagret ikke er tuple-en som er trykket i loggen.

Skriv ned hvilke av disse du utelukket, og hvordan, før du går videre.

Les tuple-en, grensesnittet og hooken

En conntrack-oppføring er nøklet på adresser, porter og protokoll, så enhver oversettelse endrer hvilken oppføring som samsvarer. Noter også grensesnittet og hooken, fordi en pakke sett på feil grensesnitt eller etter en annen kjede forteller deg at stien ikke er den diagrammet viser. Når hendelsen involverer en VPN, avgjør om du ser på den indre pakken eller den ytre bæreren. Sammenlign deretter med det gatewayen logget for den samme femdelte tuple-en.

To visninger av én strøm som er uenige er mer informative enn hver av dem alene.

Når det er verdt å eskalere

Eskaler når du kan vise en tjeneste som er tilgjengelig og ikke burde være det, med strømmen, policyen som tillot det, og bevis fra begge ender. Ikke rapporter en leverandørfeil på grunnlag av én tilstandsetikett eller ett delvis opptak, fordi den rapporten vil bli lukket med forklaringen du nettopp leste. Hvis tjenesten virkelig er eksponert, er eieren av den grensen den rette personen til å rette det, og en delegert portmapping eller en utilsiktet lytter er en mer sannsynlig årsak enn en feil.

Rett deretter opp synlighetsgapet som lot én pakke se ut som en hel økt.