Reaktion auf Tailworm: wie wir unser Tailscale-Netzwerk gehärtet haben, ohne die Produktion zu stören

Wie wir unser Tailscale-Netzwerk anhand der Tailworm-Befunde geprüft, die Tailscale-SSH-Angriffsfläche entfernt und alle Produktionsjobs am Laufen gehalten haben.

Zusammenfassung

Am 25. Oktober 2026 veröffentlichte ein Sicherheitsforscher „Tailworm“: 11 Befunde zu Tailscale und headscale, veröffentlicht ohne koordinierte Offenlegung (coordinated disclosure). Zum Zeitpunkt der Erstellung dieses Beitrags hat Tailscale noch keinen Fix veröffentlicht. Noch am selben Abend haben wir unser eigenes Tailscale-Netzwerk anhand jedes einzelnen Befunds geprüft. Wir haben die einzige Schwachstelle entfernt, die uns betraf, die Zugriffe verschärft und alle Produktionsjobs durchgehend weiterlaufen lassen.

Dieser Beitrag beschreibt, was wir geprüft und geändert haben, wie wir einen Ausfall vermieden haben und was wir daraus gelernt haben. Er ist keine unabhängige Überprüfung des Berichts.

Was Tailworm gemeldet hat – kurz zusammengefasst

Die 11 Befunde lassen sich in einige Gruppen einteilen:

• Tailscale SSH (am schwerwiegendsten). Eine autorisierte SSH-Sitzung ließ sich auf dem Zielrechner zu root-Rechten ausweiten. Im Labor des Forschers breitete sich der Angriff anschließend von Rechner zu Rechner aus.
• App connectors. Ziele (Destinations) werden nicht validiert.
• Speichererschöpfung, im Steuerungsserver und in den Clients.
• Grenzfälle bei Serve und Funnel.

Jeder Befund setzt voraus, dass ein Angreifer bereits Fuß gefasst hat. Keiner davon ist ein Fernangriff aus dem Internet. Manche Sicherheitsexperten halten die Darstellung für übertrieben, doch die Hauptschwachstelle, Tailscale SSH, ist real und leicht zu beseitigen.

Schritt 1: Erst prüfen, dann ändern

Wir begannen mit rein lesenden Prüfungen und dokumentierten die Ergebnisse, bevor wir irgendetwas anfassten:

• die eingesetzten Versionen des Tailscale-Clients
• welche Funktionen tatsächlich aktiviert waren
• SSH-Sitzungsprotokolle aus 60 Tagen, um zu sehen, wer sich von wo verbunden hatte und ob jemand Port- oder Socket-Weiterleitung genutzt hatte
• die Geräteliste, einschließlich Geräten, die seit Monaten nicht mehr online gewesen waren

Ergebnisse:

• Tailscale SSH war in einem Teil unserer Umgebung aktiviert, daher waren die Befunde F1–F3 und F5 für uns relevant.
• Die Funktionen, auf denen die übrigen Befunde beruhen, waren nicht im Einsatz; die meisten trafen also nicht zu.
• Die SSH-Protokolle zeigten keine unerwarteten Quellen und keine Weiterleitungsanfragen.

Schritt 2: Die Schwachstelle ohne Ausfall beseitigen

Die naheliegende Lösung war, Tailscale SSH abzuschalten und stattdessen die übliche Schlüsselauthentifizierung von OpenSSH zu verwenden. Unsere Vorabprüfung deckte jedoch eine Falle auf.

Tailscale SSH authentifiziert über die Identität im tailnet, nicht über den SSH-Schlüssel. Unsere Automatisierungsskripte übergaben zwar einen SSH-Schlüssel auf der Kommandozeile, doch dieser war mit einer Passphrase geschützt und hätte unbeaufsichtigt nie funktionieren können. Die Jobs liefen nur, weil Tailscale SSH den Schlüssel gar nicht beachtete. Hätten wir Tailscale SSH einfach abgeschaltet, wären alle automatisierten Jobs stehen geblieben.

Deshalb sind wir bei der Umstellung in dieser Reihenfolge vorgegangen:

1. Einen eigenen Schlüssel für die Automatisierung erstellt, beschränkt auf einen einzigen Quellrechner und mit deaktivierter Weiterleitung.
2. Den neuen Weg vor der Umstellung getestet. Wir öffneten einen temporären OpenSSH-Port, der nur innerhalb des tailnet erreichbar war, und verbanden uns aus einer Umgebung wie der unserer Jobs (kein SSH-Agent, kein Terminal) – auf jede Art, wie unsere Skripte SSH aufrufen.
3. Negativtests durchgeführt. Der neue Schlüssel wurde außerhalb seiner erlaubten Quelle abgewiesen, und Weiterleitungsanfragen wurden abgelehnt.
4. Zuerst einen automatischen Rollback eingerichtet. Bevor wir Tailscale SSH abschalteten, planten wir einen Timer, der es von selbst wieder einschalten würde. Dieser Wiederherstellungsweg hing nicht davon ab, dass SSH funktioniert.
5. Umgestellt und dann jeden automatisierten Job mit neuen Verbindungen geprüft. Jeder Job schloss einen echten Durchlauf ab. Eine bereits offene Sitzung haben wir nicht als Beweis gelten lassen.
6. Die temporären Elemente entfernt – den zusätzlichen Port, die Firewall-Regel und den Rollback-Timer – und noch einmal geprüft.

