OpenClaw sicher auf VPS bereitstellen (2026)

OpenClaw ist ein quelloffener, selbst gehosteter KI-Assistent, der sich mit Messaging-Apps (WhatsApp, Telegram, Discord, Slack, Signal) und KI-Modellanbietern verbindet. Er fuehrt einen Gateway-Prozess auf Ihrem Server aus, empfaengt Nachrichten, fuehrt Agenten-Aktionen mit Tools aus und sendet Antworten. Alle Daten bleiben auf Ihrer Infrastruktur.

Diese Anleitung fuehrt durch eine sicherheitsorientierte Bereitstellung auf einem VPS mit Ubuntu 24.04. Sie werden das Betriebssystem haerten, OpenClaw installieren, die Gateway-Authentifizierung konfigurieren, Nginx mit TLS als Reverse Proxy einrichten, den Docker/UFW-Firewall-Bypass beheben, Docker-Sandboxing aktivieren, die Tool-Richtlinie einschraenken und das Gateway als gehaerteten systemd-Dienst betreiben.

Warum ist die Sicherheit von OpenClaw auf einem VPS wichtig?

OpenClaw fuehrt KI-Agenten aus, die Shell-Befehle ausfuehren, Dateien lesen und im Web surfen koennen. Eine fehlkonfigurierte Instanz gibt Angreifern dieselben Faehigkeiten. Das ist nicht theoretisch.

Anfang 2026 fanden Forscher ueber 42.000 oeffentlich erreichbare OpenClaw-Instanzen im Internet. 63% waren fuer Remote-Ausnutzung anfaellig. CVE-2026-25253 (CVSS 8.8) ermoeglichte Remote Code Execution mit einem Klick durch Exfiltration des Auth-Tokens ueber einen boeswilligen Link. Der Angreifer konnte das Gateway-Token stehlen, sich per WebSocket verbinden, Bestaetigungsaufforderungen deaktivieren, das Docker-Sandboxing umgehen und beliebige Befehle ausfuehren.

Der Fix wurde in Version 2026.1.29 veroeffentlicht, aber Patches allein reichen nicht aus. Sicherheit erfordert Schichten: Netzwerkisolation, Authentifizierung, TLS, Sandboxing und Tool-Einschraenkungen muessen zusammenwirken. Eine einzige fehlende Schicht (z.B. Gateway-Auth ohne Firewall) hinterlaesst einen direkten Weg zur Kompromittierung.

Was brauchen Sie vor dem Start?

Voraussetzung	Details
VPS	Ubuntu 24.04, mindestens 4 vCPU, 8 GB RAM
Domainname	A-Record, der auf Ihre VPS-IP zeigt (z.B. `openclaw.example.com`)
SSH-Zugang	Schluesselbasierte Authentifizierung konfiguriert
KI-Anbieter-API-Key	Anthropic, OpenAI oder Google Gemini
Node.js	Version 22 oder neuer
Docker	Engine 20+ mit Compose-Plugin

Wenn Sie Hilfe bei der Bereitstellung eines VPS oder der Einrichtung von SSH-Schluesseln brauchen, lesen Sie Secure a Linux VPS.

Wie haerten Sie den VPS vor der Installation von OpenClaw?

Bevor Sie etwas installieren, sichern Sie das Betriebssystem ab. Wenn Sie bereits Secure a Linux VPS und SSH Security Configuration befolgt haben, springen Sie zum naechsten Abschnitt.

Dedizierten Benutzer erstellen

Dienste als root auszufuehren ist ein unnoetiges Risiko. Erstellen Sie einen openclaw-Systembenutzer:

sudo useradd -r -m -s /bin/bash openclaw

Das erstellt ein Systemkonto mit Home-Verzeichnis. OpenClaw speichert seine Konfiguration in ~/.openclaw, daher ist das Home-Verzeichnis erforderlich.

UFW konfigurieren

Installieren und aktivieren Sie die Firewall, bevor Sie Dienste freigeben:

sudo apt update && sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp comment 'SSH'
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw enable

Regeln pruefen:

sudo ufw status verbose

Sie sollten die drei erlaubten Ports und eine Standard-Deny-Richtlinie fuer eingehenden Verkehr sehen. Port 18789 (das OpenClaw-Gateway) fehlt absichtlich. Das Gateway bindet nur an localhost und sitzt hinter Nginx.

