Runbook zur Gateway-Exposition

​

Freigabemuster auswählen

​

Bestandsaufnahme vor der Freigabe

• Gateway-Host, Betriebssystembenutzer und Zustandsverzeichnis (Standard: ~/.openclaw).
• Gateway-URL und Bindungsmodus (gateway.bind; Standardport: 18789).
• Authentifizierungsmodus, Quelle für Token/Passwort oder Identitätsquelle des vertrauenswürdigen Proxys.
• Jeder aktivierte Kanal und ob er Direktnachrichten, Gruppen oder Webhooks akzeptiert.
• Agenten, die für nicht lokale Absender erreichbar sind.
• Tool-Profil, Sandbox-Modus und Richtlinie für privilegierte Tools für jeden erreichbaren Agenten.
• Externe Anmeldedaten, die diesen Agenten zur Verfügung stehen.
• Sicherungsort für ~/.openclaw/openclaw.json und Anmeldedaten.

​

Grundlegende Prüfungen

openclaw doctor
openclaw security audit
openclaw security audit --deep
openclaw health

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

​

Minimaler sicherer Ausgangszustand

{
  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 },
  },
}

​

Freigabe von Direktnachrichten und Gruppen

• Bevorzugen Sie dmPolicy: "pairing" oder eine strikte allowFrom-Liste gegenüber dmPolicy: "open".
• Kombinieren Sie "*"-Zulassungslisten nicht mit umfassendem Tool-Zugriff.
• Verlangen Sie Erwähnungen in Gruppen, sofern der Raum nicht streng kontrolliert wird.
• Legen Sie session.dmScope: "per-channel-peer" (oder "per-account-channel-peer" für Kanäle mit mehreren Konten) fest, wenn mehrere Personen dem Bot Direktnachrichten senden können, damit Direktnachrichtensitzungen keinen Kontext gemeinsam nutzen.
• Leiten Sie gemeinsam genutzte Kanäle an Agenten mit minimalen Tools und ohne persönliche Anmeldedaten weiter.

​

Prüfungen für Reverse-Proxys

• Der Proxy muss Benutzer authentifizieren, bevor er Anfragen an den Gateway weiterleitet.
• Eine Firewall- oder Netzwerkrichtlinie muss den direkten Zugriff auf den Gateway-Port blockieren.
• gateway.trustedProxies darf ausschließlich die Quell-IP-Adressen des Proxys enthalten.
• Der Proxy muss vom Client bereitgestellte Identitäts- und Weiterleitungsheader entfernen oder überschreiben.
• Legen Sie gateway.auth.trustedProxy.allowUsers fest, wenn der Proxy mehr als eine Zielgruppe bedient.
• Verwenden Sie gateway.auth.trustedProxy.allowLoopback nur für einen Proxy auf demselben Host, wenn lokalen Prozessen vertraut wird und der Proxy die Identitätsheader kontrolliert.

​

Überprüfung von Tools und Sandbox

• Prüfen Sie, welche Sitzungen auf dem Host und welche in der Sandbox ausgeführt werden.
• Verweigern Sie die Ausführung auf dem Host oder verlangen Sie dafür eine Genehmigung.
• Lassen Sie privilegierte Tools deaktiviert, sofern sie nicht von einem bestimmten vertrauenswürdigen Absender benötigt werden.
• Vermeiden Sie Browser-, Canvas-, Node-, Cron-, Gateway- und Tools zum Erzeugen von Sitzungen für offene oder teilweise offene Messaging-Oberflächen.
• Beschränken Sie Bind-Mounts eng; vermeiden Sie Pfade zu Anmeldedaten, Home-Verzeichnissen, Docker-Sockets und Systempfaden.
• Verwenden Sie separate Gateways, Betriebssystembenutzer oder Hosts für wesentlich unterschiedliche Vertrauensgrenzen.

​

Validierung nach Änderungen

1. Führen Sie openclaw security audit --deep erneut aus.
2. Bestätigen Sie, dass eine autorisierte Verbindung erfolgreich hergestellt wird.
3. Bestätigen Sie, dass ein nicht autorisierter Absender oder eine nicht autorisierte Browsersitzung abgewiesen wird.
4. Bestätigen Sie, dass Geheimnisse in Protokollen unkenntlich gemacht werden.
5. Bestätigen Sie, dass die Weiterleitung von Direktnachrichten und Gruppen nur den vorgesehenen Agenten erreicht.
6. Bestätigen Sie, dass Tools mit hohen Auswirkungen eine Genehmigung anfordern oder abgewiesen werden.
7. Dokumentieren Sie die akzeptierten verbleibenden Warnungen.

​

Rücksetzplan

{
  gateway: {
    bind: "loopback",
  },
  channels: {
    whatsapp: { dmPolicy: "disabled" },
    telegram: { dmPolicy: "disabled" },
    discord: { dmPolicy: "disabled" },
    slack: { dmPolicy: "disabled" },
  },
  tools: {
    exec: { security: "deny", ask: "always" },
    elevated: { enabled: false },
  },
}

1. Beenden Sie öffentliche Weiterleitungen, Tailscale Funnel oder Reverse-Proxy-Routen.
2. Rotieren Sie Gateway-Token/-Passwörter und betroffene Integrationsanmeldedaten.
3. Entfernen Sie "*" und unerwartete Absender aus Zulassungslisten.
4. Überprüfen Sie aktuelle Audit-Protokolle, den Ausführungsverlauf, Tool-Aufrufe und Konfigurationsänderungen.
5. Führen Sie openclaw security audit --deep erneut aus.
6. Aktivieren Sie den Zugriff erneut mit dem restriktivsten Muster, das den Workflow erfüllt.

​

Prüfliste

• Der Gateway bleibt auf Loopback beschränkt, sofern kein dokumentierter Grund dagegen spricht.
• Zugriff außerhalb von Loopback verfügt über Authentifizierung und Firewall-Schutz sowie keinen direkten öffentlichen Pfad.
• Bereitstellungen mit vertrauenswürdigen Proxys verfügen über strikte Proxy-IP-Adressen und Header-Kontrollen.
• Direktnachrichten verwenden standardmäßig Kopplung oder Zulassungslisten statt offenen Zugriffs.
• Gruppen erfordern Erwähnungen oder ausdrückliche Zulassungslisten.
• Gemeinsam genutzte Kanäle können nicht auf persönliche Anmeldedaten zugreifen.
• Nicht-Hauptsitzungen werden im Sandbox-Modus ausgeführt.
• Die Ausführung auf dem Host und privilegierte Tools werden verweigert oder unterliegen einer Genehmigung.
• Geheimnisse werden in Protokollen unkenntlich gemacht.
• Kritische Audit-Befunde sind behoben.
• Rücksetzschritte sind getestet und dokumentiert.