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

Diese Anleitung führt durch eine sicherheitsorientierte Bereitstellung auf einem VPS mit Ubuntu 24.04. Sie werden das Betriebssystem härten, 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 einschränken und das Gateway als gehärteten systemd-Dienst betreiben.

Warum ist die Sicherheit von OpenClaw auf einem VPS wichtig?

OpenClaw führt KI-Agenten aus, die Shell-Befehle ausführen, Dateien lesen und im Web surfen können. Eine fehlkonfigurierte Instanz gibt Angreifern dieselben Fähigkeiten. Das ist nicht theoretisch.

Anfang 2026 fanden Forscher über 42.000 öffentlich erreichbare OpenClaw-Instanzen im Internet. 63% waren für Remote-Ausnutzung anfällig. CVE-2026-25253 (CVSS 8.8) ermöglichte Remote Code Execution mit einem Klick durch Exfiltration des Auth-Tokens über einen böswilligen Link. Der Angreifer konnte das Gateway-Token stehlen, sich per WebSocket verbinden, Bestätigungsaufforderungen deaktivieren, das Docker-Sandboxing umgehen und beliebige Befehle ausführen.

Der Fix wurde in Version 2026.1.29 veröffentlicht, aber Patches allein reichen nicht aus. Sicherheit erfordert Schichten: Netzwerkisolation, Authentifizierung, TLS, Sandboxing und Tool-Einschränkungen müssen zusammenwirken. Eine einzige fehlende Schicht (z.B. Gateway-Auth ohne Firewall) hinterlässt 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	Schlüsselbasierte 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-Schlüsseln brauchen, lesen Sie Linux VPS Security: Bedrohungen, Schutzschichten und Hardening-Guide.

Wie härten Sie den VPS vor der Installation von OpenClaw?

Bevor Sie etwas installieren, sichern Sie das Betriebssystem ab. Wenn Sie bereits Linux VPS Security: Bedrohungen, Schutzschichten und Hardening-Guide und SSH-Härtung auf einem Linux-VPS: sshd_config Sicherheitsanleitung befolgt haben, springen Sie zum nächsten Abschnitt.

Dedizierten Benutzer erstellen

Dienste als root auszuführen ist ein unnötiges 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 prüfen:

sudo ufw status verbose

Sie sollten die drei erlaubten Ports und eine Standard-Deny-Richtlinie für 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

Prüfen Sie, ob es läuft:

sudo systemctl status fail2ban

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

Wie installieren Sie OpenClaw auf Ubuntu?

OpenClaw unterstützt zwei Installationsmethoden: npm (direkt) und Docker. Beide werden unten behandelt. Wählen Sie eine. Docker wird für 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

Fügen Sie den openclaw-Benutzer zur Docker-Gruppe hinzu:

sudo usermod -aG docker openclaw

Hinweis: Die Mitgliedschaft in der Docker-Gruppe gewährt das Äquivalent von Root-Zugriff auf dem Host. Das ist für die Docker-Funktionalität von OpenClaw erforderlich, aber es bedeutet, dass der openclaw-Benutzer alle Container auf dem System steuern kann. Die systemd-Härtung und Sandbox-Isolation weiter unten begrenzen, was der OpenClaw-Prozess tatsächlich tun kann.

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

sudo -u openclaw -i

Klonen Sie das Repository und führen 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 führt das Onboarding durch und startet das Gateway über Docker Compose.

Das Gateway im Container bindet standardmäßig 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).

Prüfen Sie, ob das Gateway läuft:

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

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

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

Option B: npm-Installation

Installieren Sie Node.js 22 über NodeSource:

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

Prüfen 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

Führen Sie das Onboarding aus:

openclaw onboard

Wählen Sie loopback für 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

Prüfen:

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

Gateway-Binding prüfen

Prüfen 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 veröffentlicht 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 einschränken

Die Konfigurationsdatei enthält Ihr Auth-Token und Ihre API-Keys:

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

Prüfen:

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

Sie sollten -rw------- sehen. Bei npm-Installationen ist der Eigentümer openclaw. Bei Docker-Installationen kann der Eigentümer 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 standardmäßig 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 unterstützt drei Authentifizierungsmodi:

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

Ein starkes Token setzen

