DanLevy.net

DE

Dein KI-Assistent gab mir Shell-Zugriff

So sicherst du deine lokale oder VPS-OpenClaw/Moltbot-Installation ab

OpenClaw (früher Clawdbot/Moltbot) gibt dir einen persönlichen KI-Assistenten, der über WhatsApp, Slack, Discord, iMessage und andere Kanäle funktioniert. Aber wenn du sein Gateway, die Node-Steuerung oder SSH ohne starke Authentifizierung ins öffentliche Internet stellst, schenkst du Fremden einen Pfad zu Shell-Zugriff auf deinem Rechner.

Diese Anleitung zeigt den sichersten Standard: Lasse das OpenClaw-Gateway auf Loopback, gib es nur mit Tailscale Serve für dein Tailnet frei, schotte SSH ab und überprüfe von außen, dass das Gateway nicht öffentlich ist.

Die schnelle Verbreitung des Projekts hat echte Sicherheitsbedenken offengelegt: Shodan-Scans fanden 2.847 offene Instanzen in den ersten Wochen, und ein GitHub-Sicherheitsaudit meldete 512 Befunde im Codebestand. Einiges davon stammte von automatischen Scannern, und einiges hat sich seit der Umbenennung zu OpenClaw im Januar 2026 geändert. Betrachte die Zahl also eher als Warnsignal denn als präzise aktuelle Schwachstellenzahl. Du musst kein Sicherheitsexperte sein – du musst nur vermeiden, Operator-Oberflächen zu veröffentlichen, bevor du es bereitstellst.

Was du tatsächlich freigibst

Abhängig davon, wie du installiert und freigegeben hast, gibt es drei Oberflächen, die eine Überprüfung wert sind:

Die aktuellen OpenClaw-Remote-Access-Dokumente besagen, dass der Gateway-WebSocket standardmäßig an Loopback bindet, und empfehlen, ihn nur dort zu belassen, es sei denn, du wählst bewusst ein LAN-/Tailnet-/benutzerdefiniertes Binding. Das ist gut. Das Risiko entsteht, wenn du diese Voreinstellung überschreibst, Docker-Ports veröffentlichst, einen Reverse-Proxy hinzufügst, Funnel aktivierst oder SSH weltweit offen lässt.

Das Gateway ist der wichtigste Punkt. Es ist die Operator-Oberfläche für deinen Assistenten, einschließlich der Tool-Aufruf-Pfade. Wenn es aus dem Internet erreichbar ist und die Authentifizierung fehlt, schwach, umgangen oder durchgesickert ist, kann ein Angreifer möglicherweise den Agenten steuern oder Tools mit den Berechtigungen deines Benutzerkontos aufrufen.

Die Browser-Steuerung ist fast genauso sensibel. Die aktuellen OpenClaw-Dokumente empfehlen, die Browser-Steuerung über einen gepaarten Node-Host auf dem Browser-Rechner auszuführen und die Node-Paarung wie Operator-Zugriff zu behandeln. Wenn ein Gateway system.run auf einem gepaarten Node aufrufen kann, bedeutet das Remote-Code-Ausführung auf diesem Node, vorbehaltlich der Gateway-Node-Richtlinie und der eigenen Ausführungsgenehmigungen des Nodes.

SSH ist SSH. Wenn du mit aktivierter Passwort-Authentifizierung arbeitest, sind Brute-Force-Versuche auf einem öffentlichen VPS unvermeidlich.

Die Tailscale-Lösung

Für OpenClaw bietet Tailscale Remote-Zugriff, ohne Operator-Dienste zu veröffentlichen:

  1. Deine OpenClaw-Instanz läuft auf einem VPS oder einem lokalen Rechner
  2. Das Gateway bleibt an Loopback gebunden und wird über Tailscale Serve erreicht, oder es bindet direkt an die Tailnet-IP mit expliziter Authentifizierung
  3. Du installierst Tailscale sowohl auf dem Server als auch auf deinen persönlichen Geräten
  4. Du greifst über die Tailscale-IP oder den MagicDNS-Namen auf OpenClaw zu
  5. Alle anderen im Internet sehen nichts, es sei denn, du aktivierst absichtlich Funnel oder einen anderen öffentlichen Proxy

Solltest du OpenClaw die Tailscale-Verwaltung überlassen?

OpenClaw verfügt über eine integrierte Tailscale-Integration, die tailscale serve oder tailscale funnel für das Gateway konfigurieren kann.

Der Serve-Modus hält die Dinge ausschließlich in deinem Tailnet. Das Gateway bleibt an 127.0.0.1 gebunden, während Tailscale das Routing und HTTPS übernimmt. Wenn gateway.auth.allowTailscale aktiviert ist, kann OpenClaw den Control-UI-/WebSocket-Verkehr mithilfe von Tailscale-Identitäts-Headern authentifizieren und die Quelle mit tailscale whois verifizieren. Dies ist der richtige Modus für die meisten persönlichen Installationen.

