IPsec-Zustand prüfen, ohne die Schlüssel zu veröffentlichen

Ein IPsec-Zustandsdump ist kein Statusbericht, und genau diese Behandlung führt dazu, dass Schlüsselmaterial in einem öffentlichen Issue-Tracker landet. Manche Ausgaben der Kernel-Inspektion enthalten die Verkehrsschlüssel, die der Kernel verwendet, zusammen mit Adressen, Selektoren und Zählern, die wirklich nützlich sind. Die sichere Gewohnheit ist, zuerst die Übersicht zu sammeln und erst dann zum rohen Zustand zu greifen, wenn die Übersicht die Frage nicht beantworten kann. Wenn Sie den rohen Zustand sehen müssen, sehen Sie ihn lokal an und teilen Sie etwas Engeres.

Prüfung 1: Kann dieses Artefakt die Maschine überhaupt verlassen

Eine Konfigurationsdatei, ein privater Schlüssel, ein uneingeschränkter Paketmitschnitt und ein roher Zustandsdump sind alle Geheimnisse, bis das Gegenteil bewiesen ist. Ein Befehl, der Schlüssel ausgibt, wird nicht dadurch sicher, dass Sie ihn zur Diagnose ausgeführt haben.

Die Regel ist einfach genug, um sie in einem Satz zu sagen: Teilen Sie die Beobachtung, die die Frage beantwortet, nicht den Maschinenzustand, der sie erzeugt hat.

Prüfung 2: Wählen Sie den Übersichtsbefehl, nicht den Zustandsdump

Für strongSwan zeigt swanctl --list-sas die Assoziationsübersicht: Identitäten, installierte Child-SAs, Zustände und Zähler. Er erfordert nicht den rohen Schlüsseldump und ist das Erste, was in ein Ticket gehört. Auf der Kernelseite unterstützt iproute2 ip xfrm state list nokeys in Versionen, die die Option dokumentieren, wodurch Schlüsselmaterial unterdrückt wird, während die Assoziationsfelder erhalten bleiben.

Bestätigen Sie die Syntax im lokalen Handbuch, bevor Sie sich darauf verlassen, denn die Option ist nicht in jeder Version vorhanden, und eine allgemeine Zustandsauflistung ohne sie ist ein anderer Befehl mit anderer Ausgabe. ip xfrm state auf einem alten Build auszuführen, um zu sehen, ob das Flag existiert, ist genau der Fehler, um den es in dieser Checkliste geht.

Prüfung 3: Notieren Sie nur, was die Untersuchung braucht

Assoziationsstatus, Algorithmen, Selektoren, Zeitstempel, Richtung und die relevanten Zähler reichen normalerweise aus. Kontoidentitäten, öffentliche Adressen und interne Topologie oft nicht, und sie lassen sich schwärzen, ohne den diagnostischen Wert zu verlieren.

Schwärzen Sie standardmäßig und fügen Sie auf Anfrage wieder hinzu. Wer Ihr Ticket liest, kann ein weiteres Feld anfordern; einen bereits eingefügten Schlüssel kann er nicht ungesehen machen.

Es gibt einen Mittelweg, den man kennen sollte: Auch eine Übersicht kann sensibel sein. Identitäten, Peer-Adressen und Child-Namen beschreiben Ihre Topologie, und in manchen Organisationen sind das bereits eingeschränkte Informationen. Entscheiden Sie vor dem Einfügen, wer das Publikum ist, und bevorzugen Sie einen Kanal mit passender Zugriffskontrolle gegenüber einem öffentlichen Issue. Ein sicherer Befehl ist nicht dasselbe wie ein sicheres Ziel.

Prüfung 4: Korrelieren Sie einen Versuch über beide Enden

Erfassen Sie Client und Gateway für denselben Verbindungsversuch zur selben Zeit und stellen Sie sicher, dass die Assoziation, die Sie beschreiben, die ist, die dieser Versuch erzeugt hat. Eine veraltete Child-SA aus einem früheren Versuch mit einer frischen Routenaufnahme zu mischen, ergibt einen Bericht, der intern konsistent und völlig irreführend ist.

Identifizieren Sie die Assoziation anhand ihrer eindeutigen Kennungen und nicht anhand des Tunnels, und notieren Sie die Richtung des Fehlers. Wenn das Symptom kein Verkehr in einer Richtung ist, sagen Sie welche Richtung und nennen Sie ein harmloses Testziel, damit der Leser über den Pfad nachdenken kann, statt zu raten. Ein Zähler, der in einer Richtung null ist und in der anderen steigt lokalisiert das Problem weit besser als jeder Schlüsseldump. Halten Sie die Zeitstempel in einer Zeitzone und sagen Sie, in welcher.

Prüfung 5: Was tun, wenn Material bereits offengelegt wurde

Das Löschen des Anhangs belegt nicht, dass niemand ihn behalten hat, und ein öffentlicher Paste wird schnell kopiert.

Behandeln Sie das als Vorfall und nutzen Sie den Ersatzprozess des Betreibers: Rotieren Sie die betroffenen Schlüssel oder Anmeldedaten, prüfen Sie, ob die Offenlegung eine breitere Kompromittierung bedeutet, und folgen Sie dem jeweils geltenden Benachrichtigungsweg. Die technische Bereinigung ist der leichte Teil; die Annahme, dass niemand es gelesen hat, ist der schwere.

Die dauerhafte Praxis ist eine kleine Vorlage, die Sie vor dem Einfügen ausfüllen: welches Ende, welche Assoziationskennung, welche Richtung, welcher Zähler und was bereits ausgeschlossen wurde. Die Dokumentation zu swanctl list-sas beschreibt die Übersichtsfelder, und genau das brauchen die meisten Tickets. Alles andere ist auf Anfrage für diejenigen verfügbar, die es brauchen. Ein Diagnosebericht sollte Belege enthalten, keinen Zugang.