ClawHosters
von Daniel Samer
5 Min. Lesezeit
40.214 offene OpenClaw-Instanzen. SecurityScorecard hat die Zahl letzten Monat veröffentlicht. 63% davon sind verwundbar. Bei 12.812 ist Remote Code Execution bestätigt. Das sind keine Theorie-Szenarien. Das passiert gerade.
Peter Steinberger, der OpenClaw erfunden hat, sagt es selbst ganz offen: "Most non-techies should not install this. It's not finished, I know about the sharp edges." Trotzdem starten tausende Leute ihre Container, ohne eine einzige Einstellung zu ändern.
Ich habe jemandem zugesehen, der in 30 Sekunden API-Keys aus einer ungesicherten Instanz gezogen hat. Kein ausgefeilter Angriff. WebSocket-Verbindung, ein manipulierter Parameter, fertig. CVE-2026-25253, CVSS 8.8, funktioniert auf jeder Default-Konfiguration.
Hier ist, was du dagegen tun kannst.
Dockerfile Sicherheit: Hör auf, als Root zu laufen
58% aller Container laufen als Root. OpenClaw ist da keine Ausnahme.
Root im Container bedeutet: Jeder Exploit, der die Anwendung verlässt, hat volle Kontrolle. Über den Container und möglicherweise über den Host. Das ist das Erste, was du ändern solltest.
services:
openclaw:
user: "1000:1000"
security_opt:
- no-new-privileges:true
cap_drop:
- ALL
cap_drop: ALL ist wahrscheinlich die wirkungsvollste Änderung, die du machen kannst. Damit werden alle Linux-Capabilities entfernt, die der Container sonst erben würde. no-new-privileges verhindert, dass Prozesse im Container über setuid-Binaries oder ähnliche Tricks Rechte eskalieren.
Falls deine Anwendung bestimmte Capabilities braucht (selten bei OpenClaw), füge sie einzeln mit cap_add wieder hinzu. Aber starte bei null.
Container Sicherheit: Dateisystem sperren
Ein Read-Only-Root-Dateisystem verhindert, dass Angreifer Binaries verändern, Malware ablegen oder Persistence-Mechanismen in deinem Container installieren.
services:
openclaw:
read_only: true
tmpfs:
- /tmp
- /var/run
OpenClaw braucht ein paar beschreibbare Verzeichnisse für temporäre Dateien. Die mountest du als tmpfs, also nur im RAM und nach Neustart gelöscht. Alles andere bleibt schreibgeschützt.
Docker Schwachstellen-Scan und Image Pinning
Benutze niemals latest. Wirklich nie.
Wenn du openclaw:latest pullst, hast du keinerlei Garantie, was in dem Image steckt. Pinne stattdessen auf einen konkreten Digest.
image: openclaw/openclaw@sha256:abc123...
Netskope hat über 300 trojanisierte Docker-Packages mit LuaJIT-Payloads gefunden. Der Angriffsvektor? Entwickler, die ungeprüfte Images aus öffentlichen Registries pullen. Pinning auf einen bekannten Digest macht deine Builds reproduzierbar. Du vertraust nicht blind dem, was heute Morgen als latest aufgetaucht ist.
Scanne deine Images regelmäßig mit docker scout oder Trivy. Am besten automatisiert in der CI-Pipeline.
Netzwerk-Isolation: Nur auf Localhost binden
Standardmäßig lauscht das OpenClaw-Gateway auf allen Interfaces. Das bedeutet: Jeder, der deinen Server erreicht, erreicht auch deinen KI-Agenten.
services:
openclaw:
ports:
- "127.0.0.1:8080:8080"
networks:
- openclaw-internal
networks:
openclaw-internal:
driver: bridge
internal: true
Mit 127.0.0.1 erreicht nur lokaler Traffic das Gateway. Davor kommt nginx oder Caddy für TLS-Terminierung und Zugriffskontrolle.
Ein dediziertes Bridge-Netzwerk mit internal: true sorgt dafür, dass Container im Netzwerk nicht direkt ins Internet können. Dein KI-Agent muss nicht im Web surfen.
Beschränke, was OpenClaw wirklich darf
Den Teil überspringen die meisten Leute. Und ehrlich gesagt ist es der wichtigste.
OpenClaw hat ein system.run-Tool, das beliebige Befehle ausführen kann. Ohne Einschränkung kann dein KI-Agent alles tun, was der Container-User darf.
{
"tool_policy": {
"allowed": ["read_file", "write_file", "search"],
"denied": ["system.run"]
},
"workspace": {
"only": true,
"deny_patterns": [".ssh/**", ".aws/**", ".env*", "*.pem"]
}
}
workspaceOnly: true begrenzt den Dateizugriff auf das Projektverzeichnis. Deny-Patterns blockieren sensible Verzeichnisse. Und eine Tool-Policy-Allowlist stellt sicher, dass nur die Tools verfügbar sind, die du explizit freigibst.
Jeremy Turner von SecurityScorecard warnt: "Don't just blindly download one of these things and start using it on a system that has access to your whole personal life."
Ressourcen-Limits setzen
services:
openclaw:
deploy:
resources:
limits:
cpus: "2.0"
memory: 2G
ulimits:
nofile:
soft: 1024
hard: 2048
Ohne Limits kann ein fehlerhafter Agent oder ein Denial-of-Service-Angriff alle Systemressourcen auffressen. Harte Limits verhindern das.
Oder du sparst dir das alles
Hier ist die ehrliche Wahrheit. Jeder Härtungsschritt, den ich beschrieben habe, ist bereits in die ClawHosters Managed-Infrastruktur eingebaut. Hetzner Cloud Firewall mit Whitelist-Only-Zugriff, Docker-Daemon-Hardening mit no-new-privileges, fail2ban, SSH-Key-Only-Authentifizierung, automatische Sicherheitsupdates.
OpenClaw sicher selbst zu hosten kostet 20 bis 40 Stunden für das initiale Setup und 2 bis 4 Stunden pro Woche für laufende Wartung. Patches, Monitoring, Log-Auditing. Das ist echte Zeit, die du stattdessen zum Bauen nutzen könntest.
Schau dir unsere Sicherheitsübersicht an, oder lies den Vergleich Self-Hosted vs. Managed, wenn du noch unentschlossen bist. Es gibt auch eine kostenlose Testphase, falls du es einfach ausprobieren willst.
