Gateway

Gateway-Expositions-Runbook

Dieses Runbook überführt die allgemeinere Anleitung unter Sicherheit in eine Operator-Checkliste für Remotezugriff und Messaging-Freigabe.

Freigabemuster wählen

Bevorzugen Sie das engste Muster, das den Workflow erfüllt.

Muster	Empfohlen, wenn	Erforderliche Kontrollen
Loopback + SSH-Tunnel	Persönliche Nutzung, Adminzugriff, Debugging	`gateway.bind: "loopback"` beibehalten und `127.0.0.1:18789` tunneln
Loopback + Tailscale Serve	Persönlicher Tailnet-Zugriff auf Control UI/WebSocket	Gateway nur über Loopback erreichbar halten; Tailscale-Identity-Header nur für unterstützte Oberflächen verwenden
Tailnet/LAN-Bind	Dediziertes privates Netzwerk mit bekannten Geräten	Gateway-Auth, Firewall-Allowlist, kein öffentliches Port-Forwarding
Vertrauenswürdiger Reverse Proxy	Organisations-SSO/OIDC vor dem Gateway	`trusted-proxy`-Auth, strikte `trustedProxies`, Regeln zum Überschreiben/Entfernen von Headern, explizit erlaubte Benutzer
Öffentliches Internet	Seltene Hochrisiko-Deployments	Identity-aware Proxy, TLS, Ratenbegrenzungen, strikte Allowlists, isolierte Nicht-main-Sitzungen

Vermeiden Sie direktes öffentliches Port-Forwarding zum Gateway. Wenn Sie öffentlichen Zugriff benötigen, schalten Sie einen identity-aware Proxy davor und machen Sie den Proxy zum einzigen Netzwerkpfad zum Gateway.

Preflight-Inventar

Notieren Sie Folgendes, bevor Sie Bind-, Proxy-, Tailscale- oder Channel-Richtlinien ändern:

Gateway-Host, OS-Benutzer und State-Verzeichnis.
Gateway-URL und Bind-Modus.
Auth-Modus, Token-/Passwortquelle oder Identity-Quelle des vertrauenswürdigen Proxys.
Alle aktivierten Channels und ob sie DMs, Gruppen oder Webhooks akzeptieren.
Agenten, die von nicht lokalen Absendern erreichbar sind.
Tool-Profil, Sandbox-Modus und Richtlinie für erhöhte Tools für jeden erreichbaren Agenten.
Externe Zugangsdaten, die diesen Agenten zur Verfügung stehen.
Backup-Speicherort für ~/.openclaw/openclaw.json und Zugangsdaten.

Wenn mehr als eine Person dem Bot Nachrichten senden kann, behandeln Sie dies als gemeinsam delegierte Tool-Berechtigung, nicht als hostseitige Isolation pro Benutzer.

Basisprüfungen

Führen Sie diese aus, bevor Sie Zugriff öffnen:

bash

openclaw doctoropenclaw security auditopenclaw security audit --deepopenclaw health

Beheben Sie kritische Befunde zuerst. Warnungen können nur akzeptabel sein, wenn sie absichtlich sind und für das Deployment dokumentiert wurden.

Übergeben Sie Zugangsdaten für die Remote-CLI-Validierung explizit:

bash

openclaw gateway probe --url ws://127.0.0.1:18789 --token "$OPENCLAW_GATEWAY_TOKEN"

Gehen Sie nicht davon aus, dass lokale Konfigurations-Zugangsdaten für eine explizite Remote-URL gelten.

Sichere Mindestbasis

Verwenden Sie diese Form als Ausgangspunkt für freigegebene Deployments:

json5

{  gateway: {    bind: "loopback",    auth: {      mode: "token",      token: "replace-with-a-long-random-token",    },  },  session: {    dmScope: "per-channel-peer",  },  agents: {    defaults: {      sandbox: { mode: "non-main" },    },  },  tools: {    profile: "messaging",    exec: { security: "deny", ask: "always" },    elevated: { enabled: false },  },}

Weiten Sie anschließend jeweils nur eine Kontrolle aus. Fügen Sie beispielsweise eine spezifische Channel-Allowlist hinzu, bevor Sie schreibfähige Tools aktivieren, oder aktivieren Sie einen Reverse Proxy, bevor Sie Remote-Control-UI-Traffic akzeptieren.

