Conntrack NEW auf einem ACK-Paket: Was es nicht beweist

Im Firewall-Log steht eine Zeile, die Sie nicht erwartet haben: ein ACK-Paket, Conntrack-Zustand NEW, eine Quelladresse, die nicht Ihre ist, Zielport offen. Die Versuchung ist, das als neue eingehende Verbindung zu lesen, die niemand autorisiert hat. Was die Zeile tatsächlich sagt, ist enger: Als dieses Paket diesen Hook erreichte, hatte der Tracker keinen passenden Zustand, und das Paket trug ein ACK. Das sind zwei Fakten über zwei verschiedene Dinge, und keiner davon ist die vollständige Mitschrift eines Handshakes. Hier ist die Reihenfolge, die ich durchgehe, bevor ich eine Schlussfolgerung ziehe.

Fang beim Paket an, nicht beim Urteil

Trennen Sie die Beobachtungen, bevor Sie sie deuten. Die TCP-Flags beschreiben dieses Paket, der Zustand des Trackers beschreibt, was er an diesem Hook wusste, und Ihre Aufnahme beschreibt nur das Fenster, das Sie mitgeschnitten haben.

Diese drei zu vermischen, ist der Weg, auf dem aus einem ACK „der Anbieter hat jemanden hereingelassen“ wird.

Was NEW am Hook wirklich bedeutet

Der iptables-Conntrack-Abgleich dokumentiert NEW als ein Paket, das eine Verbindung beginnt, oder eines, das zu einer Verbindung gehört, die noch keinen Verkehr in beide Richtungen gesehen hat. ESTABLISHED heißt, der Tracker hat Pakete in beide Richtungen gesehen. Keine der beiden Definitionen sagt, dass das Paket ein SYN war, und keine sagt, dass es ohne Vorgeschichte ankam.

Ein Tracker, der einen Fluss mitten im Verlauf zu beobachten beginnt, klassifiziert das nächste Paket nach dem, was er weiß, und das kann nichts sein. Das ist eine Aussage über das Gedächtnis des Trackers, nicht über die Absicht des entfernten Hosts.

Loses Tracking erklärt die meisten ACK-Überraschungen

Der Kernel dokumentiert nf_conntrack_tcp_loose, was den Tracker TCP-Verbindungen aufnehmen lässt, deren Beginn er nicht gesehen hat. Mit der Einstellung auf ihrem Standardwert kann ein ACK aus der Flussmitte als etablierter Fluss übernommen werden. Schalten Sie sie ab, und dasselbe Paket wird wahrscheinlicher als INVALID statt als NEW eingestuft. Beide Ergebnisse beschreiben die Regeln des Trackers, nicht die Vorgeschichte der Anwendung.

Prüfen Sie also diese Einstellung, bevor Sie eine Theorie auf das Label bauen.

Schließen Sie die langweiligen Ursachen in dieser Reihenfolge aus

Die meisten NEW-auf-ACK-Ereignisse, denen ich nachgegangen bin, endeten in einer dieser Ursachen, und alle sind billig zu prüfen:

• Die Conntrack-Tabelle wurde geleert, oder der Tracker wurde neu gestartet.
• Der Host wurde neu gestartet, oder der Fluss wechselte in einen anderen Namespace oder auf ein anderes Gerät.
• Asymmetrisches Routing schickte das SYN über einen Pfad, den Sie nicht mitschneiden.
• NAT schrieb das Tuple um, sodass der Eintrag nicht mehr zu dem passt, was Sie gelesen haben.
• Die Aufnahme begann zu spät und sah den Anfang nie.

Jede davon entfernt die früheren Pakete aus der Sicht des Trackers und lässt die späteren unangetastet. Ein Neustart oder ein Leeren der Tabelle ist am leichtesten über Uptime und Logs zu bestätigen. Asymmetrisches Routing zeigt sich als einseitige Aufnahme. NAT ist der heimtückische Fall, weil das Tuple, das der Tracker gespeichert hat, nicht das im Log gedruckte Tuple ist.

Notieren Sie, welche davon Sie ausgeschlossen haben und wie, bevor Sie weitermachen.

Lesen Sie das Tuple, das Interface und den Hook

Ein Conntrack-Eintrag ist nach Adressen, Ports und Protokoll geschlüsselt, jede Übersetzung ändert also, welcher Eintrag passt. Notieren Sie auch Interface und Hook, denn ein Paket, das auf dem falschen Interface oder nach einer anderen Kette gesehen wird, sagt Ihnen, dass der Pfad nicht der aus dem Diagramm ist. Wenn das Ereignis eine VPN betrifft, entscheiden Sie, ob Sie auf das innere Paket oder den äußeren Träger schauen. Vergleichen Sie dann mit dem, was das Gateway für dasselbe Fünf-Tupel protokolliert hat.

Zwei Ansichten desselben Flusses, die sich widersprechen, sind aufschlussreicher als jede von beiden allein.

Wann es sich lohnt zu eskalieren

Eskalieren Sie, wenn Sie einen Dienst zeigen können, der erreichbar ist und es nicht sein sollte, mit dem Fluss, der Richtlinie, die ihn erlaubt hat, und Belegen von beiden Enden. Melden Sie keinen Anbieterfehler auf Basis eines einzigen Zustandslabels oder einer einzigen Teilaufnahme, denn diese Meldung wird mit genau der Erklärung geschlossen, die Sie gerade gelesen haben. Ist der Dienst wirklich exponiert, ist der Eigentümer dieser Grenze die richtige Person, das zu beheben, und ein delegiertes Port-Mapping oder ein unbeabsichtigter Listener ist die wahrscheinlichere Ursache als ein Bug.

Schließen Sie dann die Sichtbarkeitslücke, die ein Paket wie eine ganze Sitzung aussehen ließ.