Der Funnel-Modus gibt das Gateway über die öffentliche Endpunktfunktion von Tailscale öffentlich frei. Die Dokumentation von Tailscale beschreibt Funnel als das Routing von Verkehr aus dem breiteren Internet zu einem lokalen Dienst. OpenClaw weigert sich, Funnel zu starten, wenn der Gateway-Authentifizierungsmodus nicht auf password eingestellt ist, aber du entscheidest dich immer noch für eine öffentliche Freigabe einer Operator-Oberfläche.

Die Sicherheitsdokumentation von OpenClaw macht deutlich, dass Prompt-Injection und Tool-Zugriff Kernrisiken für einen persönlichen Assistenten sind. Gib dem Agenten keinen Pfad, um sich stillschweigend selbst öffentlich zu machen. Nutze Serve bewusst, vermeide Funnel, es sei denn, du benötigst wirklich öffentlichen Zugriff, und verlange eine Ausführungsgenehmigung für jeden tailscale-Befehl.

OpenClaw sicher einrichten

Schritt 1: Tailscale installieren

Auf deinem VPS oder lokalen Server:

Terminal window
# Tailscale installieren
curl -fsSL https://tailscale.com/install.sh | sh


# Authentifizieren (öffnet einen Browser zum Einloggen)
sudo tailscale up


# Deine Tailscale-IP abrufen
tailscale ip -4
# Ausgabe: 100.x.x.x

Installiere Tailscale auf deinem Client-Rechner von der offiziellen Download-Seite und melde dich im selben Tailnet an.

Jetzt befinden sich beide Rechner im selben privaten Netzwerk. Du kannst deinen VPS über seine Tailscale-IP anpingen, und der Verkehr wird durch den verschlüsselten Tunnel geroutet.

Schritt 2: OpenClaw für die Verwendung von Tailscale konfigurieren

Das sicherste aktuelle Muster ist: Behalte das Gateway auf Loopback und gib es über Tailscale Serve für dein Tailnet frei.

In der OpenClaw-Konfiguration:

{
  gateway: {
    bind: "loopback",
    tailscale: { mode: "serve" },
  },
}

Starte dann das Gateway mit Serve:

Terminal window
openclaw gateway --tailscale serve

Die Dokumentation von OpenClaw besagt, dass dies das Gateway auf 127.0.0.1 belässt, während Tailscale HTTPS und Tailnet-Routing bereitstellt. Du öffnest es unter https://<magicdns-name>/, nicht über deine öffentliche VPS-IP.

Wenn du ein direktes Tailnet-Binding anstelle von Serve bevorzugst, verwende eine explizite Gateway-Authentifizierung:

{
  gateway: {
    bind: "tailnet",
    auth: {
      mode: "token",
      token: "ersetze-dies-durch-einen-langen-zufälligen-token",
    },
  },
}

Verbinde dich dann von einem anderen Tailnet-Gerät aus:

http://<tailscale-ip>:18789/
ws://<tailscale-ip>:18789

Wenn du in Docker oder einer anderen Container-Laufzeitumgebung arbeitest, sei besonders vorsichtig mit der Port-Freigabe. Eine Freigabe wie -p 18789:18789 bindet normalerweise an alle Host-Schnittstellen. Bevorzuge Loopback plus Tailscale Serve oder binde die Host-Seite explizit an die Tailscale-IP, nachdem du bestätigt hast, dass der Container weiterhin Verkehr empfängt:

Terminal window
TAILSCALE_IP=$(tailscale ip -4)
docker run ... -p "$TAILSCALE_IP:18789:18789" ...

Überprüfe nach jeder Docker-Änderung von außen mit nmap und lokal mit ss. Docker kann Host-Firewall-Annahmen umgehen oder neu ordnen, wenn du dies nicht berücksichtigst.

Schritt 3: SSH abschotten

Auch mit Tailscale solltest du SSH ordnungsgemäß absichern:

Terminal window
# Halte deine aktuelle SSH-Sitzung währenddessen offen.
# Bestätige zuerst von deinem Client-Rechner aus, dass du über Tailscale per SSH zugreifen kannst:
ssh dein-benutzer@SERVER_TAILSCALE_IP


# Packe die Härtung in eine Drop-in-Datei, anstatt die sshd_config zu überschreiben.
sudo tee /etc/ssh/sshd_config.d/99-openclaw-hardening.conf >/dev/null <<'EOF'
PasswordAuthentication no
PermitRootLogin no
KbdInteractiveAuthentication no
EOF