fail2ban installieren

sudo apt update && sudo apt install -y fail2ban
sudo systemctl enable --now fail2ban

Pruefen Sie, ob es laeuft:

sudo systemctl status fail2ban

Die Ausgabe sollte active (running) zeigen. fail2ban ueberwacht SSH-Logs und sperrt IPs nach wiederholten fehlgeschlagenen Anmeldeversuchen.

Wie installieren Sie OpenClaw auf Ubuntu?

OpenClaw unterstuetzt zwei Installationsmethoden: npm (direkt) und Docker. Beide werden unten behandelt. Waehlen Sie eine. Docker wird fuer VPS-Bereitstellungen empfohlen, da die Container-Isolation den Schadensradius begrenzt, falls der Agenten-Prozess kompromittiert wird.

Option A: Docker-Installation (empfohlen)

Installieren Sie Docker, falls noch nicht vorhanden:

sudo apt install -y ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

Fuegen Sie den openclaw-Benutzer zur Docker-Gruppe hinzu:

sudo usermod -aG docker openclaw

Hinweis: Die Mitgliedschaft in der Docker-Gruppe gewaehrt das Aequivalent von Root-Zugriff auf dem Host. Das ist fuer die Docker-Funktionalitaet von OpenClaw erforderlich, aber es bedeutet, dass der openclaw-Benutzer alle Container auf dem System steuern kann. Die systemd-Haertung und Sandbox-Isolation weiter unten begrenzen, was der OpenClaw-Prozess tatsaechlich tun kann.

Wechseln Sie zum openclaw-Benutzer und richten Sie OpenClaw ein:

sudo -u openclaw -i

Klonen Sie das Repository und fuehren Sie das Setup mit dem offiziellen vorgebauten Image aus:

git clone https://github.com/openclaw/openclaw.git ~/openclaw-src
cd ~/openclaw-src
OPENCLAW_IMAGE=ghcr.io/openclaw/openclaw:latest ./docker-setup.sh

Die Variable OPENCLAW_IMAGE weist das Skript an, das vorgebaute Image aus der GitHub Container Registry zu ziehen, statt aus dem Quellcode zu bauen. Das Skript fuehrt das Onboarding durch und startet das Gateway ueber Docker Compose.

Das Gateway im Container bindet standardmaessig an alle Interfaces (lan-Modus). Das ist bei Docker-Bereitstellungen korrekt, da Dockers Port-Mapping das Gateway im Container erreichen muss. Externer Zugriff wird auf Host-Ebene durch DOCKER-USER-iptables-Regeln blockiert (weiter unten behandelt).

Pruefen Sie, ob das Gateway laeuft:

curl -fsS http://127.0.0.1:18789/healthz

Eine 200 OK-Antwort bestaetigt, dass das Gateway aktiv ist. Der /readyz-Endpoint bestaetigt, dass es bereit ist, Verbindungen anzunehmen:

curl -fsS http://127.0.0.1:18789/readyz

Option B: npm-Installation

Installieren Sie Node.js 22 ueber NodeSource:

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs

Pruefen Sie die Version:

node --version

Die Ausgabe sollte v22.x.x oder neuer zeigen.

Wechseln Sie zum openclaw-Benutzer und installieren Sie:

sudo -u openclaw -i
npm install -g openclaw@latest

Fuehren Sie das Onboarding aus:

openclaw onboard

Waehlen Sie loopback fuer den Bind-Modus. Der Onboarding-Assistent generiert ein Gateway-Auth-Token und speichert es in ~/.openclaw/openclaw.json.

Starten Sie das Gateway:

openclaw gateway start

Pruefen:

curl -fsS http://127.0.0.1:18789/healthz

Gateway-Binding pruefen

Pruefen Sie, worauf das Gateway lauscht:

ss -tulpn | grep 18789

Bei npm-Installationen: Die Ausgabe sollte 127.0.0.1:18789 zeigen, nicht 0.0.0.0:18789. Wenn Sie 0.0.0.0 sehen, stoppen Sie das Gateway und setzen Sie gateway.bind auf "loopback" in openclaw.json.