Die strikte Basis exec.security: "deny" blockiert alle Exec-Aufrufe, einschließlich harmloser Diagnosen. Wenn Diagnosen oder Befehle mit geringem Risiko erforderlich sind, lockern Sie dies erst, nachdem Sie die konkreten Absender, Agenten, Befehle und den Genehmigungsmodus gewählt haben, die zu Ihrem Bedrohungsmodell passen.

DM- und Gruppenfreigabe

Messaging-Channels sind nicht vertrauenswürdige Eingabeoberflächen. Bevor Sie DMs oder Gruppen zulassen:

Bevorzugen Sie dmPolicy: "pairing" oder strikte allowFrom-Listen.
Vermeiden Sie dmPolicy: "open", sofern nicht jeder Absender vertrauenswürdig ist.
Kombinieren Sie "*"-Allowlists nicht mit breitem Tool-Zugriff.
Verlangen Sie Erwähnungen in Gruppen, sofern der Raum nicht streng kontrolliert ist.
Verwenden Sie session.dmScope: "per-channel-peer", wenn mehrere Personen dem Bot DMs senden können.
Leiten Sie gemeinsame Channels an Agenten mit minimalen Tools und ohne persönliche Zugangsdaten.

Pairing berechtigt den Absender, den Bot auszulösen. Es macht diesen Absender nicht zu einer separaten Host-Sicherheitsgrenze.

Reverse-Proxy-Prüfungen

Für identity-aware Proxys:

Der Proxy muss Benutzer authentifizieren, bevor er an den Gateway weiterleitet.
Direkter Zugriff auf den Gateway-Port muss durch Firewall oder Netzwerkrichtlinie blockiert sein.
gateway.trustedProxies darf nur die Quell-IPs des Proxys enthalten.
Der Proxy muss vom Client gelieferte Identity- und Forwarding-Header entfernen oder überschreiben.
gateway.auth.trustedProxy.allowUsers sollte die erwarteten Benutzer auflisten, wenn der Proxy mehr als eine Zielgruppe bedient.
Same-Host-Loopback-Proxy-Modus sollte allowLoopback nur verwenden, wenn lokale Prozesse vertrauenswürdig sind und der Proxy die Identity-Header kontrolliert.

Führen Sie nach Proxy-Änderungen openclaw security audit --deep aus. Trusted-Proxy-Befunde sind absichtlich hochsignalig, weil der Proxy zur Authentifizierungsgrenze wird.

Tool- und Sandbox-Review

Bevor Sie einen Agenten für Remote-Absender freigeben:

Bestätigen Sie, welche Sitzungen auf dem Host und welche in der Sandbox laufen.
Verweigern Sie Host-Exec oder verlangen Sie dafür eine Genehmigung.
Lassen Sie erhöhte Tools deaktiviert, sofern kein spezifischer, vertrauenswürdiger Absender sie benötigt.
Vermeiden Sie Browser-, Canvas-, Node-, Cron-, Gateway- und Session-Spawn-Tools für offene oder halb offene Messaging-Oberflächen.
Halten Sie Bind-Mounts eng begrenzt und vermeiden Sie Pfade zu Zugangsdaten, Home, Docker-Socket und Systempfaden.
Verwenden Sie separate Gateways, OS-Benutzer oder Hosts für wesentlich unterschiedliche Vertrauensgrenzen.

Wenn Remote-Benutzer nicht vollständig vertrauenswürdig sind, muss die Isolation aus separaten Deployments entstehen, nicht nur aus Prompts oder Sitzungslabels.

Validierung nach Änderungen

Nach jeder Freigabeänderung:

Führen Sie openclaw security audit --deep erneut aus.
Testen Sie eine erfolgreiche autorisierte Verbindung.
Testen Sie, dass ein nicht autorisierter Absender oder eine nicht autorisierte Browsersitzung abgewiesen wird.
Bestätigen Sie, dass Logs Geheimnisse redigieren.
Bestätigen Sie, dass DM-/Gruppen-Routing nur den beabsichtigten Agenten erreicht.
Bestätigen Sie, dass Tools mit hoher Auswirkung um Genehmigung bitten oder verweigert werden.
Dokumentieren Sie die akzeptierten verbleibenden Warnungen.

Fahren Sie nicht mit der nächsten Freigabeänderung fort, bis die aktuelle verstanden ist.

Rollback-Plan

Wenn der Gateway möglicherweise übermäßig freigegeben ist: