So sichern und härten Sie OpenClaw auf einem VeerHost-VPS

OpenClaw auf einem VPS zu betreiben gibt Ihnen volle Kontrolle, macht Sie aber auch für die Server-Sicherheit verantwortlich. Diese Anleitung zeigt Ihnen, wie Sie Ihren VeerHost-VPS absichern, damit Ihre OpenClaw-Bereitstellung schwerer zu scannen, auszunutzen oder zu missbrauchen ist.

Hinweis: Einige ältere Anleitungen bezeichnen OpenClaw möglicherweise noch als Moltbot oder Clawdbot. Dieses Dokument verwendet den aktuellen Namen: OpenClaw.

Sicherheitsprinzipien

Bevor Sie etwas ändern, beachten Sie diese Regeln:

• Möglichst wenige Ports öffnen
• Dienste mit minimalen Rechten ausführen
• Geheimnisse aus öffentlichen Repositories heraushalten
• HTTPS für öffentlich erreichbare Endpunkte verwenden
• OS und Pakete aktuell halten
• Logs überwachen und Fehlstarts schnell beheben

1) Das System aktuell halten

Führen Sie regelmäßig Updates aus:

sudo apt update && sudo apt -y upgrade

Aktivieren Sie automatische Sicherheitsupdates, wenn das für Ihren Arbeitsablauf passt:

sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

2) Einen sudo-Benutzer anlegen und Root-Login im Alltag vermeiden

Wenn Sie noch als Root arbeiten, erstellen Sie einen dedizierten Admin-Benutzer:

adduser openclawadmin
usermod -aG sudo openclawadmin

Testen Sie den sudo-Zugriff:

su - openclawadmin
sudo whoami

3) SSH-Schlüssel verwenden

Erzeugen Sie auf Ihrem lokalen Rechner einen Schlüssel, falls noch keiner vorhanden ist:

ssh-keygen -t ed25519

Kopieren Sie ihn auf den Server:

ssh-copy-id openclawadmin@YOUR_VPS_IP

Login testen:

ssh openclawadmin@YOUR_VPS_IP

4) SSH härten

Bearbeiten Sie die SSH-Konfiguration:

sudo nano /etc/ssh/sshd_config

Empfohlene Einstellungen:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding no

Laden Sie SSH neu:

sudo systemctl reload ssh

Wichtig: Stellen Sie sicher, dass Ihr SSH-Schlüssel funktioniert, bevor Sie die Passwortanmeldung deaktivieren.

5) Firewall konfigurieren

Erlauben Sie nur die nötigen Verbindungen:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80
sudo ufw allow 443
sudo ufw enable
sudo ufw status verbose

Wenn OpenClaw hinter Nginx läuft, exponieren Sie den internen App-Port nicht öffentlich.

6) OpenClaw nur an localhost binden

Wenn OpenClaw auf Port 3000 lauscht, binden Sie es an 127.0.0.1 statt 0.0.0.0.

Beispiel für Docker-Portbindung:

ports:
  - "127.0.0.1:3000:3000"

So verhindern Sie den direkten öffentlichen Zugriff und erlauben Nginx weiterhin, Anfragen lokal weiterzuleiten.

7) Nginx vor OpenClaw schalten

Ein Reverse Proxy hilft bei:

• HTTPS-Beendigung
• Sauberem Domain-Routing
• Optionaler Basic Auth
• Rate Limiting
• Verbergen interner Ports

Ein einfaches Beispiel:

server {
    listen 80;
    server_name bot.yourdomain.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

8) HTTPS aktivieren

Certbot installieren:

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d bot.yourdomain.com

Das ist besonders wichtig, wenn OpenClaw Webhooks, Dashboards oder Admin-Endpunkte über das Web nutzt.

9) Umgebungsdateien und Geheimnisse schützen

Ihre .env-Datei darf niemals für alle lesbar sein.

Berechtigungen prüfen:

ls -l .env

Sichere Berechtigungen setzen:

chmod 600 .env

Best Practices:

• .env niemals in Git committen
• Tokens nach Leaks rotieren
• Starke Datenbankpasswörter verwenden
• API-Keys aus Screenshots, Logs und Anleitungen heraushalten

10) Datenbank absichern

Wenn PostgreSQL oder MySQL nur von OpenClaw genutzt wird, halten Sie es privat.

Gute Praxis:

• Datenbankdienste an localhost oder internes Docker-Netzwerk binden
• Keine öffentlichen Datenbank-Ports öffnen
• Einen dedizierten Datenbankbenutzer mit eingeschränkten Rechten verwenden
• Datenbank regelmäßig sichern

Offene Ports prüfen:

sudo ss -tulpn

11) Fail2Ban hinzufügen

Installieren Sie Fail2Ban, um Brute-Force-Angriffe zu reduzieren:

sudo apt install -y fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Status prüfen:

sudo fail2ban-client status

12) Dashboard- und Webhook-Zugriff begrenzen

Wenn OpenClaw ein Admin-Panel, Dashboard oder Webhook-Endpunkt enthält:

• Schützen Sie ihn mit HTTPS
• Fügen Sie nach Möglichkeit Authentifizierung hinzu
• Beschränken Sie den Zugriff per IP, wenn nur Sie Zugriff brauchen
• Verwenden Sie starke, zufällige Geheimnisse
• Deaktivieren Sie ungenutzte Endpunkte

13) Logs beobachten

Prüfen Sie Logs regelmäßig auf fehlgeschlagene Anmeldungen, wiederholte Abstürze oder verdächtige Anfragen.

Docker-Logs:

docker compose logs -f openclaw

System-Auth-Logs:

sudo journalctl -u ssh -n 100 --no-pager

Nginx-Logs:

sudo tail -f /var/log/nginx/access.log /var/log/nginx/error.log

14) Wichtige Dateien sichern

Mindestens sollten Sie sichern:

• .env
• docker-compose.yml
• Nginx-Konfiguration
• Datenbank-Dumps

Beispiel für ein PostgreSQL-Backup:

docker exec -t openclaw_postgres pg_dump -U openclaw_user openclaw > openclaw_backup.sql

15) Nach Änderungen sicher neu starten

Wenn Sie Umgebungsvariablen, Proxy-Einstellungen oder Docker-Konfiguration ändern, starten Sie den Stack sauber neu:

docker compose down
docker compose up -d

Dann prüfen Sie:

docker compose ps
docker compose logs --tail=50

Häufige Fehler vermeiden

• Port 3000 offen im öffentlichen Internet lassen
• Root-SSH-Login aktiviert lassen
• Schwache Passwörter für Datenbank oder Bot-Tokens verwenden
• Geheimnisse in GitHub-Repositories speichern
• Veraltete Docker-Images monatelang betreiben
• Datenbankports wie 5432 oder 3306 öffentlich exponieren

Kurze Hardening-Checkliste

• System aktualisiert
• SSH-Schlüssel aktiviert
• Root-SSH deaktiviert
• Firewall aktiviert
• OpenClaw an localhost gebunden
• Nginx-Reverse-Proxy eingerichtet
• HTTPS aktiviert
• .env abgesichert
• Datenbank nicht öffentlich exponiert
• Fail2Ban installiert
• Backups getestet
• Logs überwacht