Conntrack NEW op een ACK-pakket: wat het niet bewijst

In het firewall-log staat één regel die je niet verwachtte: een ACK-pakket, conntrack-toestand NEW, een bronadres dat niet van jou is, doelpoort open. De verleiding is om het te lezen als een nieuwe inkomende verbinding die niemand heeft geautoriseerd. Wat de regel werkelijk zegt, is smaller: toen dat pakket deze hook bereikte, had de tracker geen passende toestand, en het pakket droeg een ACK. Dat zijn twee feiten over twee verschillende dingen, en geen van beide is een volledig transcript van een handshake. Dit is de volgorde die ik doorloop voordat ik een conclusie trek.

Begin bij het pakket, niet bij het vonnis

Scheid de waarnemingen voordat je ze interpreteert. De TCP-flags beschrijven dit pakket, de toestand van de tracker beschrijft wat hij op die hook wist, en je opname beschrijft alleen het venster dat je hebt vastgelegd.

Die drie door elkaar halen is hoe een ACK „de provider liet iemand binnen” wordt.

Wat NEW op de hook werkelijk betekent

De iptables-conntrack-overeenkomst documenteert NEW als een pakket dat een verbinding begint, of een dat hoort bij een verbinding die nog geen verkeer in beide richtingen heeft gezien. ESTABLISHED betekent dat de tracker pakketten in beide richtingen heeft gezien. Geen van beide definities zegt dat het pakket een SYN was, en geen zegt dat het zonder geschiedenis aankwam.

Een tracker die een stroom halverwege begint te observeren, classificeert het volgende pakket naar wat hij weet, en dat kan niets zijn. Dat is een uitspraak over het geheugen van de tracker, niet over de bedoeling van de externe host.

Losse tracking verklaart de meeste ACK-verrassingen

De kernel documenteert nf_conntrack_tcp_loose, waardoor de tracker TCP-verbindingen kan oppikken waarvan hij het begin niet zag. Met de instelling op de standaardwaarde kan een ACK midden in een stroom als gevestigde stroom worden overgenomen. Zet je hem uit, dan wordt hetzelfde pakket eerder als INVALID dan als NEW geclassificeerd. Beide uitkomsten beschrijven de regels van de tracker, niet de geschiedenis van de toepassing.

Controleer die instelling dus voordat je een theorie op het label bouwt.

Sluit de saaie oorzaken in deze volgorde uit

De meeste NEW-op-ACK-gebeurtenissen die ik heb nagelopen, eindigden in een van deze, en alle zijn goedkoop te controleren:

• De conntrack-tabel is geleegd, of de tracker is herstart.
• De host is herstart, of de stroom is naar een andere namespace of een ander apparaat verhuisd.
• Asymmetrische routering stuurde de SYN over een pad dat je niet opneemt.
• NAT herschreef de tuple, dus de vermelding komt niet meer overeen met wat je las.
• De opname begon laat en zag het begin nooit.

Elk daarvan haalt de eerdere pakketten uit het zicht van de tracker en laat de latere intact. Een herstart of een leeggemaakte tabel is het gemakkelijkst te bevestigen uit uptime en logs. Asymmetrische routering komt naar voren als een eenrichtingsopname. NAT is de geniepige, omdat de tuple die de tracker bewaarde niet de tuple is die in het log is afgedrukt.

Schrijf op welke van deze je hebt uitgesloten, en hoe, voordat je verdergaat.

Lees de tuple, de interface en de hook

Een conntrack-vermelding wordt gesleuteld op adressen, poorten en protocol, dus elke vertaling verandert welke vermelding past. Noteer ook de interface en de hook, want een pakket dat op de verkeerde interface of na een andere keten wordt gezien, zegt je dat het pad niet is wat het diagram zegt. Wanneer de gebeurtenis een VPN betreft, bepaal of je naar het binnenste pakket of de buitenste drager kijkt. Vergelijk daarna met wat de gateway voor dezelfde vijfdelige tuple heeft gelogd.

Twee weergaven van één stroom die het oneens zijn, zijn informatiever dan elk van beide alleen.

Wanneer het de moeite loont te escaleren

Escaleer wanneer je een dienst kunt tonen die bereikbaar is en dat niet zou moeten zijn, met de stroom, het beleid dat het toestond en bewijs van beide kanten. Meld geen leveranciersfout op grond van één toestandslabel of één gedeeltelijke opname, want die melding wordt gesloten met de uitleg die je net hebt gelezen. Als de dienst echt is blootgesteld, is de eigenaar van die grens de juiste persoon om het te herstellen, en een gedelegeerde portmapping of een onbedoelde listener is een waarschijnlijker oorzaak dan een bug.

Sluit dan het zichtbaarheidsgat dat één pakket op een hele sessie liet lijken.