Ein SSH-Bastion für 43 Maschinen: warum Warpgate und wie wir es eingeführt haben

Stellen Sie einem beliebigen Administrator die Frage: „Wer hat sich letzten Dienstag an diesem Server angemeldet, und was hat er dort getan?“ Beginnt die Antwort mit „Da müsste man ins Authentifizierungsprotokoll der Maschine schauen“, haben Sie keinen Bastion. Und wurde die Maschine kompromittiert, ist dieses Protokoll nichts mehr wert. Genau so war es bei uns, mit einer Serverflotte von mehr als vierzig Maschinen. Wie wir da an einem Tag mit Warpgate herausgekommen sind, lesen Sie hier.

Das Problem war nicht der Zugang, sondern die Spur #

Auf dem Papier war unser Zugang sauber: nur Schlüssel, keine Passwörter, überall fail2ban. Doch bei der Prüfung der autorisierten Schlüssel der Flotte zählten wir drei Werkzeugschlüssel auf jeder Maschine (unseren, den der Konsole, den des Automatisierungsagenten), mit bis zu sechs Kopien desselben Schlüssels auf einem Hypervisor, im Lauf der Jahre dort abgelegt. Jeder Schlüssel öffnete zweiundvierzig Türen. Und es gab keine zentrale Spur: Um zu wissen, was eine Sitzung getan hatte, musste man dem Protokoll der Maschine selbst vertrauen. Die Hygienemaßnahmen der ANSSI, der französischen Cybersicherheitsbehörde, die wir uns auferlegt hatten, sind hier eindeutig: Administration über einen eigenen Zugangspunkt, zentrale Protokollierung, personenbezogene Konten. Wir erfüllten die Hälfte.

Warum Warpgate #

Warpgate ist ein Open-Source-Bastion in Rust, geschrieben vom Autor von Tabby. Seine wichtigste Eigenschaft: Er kommt ohne Client aus. Nichts auf den Arbeitsplätzen zu installieren, kein Agent auf den Servern. Er sitzt im Datenpfad: Man verbindet sich mit ihm, er leitet mit seinen eigenen Schlüsseln zum Ziel weiter und zeichnet jede Sitzung abspielbar auf. Die Adressierung steckt im SSH-Benutzernamen: ssh moi:cible@bastion -p 2222. Er beherrscht OIDC und damit auch unseren IdP Authentik; er verwaltet Zugriffsrollen pro Ziel; er bietet eine vollständige API. Und er ist schlank: ein Container, eine SQLite-Datenbank, ein paar Dutzend Megabyte. Die Alternativen, die wir uns angesehen haben, waren entweder kommerzielle Produkte, die für vierzig Maschinen überdimensioniert sind, oder klassische SSH-Sprung-Hosts, die nichts protokollieren.

Ein Bastion gehört nicht auf das, was er administriert #

Zuerst haben wir ihn auf einer VM in unserem privaten Administrationsnetz installiert. Noch am selben Abend zog er auf einen eigenen VPS um, unter eigenem Namen. Aus zwei Gründen. Der erste ist praktisch: Ein Bastion, der nur aus einem lokalen Netz erreichbar ist, verhindert jeden Zugang von unterwegs und macht die Leitung dieses Netzes zum Single Point of Failure. Der zweite ist grundsätzlich: Der Bastion darf nicht von der Infrastruktur abhängen, die er administriert. Läuft er auf dem Cluster, den er öffnet, nimmt Ihnen ein Ausfall des Clusters genau den Zugang, den Sie für die Reparatur brauchen. Migration im laufenden Betrieb für die Aufzeichnungen, im ausgeschalteten Zustand für die Datenbank: drei Minuten Unterbrechung, und der SSH-Hostschlüssel zieht mit den Daten um, also keine Warnung auf Seiten der Clients.

⟷ seitlich scrollen

Rollen: keine Sammelrolle #

Warpgate unterscheidet zwei Dinge, die oft verwechselt werden: Gruppen von Zielen (zur Organisation: Name, Farbe, Beschreibung) und Rollen (Rechte). Unser erster Reflex war eine einzige Rolle mit Zugang zu allem. Wir haben sie gelöscht: Eine Sammelrolle hebt jede Feinsteuerung auf. Die Flotte ist in fünf Rollen aufgeteilt: infra-pure (die drei Hypervisoren und der Backup-Server), service (23 Basismaschinen: Edge, DNS, IdP, Tresore, Mail), app (11 gehostete Anwendungen) und zwei Rollen für die betreuten Kundenmaschinen. Ein Mitarbeiter, der nur an den Hypervisoren arbeitet, erhält infra-pure und sonst nichts. Beachten Sie das Paradox: Es ist die zahlenmäßig kleinste Rolle und zugleich die mit der größten Reichweite, denn root auf einem Hypervisor kontrolliert alle seine Gäste.

Automatisierungsagenten haben ihr eigenes Konto #

Wir administrieren diese Flotte mit Hilfe eines KI-Agenten, und der nutzte anfangs das Token eines Menschen: Alles, was er tat, wurde diesem Menschen zugeschrieben, ein Rückschritt gegenüber dem direkten SSH-Zugang, bei dem er einen eigenen Schlüssel hatte. Er erhielt deshalb ein eigenes Konto in Warpgate: Anmeldung nur per Schlüssel (was ihm die Weboberfläche faktisch verschließt), eine einzige zugelassene Quell-IP-Adresse, keine Administratorrolle und Zugriffsrollen, die Ziel für Ziel erweitert werden, nie pauschal. Das Audit unterscheidet nun den Agenten vom Menschen. Und als der Benutzer entschied, dass „der Agent nicht der Notzugang der Flotte sein soll“, wurde sein direkter Schlüssel von den zweiundvierzig Maschinen entfernt. Danach auch sein Zugang zum Bastion selbst, der als zu sensibel galt: Das ist die Maschine, die die Identität von allem anderen trägt.

