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

I firewall-loggen er der én linje, du ikke forventede: en ACK-pakke, conntrack-tilstand NEW, en kildeadresse, der ikke er din, destinationsport åben. Fristelsen er at læse det som en ny indgående forbindelse, som ingen har godkendt. Det, linjen faktisk siger, er smallere: da den pakke nåede dette hook, havde trackeren ingen matchende tilstand, og pakken bar en ACK. Det er to fakta om to forskellige ting, og ingen af dem er en fuld transskription af et håndtryk. Her er den rækkefølge, jeg går igennem, før jeg drager en konklusion.

Start med pakken, ikke dommen

Adskil observationerne, før du fortolker dem. TCP-flagene beskriver denne pakke, trackerens tilstand beskriver, hvad den vidste ved det hook, og din optagelse beskriver kun det vindue, du har registreret.

At blande de tre er måden, hvorpå en ACK bliver til „udbyderen lukkede nogen ind“.

Hvad NEW egentlig betyder ved hooket

Den iptables-conntrack-matchning dokumenterer NEW som en pakke, der starter en forbindelse, eller en, der er knyttet til en forbindelse, som endnu ikke har set trafik i begge retninger. ESTABLISHED betyder, at trackeren har set pakker begge veje. Ingen af definitionerne siger, at pakken var en SYN, og ingen siger, at den ankom uden historik.

En tracker, der begynder at observere et flow midt i det, klassificerer den næste pakke ud fra det, den ved, og det kan være ingenting. Det er en udtalelse om trackerens hukommelse, ikke om den fjerne værtss vilje.

Løs sporing forklarer de fleste ACK-overraskelser

Kernen dokumenterer nf_conntrack_tcp_loose, som lader trackeren samle TCP-forbindelser op, den ikke har set starte. Med indstillingen på sin standardværdi kan en ACK midt i et flow antages som et etableret flow. Slå den fra, og samme pakke klassificeres sandsyneligere som INVALID i stedet for NEW. Begge udfald beskriver trackerens regler, ikke applikationens historik.

Så tjek den indstilling, før du bygger en teori på etiketten.

Udeluk de kedelige årsager i denne rækkefølge

De fleste NEW-på-ACK-hændelser, jeg har jagtet, endte i en af disse, og alle er billige at tjekke:

• Conntrack-tabellen blev tømt, eller trackeren blev genstartet.
• Værten blev genstartet, eller flowet flyttede til et andet namespace eller en anden enhed.
• Asymmetrisk routing sendte SYN’en ud ad en vej, du ikke optager.
• NAT skrev tuple’en om, så posten matcher ikke længere det, du læste.
• Optagelsen startede sent og så aldrig begyndelsen.

Hver af dem fjerner de tidligere pakker fra trackerens synsfelt og lader de senere være intakte. En genstart eller en tømning af tabellen er lettest at bekræfte ud fra uptime og logfiler. Asymmetrisk routing viser sig som en envejsoptagelse. NAT er den snedige, fordi den tuple, trackeren har gemt, ikke er den tuple, der er trykt i loggen.

Skriv ned, hvilke af disse du har udelukket, og hvordan, før du går videre.

Læs tuple’en, interfacet og hooket

En conntrack-post er nøglet på adresser, porte og protokol, så enhver oversættelse ændrer, hvilken post der matcher. Noter også interfacet og hooket, fordi en pakke set på det forkerte interface eller efter en anden kæde fortæller dig, at vejen ikke er den, diagrammet viser. Når hændelsen involverer en VPN, afgør, om du ser på den indre pakke eller den ydre bærer. Sammenlign derefter med det, gatewayen loggede for den samme femdelte tuple.

To visninger af ét flow, der er uenige, er mere oplysende end nogen af dem alene.

Hvornår det er værd at eskalere

Eskaler, når du kan vise en tjeneste, der er tilgængelig og ikke burde være det, med flowet, den politik, der tillod det, og beviser fra begge ender. Rapportér ikke en udbyderfejl på baggrund af én tilstandsetiket eller én delvis optagelse, for den rapport vil blive lukket med den forklaring, du netop har læst. Hvis tjenesten virkelig er eksponeret, er ejeren af den grænse den rette til at rette det, og en delegeret portmapping eller en utilsigtet lytter er en mere sandsynlig årsag end en fejl.

Ret derefter det synlighedshul, der lod én pakke ligne en hel session.