Bei Docker-Installationen: Sie werden 0.0.0.0:18789 vom docker-proxy-Prozess sehen. Das ist normal. Dockers Port-Mapping veroeffentlicht den Port auf allen Host-Interfaces, damit localhost-Verkehr den Container erreichen kann. Die DOCKER-USER-iptables-Regeln (weiter unten im Firewall-Abschnitt) blockieren externen Zugriff auf Netzwerkebene.

Dateiberechtigungen einschraenken

Die Konfigurationsdatei enthaelt Ihr Auth-Token und Ihre API-Keys:

chmod 700 /home/openclaw/.openclaw
chmod 600 /home/openclaw/.openclaw/openclaw.json

Pruefen:

ls -la /home/openclaw/.openclaw/openclaw.json

Sie sollten -rw------- sehen. Bei npm-Installationen ist der Eigentuemer openclaw. Bei Docker-Installationen kann der Eigentuemer als UID 1000 angezeigt werden (der node-Benutzer im Container). Das ist normal und erforderlich, damit der Container die Konfiguration lesen kann.

Wie konfigurieren Sie die Gateway-Authentifizierung?

Das Gateway von OpenClaw erfordert standardmaessig eine Authentifizierung. Wenn kein Token oder Passwort konfiguriert ist, lehnt das Gateway WebSocket-Verbindungen ab (Fail-Closed). Der Onboarding-Assistent generiert automatisch ein Token.

OpenClaw unterstuetzt drei Authentifizierungsmodi:

Modus	Funktionsweise	Geeignet fuer
`token`	Gemeinsames Bearer-Token in jeder Anfrage	Einzelbenutzer-VPS (empfohlen)
`password`	Passwortbasierte Authentifizierung	Setups mit mehreren Geraeten
`trusted-proxy`	Delegiert Auth an einen Reverse Proxy	Enterprise/SSO-Setups

Ein starkes Token setzen

Wenn Sie das automatisch generierte Token ersetzen moechten, generieren Sie ein neues:

openssl rand -base64 32

Speichern Sie es als Umgebungsvariable, anstatt es in der Konfigurationsdatei fest zu codieren. Erstellen Sie eine Umgebungsdatei:

sudo mkdir -p /etc/openclaw
sudo tee /etc/openclaw/env > /dev/null << 'EOF'
OPENCLAW_GATEWAY_TOKEN=your-generated-token-here
EOF
sudo chmod 600 /etc/openclaw/env
sudo chown openclaw:openclaw /etc/openclaw/env

Bearbeiten Sie ~/.openclaw/openclaw.json, um die Umgebungsvariable zu referenzieren:

{
  gateway: {
    bind: "loopback",  // use "loopback" for npm, keep default for Docker
    port: 18789,
    auth: {
      mode: "token",
      token: "${OPENCLAW_GATEWAY_TOKEN}"
    }
  }
}

OpenClaw unterstuetzt ${VARIABLE}-Substitution in seiner JSON5-Konfiguration, sodass das Token beim Start aus der Umgebung gelesen wird. Bei Docker-Installationen setzen Sie die OPENCLAW_GATEWAY_TOKEN-Variable stattdessen in der .env-Datei in Ihrem openclaw-src-Verzeichnis. Das docker-setup.sh-Skript generiert diese Datei automatisch.

Starten Sie das Gateway neu und testen Sie, ob unauthentifizierte Anfragen abgelehnt werden:

curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:18789/healthz

Der Health-Endpoint gibt 200 ohne Auth zurueck (es ist ein Health Check). Um die Auth-Durchsetzung am WebSocket-Endpoint zu testen, pruefen Sie die Gateway-Logs:

Bei systemd/npm-Installationen:

journalctl -u openclaw-gateway --no-pager -n 20

Bei Docker-Installationen:

cd ~/openclaw-src && docker compose logs openclaw-gateway --tail 20

Suchen Sie nach auth required- oder connection rejected-Eintraegen, die das Fail-Closed-Verhalten bestaetigen.

Wie richten Sie Nginx als TLS-Reverse-Proxy fuer OpenClaw ein?

Das Gateway bindet an localhost. Nginx sitzt davor, terminiert TLS und leitet WebSocket-Verbindungen an das Gateway weiter. So erhalten Sie verschluesselte Verbindungen, ohne den Gateway-Port freizugeben.

Hintergrundinformationen zu Nginx-Reverse-Proxys finden Sie unter Nginx Reverse Proxy. Zur TLS-Einrichtung mit Let's Encrypt lesen Sie Nginx SSL/TLS with Let's Encrypt.