Wenn Sie das automatisch generierte Token ersetzen möchten, 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 unterstützt ${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 zurück (es ist ein Health Check). Um die Auth-Durchsetzung am WebSocket-Endpoint zu testen, prüfen 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-Einträgen, die das Fail-Closed-Verhalten bestätigen.

Wie richten Sie Nginx als TLS-Reverse-Proxy für OpenClaw ein?

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

Hintergrundinformationen zu Nginx-Reverse-Proxys finden Sie unter Nginx als Reverse Proxy konfigurieren. Zur TLS-Einrichtung mit Let's Encrypt lesen Sie Let's Encrypt SSL/TLS für Nginx einrichten auf Debian 12 und Ubuntu 24.04.

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 tatsächliche 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 (überschreiben), nicht $proxy_add_x_forwarded_for (anhängen). Das ist Absicht. Beim Anhängen können Clients gefälschte IPs in den Header einschleusen. Die OpenClaw-Dokumentation empfiehlt ausdrücklich das Überschreiben.

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 hinzufügen:

{
  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 Änderungen zu übernehmen. Prüfen Sie von Ihrem lokalen Rechner (nicht dem Server), ob TLS funktioniert:

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

Sie sollten eine 200-Antwort über HTTPS erhalten. Nginx-Sicherheitshärtung unter Ubuntu und DebianWeitere Informationen zur Nginx-Sicherheitshärtung finden Sie im Nginx Security Hardening Guide (in Kürze verfügbar).

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

Docker manipuliert iptables direkt und umgeht UFW vollständig. Wenn Sie OpenClaw mit Docker ausführen und einen Port veröffentlichen, ist dieser Port aus dem Internet erreichbar, selbst wenn UFW ihn blockiert. Das ist eine der häufigsten Fehlkonfigurationen bei Docker-Bereitstellungen.

Eine vollständige Erklärung dieses Problems finden Sie unter Docker umgeht UFW: 4 getestete Lösungen für Ihren VPS.

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 würde. Passen Sie den Interfacenamen an, falls Ihrer abweicht (prüfen mit ip link show).

Loopback-Verkehr erlauben

Nginx auf demselben Host muss den Gateway-Container über 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 prüfen

sudo iptables -L DOCKER-USER -n -v

Sie sollten die ACCEPT-Regeln für Loopback und bestehende Verbindungen über der DROP-Regel für 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 für OpenClaw?

Docker-Sandboxing führt Agenten-Tool-Ausführungen in isolierten Containern aus. Wenn ein Agent einen Shell-Befehl ausführt oder eine Datei schreibt, geschieht das in einem Wegwerf-Container, nicht auf Ihrem Host.

Fügen 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 läuft 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 prüfen:

openclaw sandbox explain

Bei Docker-Installationen über Compose ausführen:

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 Überschreibungen aus. Bestätigen Sie, dass mode: all und network: none in der Ausgabe erscheinen.

Wenn Sie Netzwerkzugriff für bestimmte Tools benötigen (z.B. web_search), gewähren Sie ihn selektiv pro Agent, anstatt den globalen Standard zu ändern. Siehe den Abschnitt zur Tool-Richtlinie unten.

OpenClaw blockiert standardmäßig gefährliche Bind-Mount-Quellen: /var/run/docker.sock, /etc, /proc, /sys und /dev werden alle abgelehnt. Überschreiben Sie das nicht mit benutzerdefinierten Bind Mounts, die sie erneut freigeben. Wenn ein Sandbox-Container Zugriff auf Host-Daten benötigt, verwenden Sie schreibgeschützte 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 ändern kann.

Wie schränken Sie die OpenClaw-Tool-Richtlinie ein?

Die Tool-Richtlinie steuert, welche Tools Agenten verwenden können. Die Sandbox hat ihren eigenen Tool-Filter, getrennt von den Berechtigungen auf Agentenebene. Deny gewinnt immer über 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 standardmäßig Befehlsausführung, Dateischreiben, Dateibearbeitung und Browserzugriff. Agenten können weiterhin Dateien lesen und im Web suchen.

Profile pro Agent

Überschreiben Sie die Standards für bestimmte Agenten, die mehr Zugriff benötigen. Fügen 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 ausführen, aber nur in einem Sandbox-Container ohne Netzwerk. Der messaging-agent kann lesen und suchen, aber nichts ausführen.

Elevated Mode deaktivieren

Der Elevated Mode lässt Agenten Befehle direkt auf dem Gateway-Host ausführen 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 ausführen. 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. Standardmäßig 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 führen Sie OpenClaw als gehärteten systemd-Dienst aus?

OpenClaw unter systemd auszuführen bedeutet, dass es beim Booten startet, bei Abstürzen neu startet und durch Härtungsdirektiven Prozessisolation erhält.

Service-Unit erstellen

Erstellen Sie für 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 Härtungsdirektive bewirkt:

Direktive	Schutz
`NoNewPrivileges`	Verhindert, dass der Prozess über setuid/setgid zusätzliche Rechte erlangt
`PrivateTmp`	Gibt dem Dienst sein eigenes `/tmp`, unsichtbar für andere Prozesse
`ProtectSystem=strict`	Mountet das gesamte Dateisystem schreibgeschützt, 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 überschreitet, und verhindert OOM auf dem Host

Aktivieren und starten

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

enable sorgt für den Start beim Booten. --now startet sofort.

Prüfen Sie, ob es läuft:

sudo systemctl status openclaw-gateway

Die Ausgabe sollte active (running) zeigen. Prüfen Sie die Logs auf Fehler:

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

Wie prüfen Sie, ob die gesamte Bereitstellung sicher ist?

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

1. OpenClaws integriertes Sicherheitsaudit ausführen

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 häufige Fehlkonfigurationen: unauthentifizierte Netzwerkexposition, erhöhte Tool-Berechtigungen, Probleme mit Dateiberechtigungen. Beheben Sie alle Warnungen, bevor Sie fortfahren.

2. Gateway-Binding bestätigen

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 prüfen

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

Erwartet: 200 über HTTPS mit einem gültigen Zertifikat.

5. Auth-Durchsetzung testen

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

Das Gateway sollte für Nicht-Health-Endpoints eine Authentifizierung verlangen.

6. Sandbox-Isolation prüfen

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

Bestätigen Sie mode: all, network: none und keine Elevated-Überschreibungen.

7. Dateiberechtigungen prüfen

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

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

8. systemd-Härtung prüfen

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 Geräte-Interfaces benötigt. Die obigen Härtungsdirektiven senken den Score vom Standard ~9.6 auf etwa 5.2.

9. UFW- und DOCKER-USER-Regeln prüfen

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 prüfen

ss -tulpn

Nur SSH (22), Nginx (80, 443) und OpenClaw (127.0.0.1:18789 bei npm oder 0.0.0.0:18789 über 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 veröffentlicht häufig Updates. Prüfen 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 führen 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. Änderungen am Konfigurationsformat kommen vor. Version 2026.3.7 führte 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 außerhalb des Servers. Das Konfigurationsverzeichnis enthält Ihre Auth-Tokens, Agenten-Konfigurationen und den Konversationszustand. Schützen Sie Backups mit derselben Sorgfalt wie die Live-Konfiguration: Verschlüsseln Sie sie mit gpg oder speichern Sie sie auf einem verschlüsselten Volume.

Log-Verwaltung

Logs in Echtzeit anzeigen:

journalctl -u openclaw-gateway -f

OpenClaw-Logs können 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	Lösung
Gateway startet nicht	Port 18789 bereits belegt	`ss -tulpn \| grep 18789` um den konfliktverursachenden Prozess zu finden
WebSocket-Verbindungen schlagen über Nginx fehl	Fehlende `Upgrade`- und `Connection`-Header	Prüfen 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	Prüfen Sie die Audit-Ausgabe und wenden Sie die empfohlenen Fixes an
Gateway von externer IP erreichbar	Docker/UFW-Bypass	Fügen Sie `DOCKER-USER`-iptables-Regeln wie oben beschrieben hinzu
TLS-Zertifikatsfehler	Certbot-Erneuerung fehlgeschlagen	Führen Sie `sudo certbot renew --dry-run` zur Diagnose aus
OOM-Kills auf dem VPS	Fehlendes `MemoryMax` in der systemd-Unit	Fügen Sie `MemoryMax=4G` im `[Service]`-Abschnitt hinzu

KI-Agent-Server absichern: Sandboxing, Firewall und MonitoringZu weitergehenden Sicherheitsthemen wie Rate Limiting und Monitoring für KI-Agent-Server lesen Sie den Secure AI Agent Server Guide (in Kürze verfügbar).

Verwandte Artikel