Ein privater Port bescheinigt nicht die Software dahinter

Es ist ein vernünftiger Instinkt: Wenn nur das VPN den SSH-Listener erreicht, ist die Exposition klein und das Problem erledigt. Exposition ist jedoch nicht gleich Integrität. Die erste Hälfte stimmt, die zweite folgt daraus nicht. Erreichbarkeit steuert, wer eine Verbindung versuchen darf; Softwareintegrität steuert, was der Listener tut, wenn er eine bekommt. Ein Tor verengt das Publikum und sagt nichts über den Code dahinter.

Ein privater Port ist eine kleinere Tür, kein anderes Schloss, und dieser Unterschied entscheidet, was Sie als Nächstes prüfen.

Zwei Kontrollen, zwei Fragen

Eine Netzwerkbeschränkung verringert die Exposition. Sie lässt zugelassene Nutzer und jeden kompromittierten freigegebenen Client weiterhin den betroffenen Dienst erreichen. Das Korrigieren des Pakets stellt die Software wieder her, und es verengt auch keine zu breite Netzwerkfreigabe. Jede Kontrolle erfüllt ihre eigene Aufgabe, und jede kann korrekt sein, während die andere fehlt. Beide zusammen zu prüfen ist der Weg, auf dem sich ein Team davon überzeugt, dass eine beide abdeckt, und genau das ist der Fehler, um den es in diesem Beitrag geht.

Der VPN-Endpunkt ist ebenfalls Software und trägt dieselbe Verpflichtung. Ihn in den Pfad aufzunehmen bringt eine eigene Wartungsverpflichtung mit sich und beseitigt nicht die Lieferkettenverantwortung für alles dahinter.

Was die XZ-Offenlegung tatsächlich zeigte

Die XZ/liblzma-Offenlegung vom März 2024 beschrieb eine Hintertür, die unter betroffenen Bedingungen zur Kompromittierung eines SSH-Servers führen konnte. Sie war ebenso ein Softwareintegritätsproblem wie ein Expositionsproblem und kein Beleg dafür, dass jede Linux-Installation den verwundbaren Build enthielt. Der Umfang ergibt sich aus den betroffenen Versionen und den Distributionen, die sie ausgeliefert haben, nicht aus dem Namen der Betriebssystemfamilie.

Dieser Unterschied ist der Unterschied zwischen einer Incident-Reaktion und einem Gerücht, und es lohnt sich, darin pedantisch zu sein.

Den Port zu schließen ist keine Wiederherstellung

Wenn eine Kompromittierung bereits stattgefunden haben könnte, ist eine Änderung der Erreichbarkeit keine Wiederherstellung. Eine Hintertür, die ausgeführt wurde, hatte bereits ihre Gelegenheit; eine Firewall-Regel reist nicht in der Zeit zurück. Folgen Sie dem freigegebenen Incident-Prozess für den Host und für etwaige exponierte Zugangsdaten, und bewahren Sie die Beweise auf, die nötig sind, um festzustellen, was tatsächlich ausgeführt wurde. Ein Neuaufbau von bekannt einwandfreien Medien ist normalerweise Teil dieses Gesprächs.

Nutzen Sie auch die aktuelle verifizierte Empfehlung und den Behebungsprozess der Distribution und lesen Sie die Liste der betroffenen Versionen statt der Schlagzeile. Einen historischen Downgrade-Befehl in eine unabhängige Umgebung zu kopieren, ist der Weg, auf dem eine Korrektur zu einer neuen Exposition wird.

Prüfen Sie beides, getrennt

Stellen Sie die beiden Fragen in ihren eigenen Begriffen. Wer kann den Listener erreichen, und ist dieses Publikum genau das, für das der Dienst gedacht ist? Welche Version der Software ist installiert, wer hat das Artefakt signiert, und wie erfährt die Organisation von einer schlechten Veröffentlichung, bevor sie in den Nachrichten davon liest? Die Antworten gehören in verschiedene Dokumente mit verschiedenen Verantwortlichen, und keiner kann für den anderen antworten.

Für eine verwaltete Flotte ist ein Softwareinventar die Kontrolle, die die zweite Frage überhaupt beantwortbar macht. Ohne es wird jede Offenlegung zu einem Archäologieprojekt mit Frist.

Ein Tor verengt das Publikum. Integrität entscheidet, ob das Publikum zählt.