Nginx und Certbot installieren

sudo apt install -y nginx certbot python3-certbot-nginx

TLS-Zertifikat beschaffen

sudo certbot --nginx -d openclaw.example.com

Ersetzen Sie openclaw.example.com durch Ihre tatsaechliche Domain. Certbot konfiguriert die automatische Erneuerung.

Reverse Proxy konfigurieren

Erstellen Sie den Nginx-Serverblock:

sudo tee /etc/nginx/sites-available/openclaw.conf > /dev/null << 'NGINX'
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name openclaw.example.com;

    ssl_certificate /etc/letsencrypt/live/openclaw.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/openclaw.example.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    # Hide Nginx version
    server_tokens off;

    # WebSocket proxy to OpenClaw gateway
    location / {
        proxy_pass http://127.0.0.1:18789;

        # WebSocket support
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        # Overwrite X-Forwarded-For, do not append
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Host $host;

        # Timeouts for long-running agent sessions
        proxy_read_timeout 86400s;
        proxy_send_timeout 86400s;
    }
}

server {
    listen 80;
    listen [::]:80;
    server_name openclaw.example.com;
    return 301 https://$host$request_uri;
}
NGINX

Beachten Sie: proxy_set_header X-Forwarded-For $remote_addr verwendet $remote_addr (ueberschreiben), nicht $proxy_add_x_forwarded_for (anhaengen). Das ist Absicht. Beim Anhaengen koennen Clients gefaelschte IPs in den Header einschleusen. Die OpenClaw-Dokumentation empfiehlt ausdruecklich das Ueberschreiben.

Aktivieren Sie die Site und testen Sie die Konfiguration:

sudo ln -s /etc/nginx/sites-available/openclaw.conf /etc/nginx/sites-enabled/
sudo nginx -t

Die Ausgabe sollte syntax is ok und test is successful zeigen. Laden Sie Nginx neu:

sudo systemctl reload nginx

OpenClaw so konfigurieren, dass es dem Proxy vertraut

Weisen Sie das Gateway an, den weitergeleiteten Headern von Nginx zu vertrauen, indem Sie trustedProxies zu ~/.openclaw/openclaw.json hinzufuegen:

{
  gateway: {
    bind: "loopback",  // use "loopback" for npm, keep default for Docker
    port: 18789,
    trustedProxies: ["127.0.0.1"],
    auth: {
      mode: "token",
      token: "${OPENCLAW_GATEWAY_TOKEN}"
    }
  }
}

Starten Sie das Gateway neu, um die Aenderungen zu uebernehmen. Pruefen Sie von Ihrem lokalen Rechner (nicht dem Server), ob TLS funktioniert:

curl -I https://openclaw.example.com/healthz

Sie sollten eine 200-Antwort ueber HTTPS erhalten. Weitere Informationen zur Nginx-Sicherheitshaertung finden Sie im Nginx Security Hardening Guide (in Kuerze verfuegbar).

Wie beheben Sie den Docker- und UFW-Firewall-Bypass?

Docker manipuliert iptables direkt und umgeht UFW vollstaendig. Wenn Sie OpenClaw mit Docker ausfuehren und einen Port veroeffentlichen, ist dieser Port aus dem Internet erreichbar, selbst wenn UFW ihn blockiert. Das ist eine der haeufigsten Fehlkonfigurationen bei Docker-Bereitstellungen.

Eine vollstaendige Erklaerung dieses Problems finden Sie unter Docker UFW Firewall Fix.

Der Fix verwendet die DOCKER-USER-Chain, die Docker verarbeitet, bevor Verkehr an Container weitergeleitet wird.

Gesamten externen Zugriff auf Docker-Ports blockieren

sudo iptables -I DOCKER-USER -i eth0 -j DROP

Das verwirft allen Verkehr vom externen Interface (eth0), den Docker sonst an Container weiterleiten wuerde. Passen Sie den Interfacenamen an, falls Ihrer abweicht (pruefen mit ip link show).

Loopback-Verkehr erlauben

Nginx auf demselben Host muss den Gateway-Container ueber localhost erreichen:

sudo iptables -I DOCKER-USER -i lo -j ACCEPT

Bestehende Verbindungen erlauben

sudo iptables -I DOCKER-USER -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Regeln persistent machen