# Vor dem Neuladen validieren. Überspringe dies nicht.
sudo sshd -t
sudo systemctl reload ssh || sudo systemctl reload sshd

Dies deaktiviert die passwortbasierte Anmeldung und die Root-Anmeldung. Der nächste Schritt verwendet UFW, um öffentliches SSH vollständig zu verhindern, während SSH über tailscale0 weiterhin erlaubt bleibt.

Schritt 4: Firewall-Regeln

Richte eine Firewall als zweite Ebene ein:

Terminal window
# Verwendung von UFW (Ubuntu/Debian)
sudo ufw allow in on tailscale0
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable
sudo ufw delete allow 22/tcp || true
sudo ufw reload
sudo ufw status verbose

Der Tailscale-eigene Härtungsleitfaden für Ubuntu verwendet denselben Aufbau: tailscale0 erlauben, anderen eingehenden Verkehr verweigern und dann verifizieren, dass öffentliches SSH in ein Timeout läuft, während SSH an die 100.x.y.z-Adresse weiterhin funktioniert. Wenn du eine öffentliche Website auf demselben VPS betreibst, behalte nur die öffentlichen Regeln bei, die du wirklich benötigst, wie 80/tcp und 443/tcp.

Deine Exposition überprüfen

Offene Ports von außen prüfen

Von einem Rechner aus, der sich NICHT in deinem Tailscale-Netzwerk befindet:

Terminal window
# Prüfen, ob gängige öffentliche Ports freigegeben sind
nmap -p 22,80,443,18789 DEINE_OEFFENTLICHE_IP


# Erwartete Ausgabe für eine gesicherte Instanz:
# 22/tcp   filtered ssh
# 18789/tcp filtered unknown

Wenn 22 oder 18789 als open statt filtered oder closed angezeigt wird, hast du ein Problem. Wenn 80 oder 443 offen ist, stelle sicher, dass dies nur deine absichtliche öffentliche Website oder der Tailscale-Funnel-Endpunkt ist, nicht versehentlich das OpenClaw-Gateway.

Prüfen, was lokal lauscht

Auf deinem OpenClaw-Server:

Terminal window
# Alle lauschenden Ports anzeigen und an was sie gebunden sind
sudo ss -tulpn | grep LISTEN


# Suche nach Zeilen wie dieser (gut für Serve):
# tcp   LISTEN 0   128   127.0.0.1:18789   *:*
#
# Oder dieser (akzeptabel für direktes Tailnet-Binding mit Authentifizierung):
# tcp   LISTEN 0   128   100.x.y.z:18789   *:*
#
# NICHT wie dieser (schlecht):
# tcp   LISTEN 0   128   0.0.0.0:18789     *:*

Wenn du 0.0.0.0 oder ::: (IPv6-Äquivalent) siehst, ist dieser Dienst weltweit freigegeben.

Integriertes Sicherheitsaudit

OpenClaw enthält einen Sicherheitsaudit-Befehl, der deine Konfiguration auf Sicherheits-Best-Practices überprüft:

Terminal window
openclaw security audit --deep
openclaw security audit --deep --fix

Das Audit überprüft Gateway-Freigabe, Tailscale-Modus, Authentifizierungseinstellungen, Kanalzugriff, Tool-Richtlinie, Plugin-Inventar und Dateiberechtigungen. Behandle --fix als nützlichen Helfer, nicht als Ersatz für das Lesen der Ergebnisse.

Was dies nicht löst

Tailscale beseitigt den größten Fehler: die öffentliche Freigabe von Operator-Oberflächen. Es löst nicht alles:

Credential-Speicherung: OpenClaw speichert Sitzungstranskripte, OAuth-Tokens und API-Schlüssel auf der Festplatte. Stelle sicher, dass diese die richtigen Dateiberechtigungen haben (chmod 600 für Dateien, chmod 700 für private Konfigurationsverzeichnisse) und nicht in der Versionsverwaltung liegen. Das integrierte Audit überprüft dies.

Plugin-Sandboxing: Plugins laufen mit den vollen Berechtigungen deines Benutzerkontos. Installiere nur Plugins aus vertrauenswürdigen Quellen und überprüfe, welche Fähigkeiten sie anfordern. Das Audit-Tool erfasst installierte Plugins.

Gerätesicherheit: Wenn jemand dein Tailscale-Konto kompromittiert oder ein Gerät in deinem Tailnet stiehlt, kann er auf deine OpenClaw-Instanz zugreifen. Aktiviere die Tailscale-Geräteautorisierung, um eine Genehmigung für neue Geräte zu verlangen.

Bereitstellungs-Checkliste

Bevor du deine OpenClaw/Moltbot-Instanz als produktionsreif betrachtest:

Ressourcen

Loading comments...