Schritt 3: Den Rest verschärfen

• Die Tailscale-SSH-Richtlinie geleert. Die Standardrichtlinie erlaubte es jedem Gerät eines Benutzers, SSH-Sitzungen zu dessen anderen Geräten zu öffnen, auch als root, nach einer wöchentlichen erneuten Bestätigung im Browser. Wir haben sie geleert, sodass ein versehentliches Wiedereinschalten von Tailscale SSH keinen Zugriff mehr gewährt.
• SSH zum Internet hin geschlossen. Vorher haben wir bestätigt, dass die Anmeldung über eine Out-of-Band-Konsole funktioniert, damit wir uns nicht selbst aussperren. Danach haben wir aus einem externen Netzwerk überprüft, dass SSH nicht mehr antwortet.
• Gerätefreigabe verpflichtend gemacht. Neue Geräte müssen von einem Administrator freigegeben werden, bevor sie beitreten können.
• Registrierungsschlüssel geprüft. Es gab keine, die widerrufen werden mussten.
• MFA für das Administratorkonto bestätigt. Kontrollen auf Netzwerkebene kann jeder rückgängig machen, der die Administratoranmeldung übernimmt.
• Begonnen, den tatsächlichen Verkehr zwischen Geräten zu beobachten, damit der nächste Schritt – einzuschränken, welche Geräte mit welchen Diensten kommunizieren dürfen – auf Fakten statt auf Vermutungen beruht.

Tailnet Lock und die Gerätefreigabe schützen beide davor, dass ein fremdes Gerät beitritt, lassen sich aber nicht gemeinsam verwenden. Entscheiden Sie sich daher bewusst für eine der beiden Optionen.

Schritt 4: Das Runbook korrigieren, nicht nur den Server

Unser altes Wiederherstellungsverfahren sah vor, den Server mit aktiviertem Tailscale SSH neu zu verbinden. Wäre man ihm nach dieser Änderung gefolgt, hätte es die riskante Funktion unbemerkt zurückgebracht. Wir haben es neu geschrieben:

• Zuerst diagnostizieren. Ist die Netzwerkverbindung unterbrochen, oder liegt das Problem bei SSH selbst (Schlüssel, Konfiguration, Firewall)? Beides wird unterschiedlich behoben.
• Neu verbinden, ohne Einstellungen zu ändern. Keine zusätzlichen Flags verwenden, die Einstellungen des Knotens vor dem Neuverbinden sichern und danach vergleichen.
• Notfallzugang nur mit Timer öffnen. Vorher eine Freigabe einholen, vor dem Öffnen ein automatisches Schließen planen, die Quelle einschränken und IPv4 sowie IPv6 prüfen.
• Tailscale SSH auch im Notfall nicht wieder aktivieren. Die dafür nötige Änderung der Zugriffsrichtlinie lässt sich nicht automatisch zurücknehmen.

Was wir gelernt haben

1. Wissen Sie, was eine Sicherheitsfunktion tatsächlich authentifiziert, bevor Sie sie entfernen. Der Schlüssel, den unsere Skripte angaben, war nie verwendet worden.
2. Testen Sie genau den Weg, auf den Sie umstellen, in derselben Umgebung, in der Ihre Jobs laufen, und zwar vor der Umstellung.
3. Richten Sie einen Rollback ein, der nicht von dem abhängt, was Sie gerade ändern. Einen Timer, nicht „wir loggen uns dann per SSH ein und reparieren es“.
4. Prüfen Sie den Wiederherstellungszugang, bevor Sie eine Tür schließen. Wir haben den Konsolenzugang bestätigt, bevor wir SSH zum Internet hin geschlossen haben.
5. Aktualisieren Sie das Runbook in derselben Änderung. Ein alter Wiederherstellungsschritt kann eine Sicherheitskorrektur Monate später wieder aufheben.
6. Lesen Sie die Standardrichtlinien. „Eigene Geräte erlauben, einschließlich root“ war die Voreinstellung, mit der wir begonnen haben.
7. Trennen Sie „die Änderung hat funktioniert“ von „die Schwachstelle ist behoben“. Den Tailscale-SSH-Befunden sind wir nicht mehr ausgesetzt, aber Tailworm als Ganzes ist erst abgeschlossen, wenn die Upstream-Fixes erscheinen. Dann werden wir unsere Clients aktualisieren.
8. Erst messen, dann einschränken. Beobachteter Verkehr und eine Liste realer Abhängigkeiten kommen vor strengeren Zugriffsregeln, damit die Härtung den Geschäftsbetrieb nicht beeinträchtigt.

Wie es weitergeht

Wir schränken den Netzwerkzugriff zwischen Geräten auf Basis des beobachteten Verkehrs auf das Minimum ein, das jeder Dienst benötigt. Die Fixes von Tailscale werden wir installieren, sobald sie veröffentlicht sind.

Quellen: der Tailworm-Bericht (tailworm.com) und die Tailscale-Dokumentation zu Tailnet Lock.