sudo apt install -y iptables-persistent
sudo netfilter-persistent save

Regeln pruefen

sudo iptables -L DOCKER-USER -n -v

Sie sollten die ACCEPT-Regeln fuer Loopback und bestehende Verbindungen ueber der DROP-Regel fuer eth0 sehen. Die Reihenfolge ist wichtig: iptables verarbeitet Regeln von oben nach unten.

Testen Sie von einem externen Rechner, ob der Gateway-Port nicht erreichbar ist:

nmap -p 18789 your-server-ip

Port 18789 sollte filtered oder closed anzeigen, nicht open.

Wie aktivieren Sie Docker-Sandboxing fuer OpenClaw?

Docker-Sandboxing fuehrt Agenten-Tool-Ausfuehrungen in isolierten Containern aus. Wenn ein Agent einen Shell-Befehl ausfuehrt oder eine Datei schreibt, geschieht das in einem Wegwerf-Container, nicht auf Ihrem Host.

Fuegen Sie die Sandbox-Konfiguration zu ~/.openclaw/openclaw.json hinzu:

{
  agents: {
    defaults: {
      sandbox: {
        mode: "all",
        scope: "session",
        workspaceAccess: "none",
        docker: {
          image: "openclaw-sandbox:bookworm-slim",
          network: "none",
          user: "1000:1000",
          memory: "1g",
          cpus: 1
        }
      }
    }
  }
}

Was jede Einstellung bewirkt:

Einstellung	Wert	Wirkung
`mode`	`"all"`	Jede Sitzung laeuft in der Sandbox, ohne Ausnahmen
`scope`	`"session"`	Jede Chat-Sitzung bekommt ihren eigenen Container
`workspaceAccess`	`"none"`	Die Sandbox kann den Agenten-Workspace nicht sehen
`network`	`"none"`	Kein Netzwerkzugriff aus der Sandbox (verhindert Datenabfluss)
`memory`	`"1g"`	Begrenzt den Container-RAM auf 1 GB
`cpus`	`1`	Begrenzt den Container auf 1 CPU-Kern

Bauen Sie das Sandbox-Image:

cd ~/openclaw-src
scripts/sandbox-setup.sh

Sandbox-Konfiguration pruefen:

openclaw sandbox explain

Bei Docker-Installationen ueber Compose ausfuehren:

cd ~/openclaw-src && docker compose exec openclaw-gateway node dist/index.js sandbox explain

Dieser Befehl gibt den effektiven Sandbox-Modus, Scope, Workspace-Zugriff, die Tool-Richtlinie und eventuelle Ueberschreibungen aus. Bestaetigen Sie, dass mode: all und network: none in der Ausgabe erscheinen.

Wenn Sie Netzwerkzugriff fuer bestimmte Tools benoetigen (z.B. web_search), gewaehren Sie ihn selektiv pro Agent, anstatt den globalen Standard zu aendern. Siehe den Abschnitt zur Tool-Richtlinie unten.

OpenClaw blockiert standardmaessig gefaehrliche Bind-Mount-Quellen: /var/run/docker.sock, /etc, /proc, /sys und /dev werden alle abgelehnt. Ueberschreiben Sie das nicht mit benutzerdefinierten Bind Mounts, die sie erneut freigeben. Wenn ein Sandbox-Container Zugriff auf Host-Daten benoetigt, verwenden Sie schreibgeschuetzte Mounts mit expliziten Pfaden:

{
  agents: {
    defaults: {
      sandbox: {
        docker: {
          binds: ["/home/openclaw/shared-data:/data:ro"]
        }
      }
    }
  }
}

Das :ro-Suffix stellt sicher, dass der Container die Daten lesen, aber nicht aendern kann.

Wie schraenken Sie die OpenClaw-Tool-Richtlinie ein?

Die Tool-Richtlinie steuert, welche Tools Agenten verwenden koennen. Die Sandbox hat ihren eigenen Tool-Filter, getrennt von den Berechtigungen auf Agentenebene. Deny gewinnt immer ueber Allow.

Standard-Deny-Richtlinie

Setzen Sie eine restriktive Standardeinstellung in ~/.openclaw/openclaw.json:

{
  tools: {
    deny: ["exec", "write", "edit", "browser"],
    allow: ["read", "web_search"]
  }
}