Die Bereinigung der Schlüssel, in der richtigen Reihenfolge #

Der eigentliche Gewinn kommt erst am Ende: Solange die alten Schlüssel auf den Servern bleiben, ist der Bastion nur ein weiterer, dritter Schlüssel. Wir haben deshalb Maschine für Maschine und mit Sicherung zuerst den Schlüssel der Konsole entfernt (er dient nur noch dazu, sich beim Bastion auszuweisen), dann den des Agenten: 66 Zeilen gelöscht. Bei jedem Schritt Prüfung in beide Richtungen: direkter Zugang verweigert, 42 von 42 Verbindungen über den Bastion. Auf der Flotte verbleiben der Client-Schlüssel von Warpgate, der unseres Deployment-Servers und ein Offline-Notfallschlüssel auf den öffentlich erreichbaren Maschinen, dessen Verwendung in unserem SIEM einen Alarm der höchsten Stufe auslöst. Das Sicherheitsnetz besteht jetzt aus dem lokalen Konto des Bastions, der Konsole der Hypervisoren und der Managementkarte der dedizierten Server.

Die Fallstricke, die uns jeweils einen zusätzlichen Anlauf gekostet haben #

• Das Image läuft mit dem Benutzer 1000. Ein Datenverzeichnis, das root gehört, lässt die Installation mit einem „permission denied“ scheitern, das nicht verrät, dass es sich um ein Eigentümerproblem handelt.
• Der Image-Tag lautet 0.28.6, nicht v0.28.6; das Git-Repository trägt das v, die Registry nicht. Und den Befehl für die nicht interaktive Installation gibt es, obwohl er nicht dokumentiert ist: Genau ihn brauchen Sie für eine reproduzierbare Installation.
• Der externe Host darf den Port nicht enthalten, anders als die Dokumentation behauptet: Das Binary ignoriert ihn stillschweigend, und die SSO-Rücksprung-URL geht ohne Port hinaus, was ein 400 des IdP zur Folge hat. Der Port hat einen eigenen Parameter, und bleibt dieser leer, fällt er auf den internen Lauschport zurück, nicht auf 443.
• Die OIDC-Issuer-URL muss zeichengenau mit der im Discovery-Dokument übereinstimmen, einschließlich des abschließenden Schrägstrichs. Das eingebaute Prüfwerkzeug erkennt diesen Fehler nicht: Erst ein Test im Browser deckt ihn auf.
• Warpgate verlangt eine verifizierte E-Mail-Adresse vom IdP. Ein neues Konto ohne dieses Attribut wird ohne hilfreiche Erklärung abgewiesen. Setzen Sie es, bevor Sie jemanden einladen.
• Ein per SSO angelegtes Konto hat keinerlei Administrationsrechte. Das Token ist gültig, die API antwortet auf alles mit 401: Die Administratorrolle muss ausdrücklich vergeben werden. Und beachten Sie: Ein API-Token ist nie „nur lesend“. Es erlaubt, dem Konto einen Schlüssel hinzuzufügen oder ihm den zweiten Faktor zu entziehen. Wer das Token hat, hat das Konto.
• Die Prüfung des Hostschlüssels verlangt ein Terminal. Eine nicht interaktive Verbindung zu einem unbekannten Ziel kehrt ohne Ausgabe und ohne Fehlercode zurück, was nach einem Netzwerkproblem aussieht. Der richtige Weg ist die Administrations-API, nachdem Sie den Schlüssel mit einer unabhängigen Quelle verglichen haben: Das ist ein Moment blinden Vertrauens, speichern Sie ihn nicht ohne Gegenprüfung.
• Kein integriertes ACME: ein eigenständiges certbot und ein Deployment-Skript, das das Zertifikat kopiert und den Container neu startet.

Damit leben: Überwachung, Wachstum, tote Winkel #

Der Bastion ist zum kritischsten Punkt der Flotte geworden, also wird er auch so überwacht: Verfügbarkeitsprüfungen, Metriken, ein eigenes Dashboard für die Authentifizierungskette (Bastion und IdP) und ein SIEM-Agent, der nützlichste von allen, da er die Spur sämtlicher Zugriffe trägt. Die Aufzeichnungen wachsen um etwa 5 MB und 380 Dateien pro Tag, mit einer integrierten Audit-Aufbewahrung von einem Jahr: Die 40-GB-Festplatte reicht für mehr als zwei Jahre. Ein bewusst in Kauf genommener toter Winkel: Zwei Maschinen in unserem privaten Administrationsnetz sind von einem Bastion im Internet aus strukturell nicht erreichbar und behalten einen direkten Zugang, ohne Spur. Wir sagen das lieber offen, als es zu verschweigen.

„Wer hat was, wo und wann getan?“ ist die erste Frage, die ein Kunde, ein Versicherer oder ein Auditor nach einem Vorfall stellt. Sie zu beantworten, indem man die Sitzung abspielt, statt verstreute Protokolle zu durchsuchen, gehört zu dem, was wir unter gewissenhaften Managed Services verstehen. Wenn Ihre heutige Antwort in einer Datei authorized_keys steckt, die seit zwei Jahren niemand mehr gelesen hat, sprechen wir darüber.