Das blockiert standardmaessig Befehlsausfuehrung, Dateischreiben, Dateibearbeitung und Browserzugriff. Agenten koennen weiterhin Dateien lesen und im Web suchen.

Profile pro Agent

Ueberschreiben Sie die Standards fuer bestimmte Agenten, die mehr Zugriff benoetigen. Fuegen Sie Profile unter agents.list hinzu:

{
  agents: {
    list: [
      {
        name: "coding-agent",
        tools: {
          allow: ["exec", "read", "write", "edit"],
          deny: ["browser"]
        },
        sandbox: {
          mode: "all",
          docker: {
            network: "none"
          }
        }
      },
      {
        name: "messaging-agent",
        tools: {
          allow: ["read", "web_search"],
          deny: ["exec", "write", "edit", "browser"]
        }
      }
    ]
  }
}

Der coding-agent kann Befehle ausfuehren, aber nur in einem Sandbox-Container ohne Netzwerk. Der messaging-agent kann lesen und suchen, aber nichts ausfuehren.

Elevated Mode deaktivieren

Der Elevated Mode laesst Agenten Befehle direkt auf dem Gateway-Host ausfuehren und umgeht die Sandbox. Deaktivieren Sie ihn:

{
  tools: {
    elevated: {
      enabled: false
    }
  }
}

Wenn Sie den Elevated Mode aktiviert lassen, kann jeder Benutzer, der mit dem Agenten chatten kann, potenziell Host-Befehle ausfuehren. Auf einem VPS ist das Remote Code Execution.

Multi-User-DM-Isolation

Wenn mehrere Personen Ihrer OpenClaw-Instanz Nachrichten senden werden, aktivieren Sie DM-Scoping pro Peer. Standardmaessig teilen sich alle DMs eine einzelne Hauptsitzung. Das bedeutet, Benutzer A kann den Kontext aus der Konversation von Benutzer B sehen.

{
  session: {
    dmScope: "per-peer"
  }
}

Das gibt jedem Absender seine eigene Sitzung mit isoliertem Kontext und Sandbox-Container.

Wie fuehren Sie OpenClaw als gehaerteten systemd-Dienst aus?

OpenClaw unter systemd auszufuehren bedeutet, dass es beim Booten startet, bei Abstuerzen neu startet und durch Haertungsdirektiven Prozessisolation erhaelt.

Service-Unit erstellen

Erstellen Sie fuer Docker-Installationen die folgende Unit-Datei:

sudo tee /etc/systemd/system/openclaw-gateway.service > /dev/null << 'EOF'
[Unit]
Description=OpenClaw Gateway
After=network-online.target docker.service
Wants=network-online.target
Requires=docker.service

[Service]
Type=simple
User=openclaw
Group=openclaw
WorkingDirectory=/home/openclaw/openclaw-src
EnvironmentFile=/etc/openclaw/env
ExecStart=/usr/bin/docker compose up --no-log-prefix openclaw-gateway
ExecStop=/usr/bin/docker compose down
Restart=always
RestartSec=10

# Security hardening
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ProtectHome=read-only
ReadWritePaths=/home/openclaw/.openclaw
CapabilityBoundingSet=
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes
RestrictSUIDSGID=yes
MemoryMax=4G

[Install]
WantedBy=multi-user.target
EOF

Ersetzen Sie bei npm-Installationen die ExecStart- und ExecStop-Zeilen:

ExecStart=/usr/bin/openclaw gateway start --foreground
ExecStop=/usr/bin/openclaw gateway stop

Und entfernen Sie die Zeile Requires=docker.service.

Was jede Haertungsdirektive bewirkt:

Direktive	Schutz
`NoNewPrivileges`	Verhindert, dass der Prozess ueber setuid/setgid zusaetzliche Rechte erlangt
`PrivateTmp`	Gibt dem Dienst sein eigenes `/tmp`, unsichtbar fuer andere Prozesse
`ProtectSystem=strict`	Mountet das gesamte Dateisystem schreibgeschuetzt, ausser explizite `ReadWritePaths`
`ProtectHome=read-only`	Verhindert Schreiben in jedes Home-Verzeichnis ausser dem erlaubten Pfad
`CapabilityBoundingSet=`	Entfernt alle Linux-Capabilities (leere Menge)
`ProtectKernelTunables`	Blockiert Schreiben in `/proc/sys`, `/sys`
`ProtectKernelModules`	Verhindert das Laden von Kernel-Modulen
`MemoryMax=4G`	Beendet den Dienst, wenn er 4 GB RAM ueberschreitet, und verhindert OOM auf dem Host

Aktivieren und starten

sudo systemctl daemon-reload
sudo systemctl enable --now openclaw-gateway

enable sorgt fuer den Start beim Booten. --now startet sofort.

Pruefen Sie, ob es laeuft:

sudo systemctl status openclaw-gateway

Die Ausgabe sollte active (running) zeigen. Pruefen Sie die Logs auf Fehler:

journalctl -u openclaw-gateway -f --no-pager -n 50

Wie pruefen Sie, ob die gesamte Bereitstellung sicher ist?

Gehen Sie diese Checkliste nach der Bereitstellung durch, um zu bestaetigen, dass jede Schicht funktioniert.

1. OpenClaws integriertes Sicherheitsaudit ausfuehren

Bei npm-Installationen:

sudo -u openclaw openclaw security audit --deep

Bei Docker-Installationen:

cd ~/openclaw-src && docker compose exec openclaw-gateway node dist/index.js security audit --deep

Das erkennt haeufige Fehlkonfigurationen: unauthentifizierte Netzwerkexposition, erhoehte Tool-Berechtigungen, Probleme mit Dateiberechtigungen. Beheben Sie alle Warnungen, bevor Sie fortfahren.

2. Gateway-Binding bestaetigen

ss -tulpn | grep 18789

npm-Installationen: Erwartet 127.0.0.1:18789. Nicht 0.0.0.0:18789.

Docker-Installationen: Erwartet 0.0.0.0:18789 von docker-proxy. Das ist normal. Externer Zugriff wird durch die DOCKER-USER-iptables-Regeln blockiert.

3. Externer Portscan

Von Ihrem lokalen Rechner (nicht dem Server):

nmap -p 18789 your-server-ip

Erwartet: filtered oder closed.

4. TLS pruefen

curl -I https://openclaw.example.com/healthz

Erwartet: 200 ueber HTTPS mit einem gueltigen Zertifikat.

5. Auth-Durchsetzung testen

curl -s -o /dev/null -w "%{http_code}" https://openclaw.example.com/

Das Gateway sollte fuer Nicht-Health-Endpoints eine Authentifizierung verlangen.

6. Sandbox-Isolation pruefen

Bei npm-Installationen:

sudo -u openclaw openclaw sandbox explain

Bei Docker-Installationen:

cd ~/openclaw-src && docker compose exec openclaw-gateway node dist/index.js sandbox explain

Bestaetigen Sie mode: all, network: none und keine Elevated-Ueberschreibungen.

7. Dateiberechtigungen pruefen

ls -la /home/openclaw/.openclaw/openclaw.json
ls -la /etc/openclaw/env

Beide sollten 600-Berechtigungen zeigen. Die env-Datei gehoert openclaw. Bei Docker-Installationen kann openclaw.json der UID 1000 gehoeren (der node-Benutzer des Containers).

8. systemd-Haertung pruefen

systemd-analyze security openclaw-gateway

Das bewertet die Sicherheitseigenschaften des Dienstes. Streben Sie einen Score von etwa 5.0 oder niedriger an (niedriger ist sicherer). Docker-basierte Dienste erreichen typischerweise 5.0-5.5, da Docker Zugriff auf Namespaces und Geraete-Interfaces benoetigt. Die obigen Haertungsdirektiven senken den Score vom Standard ~9.6 auf etwa 5.2.

9. UFW- und DOCKER-USER-Regeln pruefen

sudo ufw status
sudo iptables -L DOCKER-USER -n -v

UFW sollte nur die Ports 22, 80 und 443 zeigen. Die DOCKER-USER-Chain sollte externen Verkehr verwerfen.

10. Auf freigegebene Dienste pruefen

ss -tulpn

Nur SSH (22), Nginx (80, 443) und OpenClaw (127.0.0.1:18789 bei npm oder 0.0.0.0:18789 ueber docker-proxy bei Docker) sollten erscheinen.

Wie halten Sie OpenClaw aktuell und gesichert?

Versionsverbergung

Verbergen Sie die OpenClaw-Version in Gateway-Antworten. Die Offenlegung der Version hilft Angreifern, bekannte Schwachstellen gezielt auszunutzen. In ~/.openclaw/openclaw.json:

{
  gateway: {
    exposeVersion: false
  }
}

Zusammen mit der server_tokens off;-Direktive in der Nginx-Konfiguration verhindert das Fingerprinting sowohl des Reverse Proxy als auch der Anwendung.

Aktualisierungen

OpenClaw veroeffentlicht haeufig Updates. Pruefen Sie die aktuelle Version:

openclaw --version

Bei Docker-Installationen:

cd ~/openclaw-src && docker compose exec openclaw-gateway node dist/index.js --version

Um eine Docker-Installation zu aktualisieren:

cd ~/openclaw-src
git pull
docker compose pull
docker compose up -d openclaw-gateway

Um eine npm-Installation zu aktualisieren:

npm update -g openclaw

Starten Sie nach dem Update das Gateway neu und fuehren Sie das Sicherheitsaudit erneut aus:

sudo systemctl restart openclaw-gateway

Bei npm:

sudo -u openclaw openclaw security audit

Bei Docker:

cd ~/openclaw-src && docker compose exec openclaw-gateway node dist/index.js security audit

Lesen Sie die Release Notes vor dem Upgrade. Aenderungen am Konfigurationsformat kommen vor. Version 2026.3.7 fuehrte ein erforderliches gateway.auth.mode-Feld ein, wenn sowohl token als auch password vorhanden sind. Fehlt es nach dem Upgrade, werden Sie vom Gateway ausgesperrt.

Backups

Sichern Sie das Konfigurationsverzeichnis:

sudo tar czf /root/openclaw-backup-$(date +%Y%m%d).tar.gz /home/openclaw/.openclaw

Speichern Sie Backups ausserhalb des Servers. Das Konfigurationsverzeichnis enthaelt Ihre Auth-Tokens, Agenten-Konfigurationen und den Konversationszustand. Schuetzen Sie Backups mit derselben Sorgfalt wie die Live-Konfiguration: Verschluesseln Sie sie mit gpg oder speichern Sie sie auf einem verschluesselten Volume.

Log-Verwaltung

Logs in Echtzeit anzeigen:

journalctl -u openclaw-gateway -f

OpenClaw-Logs koennen Konversationsausschnitte enthalten. Legen Sie eine Log-Aufbewahrungsfrist fest, um die Exposition zu begrenzen:

sudo tee /etc/systemd/journald.conf.d/openclaw.conf > /dev/null << 'EOF'
[Journal]
MaxRetentionSec=7d
MaxFileSec=1d
EOF
sudo systemctl restart systemd-journald

Etwas ist schiefgelaufen?

Symptom	Wahrscheinliche Ursache	Loesung
Gateway startet nicht	Port 18789 bereits belegt	`ss -tulpn \| grep 18789` um den konfliktverursachenden Prozess zu finden
WebSocket-Verbindungen schlagen ueber Nginx fehl	Fehlende `Upgrade`- und `Connection`-Header	Pruefen Sie die `proxy_set_header`-Direktiven in Ihrer Nginx-Konfiguration
Sandbox-Container starten nicht	Docker-Socket-Berechtigungen	Stellen Sie sicher, dass der `openclaw`-Benutzer in der `docker`-Gruppe ist, und melden Sie sich erneut an
`openclaw security audit` zeigt Warnungen	Konfigurationsabweichung nach Update	Pruefen Sie die Audit-Ausgabe und wenden Sie die empfohlenen Fixes an
Gateway von externer IP erreichbar	Docker/UFW-Bypass	Fuegen Sie `DOCKER-USER`-iptables-Regeln wie oben beschrieben hinzu
TLS-Zertifikatsfehler	Certbot-Erneuerung fehlgeschlagen	Fuehren Sie `sudo certbot renew --dry-run` zur Diagnose aus
OOM-Kills auf dem VPS	Fehlendes `MemoryMax` in der systemd-Unit	Fuegen Sie `MemoryMax=4G` im `[Service]`-Abschnitt hinzu

Copyright 2026 Virtua.Cloud. Alle Rechte vorbehalten. Dieser Inhalt ist ein Originalwerk des Virtua.Cloud-Teams. Vervielfaeltigung, Wiederveroeffentlichung oder Weiterverbreitung ohne schriftliche Genehmigung ist untersagt.

Verwandte Artikel