Wazuh OpenClaw Autopilot mit Ollama statt Claude betreiben: Air-gapped Setup ohne Tailscale und ohne Cloud-API-Keys

Einleitung

„Autonomous SOC“-Ansätze klingen attraktiv: Alerts automatisch triagieren, zusammenhängende Incidents korrelieren, Evidence Packs erzeugen und Response-Pläne vorschlagen – idealerweise mit Human-in-the-Loop und klaren Policies. In der Praxis scheitert die Evaluierung aber oft an zwei Punkten: (1) das Projekt ist auf Cloud-LLMs (z. B. Claude) vorgeprägt und (2) die Referenzinstallation nutzt Tailscale für Zero-Trust-Networking. Dieser Beitrag zeigt, wie sich Wazuh-Openclaw-Autopilot technisch so umstellen lässt, dass Ollama lokal genutzt wird – ohne Anthropic/OpenAI Keys und ohne Tailscale im Testbetrieb.

Wichtig: Das Repository ist kein offiziell unterstütztes Wazuh-Feature; es ist eine Drittanbieter-Integration. Entsprechend sollte man es wie jede zusätzliche SOC-Automatisierung behandeln: isolieren, minimal berechtigen, observability aktivieren, und erst nach klaren Policy-Gates produktiv denken.

Ausgangslage / Problemstellung

Wazuh ist bereits installiert und läuft.
Zusätzlich existiert bereits ein „Wazuh MCP“-Baustein (MCP-Bridge zum Wazuh API-Zugriff) bzw. die Wazuh-API ist erreichbar.
Ziel: Autopilot wie im Repo beschrieben nutzen, aber
- statt Claude/Anthropic ein lokales Ollama-Modell (z. B. Llama 3.x) verwenden
- ohne Tailscale im Test (air-gapped / bootstrap) installieren

Herausforderung: In der Doku/Beispielkonfiguration sind Cloud-Provider prominent, und die Model-/Provider-Auswahl ist nicht nur „.env“, sondern vor allem OpenClaw Gateway-Konfiguration (openclaw.json) plus ggf. „airgapped“ Variante.

Technische Analyse

1) Wo wird das LLM wirklich konfiguriert?

Im Repo ist OpenClaw „model-agnostic“. Die Provider-Auswahl läuft nicht über Wazuh selbst, sondern über die OpenClaw-Konfiguration – konkret über openclaw/openclaw.json (bzw. eine air-gapped Variante) und die dort gesetzten Modelle/Allowlist/Fallbacks.

Der .env-Teil /etc/wazuh-autopilot/.env wird zwar im Quickstart erwähnt, enthält aber primär Wazuh-Verbindungsdaten und optionale Provider-Keys. Ollama ist als Provider gelistet und benötigt im Prinzip keinen klassischen API-Key, aber die Gateway-Konfiguration muss es aktivieren und auf die richtige Base URL zeigen.

2) Zwei Ollama-Modi: „native“ API vs. OpenAI-kompatibel

OpenClaw unterstützt Ollama grundsätzlich über die native Ollama-API (z. B. /api/chat) und optional über den OpenAI-kompatiblen Pfad (/v1). Laut OpenClaw-Doku ist der native Weg der „Default“, insbesondere wenn Tool-Calling + Streaming zusammen funktionieren soll.
Im Repo-Beispiel ist Ollama jedoch häufig als OpenAI-kompatibel vorkonfiguriert (baseUrl .../v1). Das kann funktionieren, ist aber je nach Modell/Proxy-Setup nicht immer gleichwertig (z. B. bei Streaming/Tools).

3) Embeddings/Memory sind ein typischer Stolperstein bei „nur Ollama“

In der Referenzkonfiguration ist häufig eine Memory-/Embedding-Komponente aktiv, die auf OpenAI-Embeddings zeigt. Wenn man wirklich ohne Cloud arbeitet, muss man entweder

Memory/Embeddings deaktivieren oder
eine lokale Embedding-Quelle integrieren (je nach OpenClaw-Funktionalität/Projektstand)

Für air-gapped Tests ist Deaktivieren oft der sauberste erste Schritt, damit triage/correlation/investigation nicht an Embeddings scheitern. (In Deployment-Hinweisen wird genau dieser Punkt regelmäßig adressiert.)

4) Tailscale ist im Repo „recommended“, aber für Tests optional

Der Installer unterstützt explizit einen Modus „ohne Tailscale“ (--skip-tailscale). Damit ist ein lokaler Bootstrap möglich, ohne das Netzwerk-Overlay zu erzwingen.

Lösung / Best Practices

Schritt 1: Installation ohne Tailscale (Test/Bootstrap)

Gemäß Repo-README:

git clone https://github.com/gensecaihq/Wazuh-Openclaw-Autopilot.git
cd Wazuh-Openclaw-Autopilot
sudo ./install/install.sh --skip-tailscale

Damit wird Tailscale übersprungen, die restlichen Komponenten (MCP/ Gateway/ Runtime) werden weiterhin eingerichtet.

Schritt 2: Wazuh-Verbindung im Runtime-Environment setzen

In /etc/wazuh-autopilot/.env die Wazuh-API-Daten sauber setzen (Host/Port/User/Pass). Das ist unabhängig vom LLM-Provider.

Beispiel (Schema aus README, Werte anpassen):

WAZUH_HOST=localhost
WAZUH_PORT=55000
WAZUH_USER=wazuh-wui
WAZUH_PASS=...

Schritt 3: Ollama als Provider aktivieren und Claude/OpenAI deaktivieren

Der Kern ist openclaw/openclaw.json:

models.default auf ein Ollama-Modell setzen (z. B. ollama/llama3.3)
providers.ollama.enabled auf true
providers.anthropic.enabled / providers.openai.enabled auf false (oder API-Keys leer lassen und disabled setzen)
allowlist so anpassen, dass nur gewünschte lokale Modelle enthalten sind (härtet gegen „unerwartete Provider-Sprünge“)

Das Repo liefert bereits Modell-Namensschema „provider/model-name“ und listet Ollama explizit für air-gapped Deployment.

Wichtig zur Base URL:

Wenn OpenClaw direkt gegen die native Ollama API sprechen soll: Base URL wie in OpenClaw-Doku (http://ollama-host:11434) setzen.
Wenn ihr (warum auch immer) den OpenAI-kompatiblen Endpunkt nutzen müsst: Base URL auf http://ollama-host:11434/v1 und ggf. in OpenClaw explizit „openai-completions“ konfigurieren (mit Vorsicht bei Streaming + Tool-Calling).

Schritt 4: Agent-Defaults auf Ollama umstellen (Primary/Fallback/Fast/Heartbeat)

Neben models.default sollten auch die Agent-Defaults umgestellt werden, damit nicht einzelne Teilfunktionen (z. B. Heartbeats) weiterhin auf Claude zeigen. In der Repo-Konfiguration sind Heartbeats und mehrere Agentenmodelle explizit gesetzt.

Praktisches Muster für einen reinen Offline-Test:

primary: ollama/llama3.3
fallback: optional ebenfalls Ollama (oder leer, wenn wirklich kein Fallback)
fast: kleines lokales Modell für „cheap checks“ (wenn vorhanden)
heartbeat.model: auf dasselbe lokale Modell setzen

Schritt 5: Memory/Embeddings für den ersten Offline-Test deaktivieren

Wenn in openclaw.json „memory.enabled: true“ und Embeddings auf einen Cloud-Provider zeigen, scheitert das Setup oft „leise“ oder mit schwer interpretierbaren Errors. Für den ersten Erfolg (Triage → Case → Plan) empfiehlt sich:

memory.enabled auf false setzen, bis ein lokales Embedding-Konzept sauber integriert ist.

Schritt 6: Runtime prüfen (Health/Metrics)

Der Repo-Quickstart nennt Health- und Metrics-Endpunkte (Standardport 9090).

curl http://localhost:9090/health
curl http://localhost:9090/metrics

Damit lässt sich verifizieren, dass Service und Observability laufen, bevor man tiefer in Agent-Workflows einsteigt.

Schritt 7: Ressourcen- und Isolations-Best-Practices (Ollama lokal)

Ollama nicht auf dem Wazuh-Kernsystem betreiben, wenn es sich vermeiden lässt: lokale LLMs ziehen CPU/RAM (und ggf. GPU) und können die SIEM-Pipeline beeinflussen.
Netzwerkseitig: auch ohne Tailscale im Test sollte man die Services an Loopback binden und nur gezielt öffnen. Das Repo beschreibt explizit „localhost only“ Bindings für zentrale Komponenten.
Human-in-the-loop nicht „wegoptimieren“: Das Projekt beschreibt ein zweistufiges Approval; das ist bei automatisierten Response-Plänen ein Sicherheitsnetz, das man im Test bewusst beibehalten sollte.

Lessons Learned / Best Practices

LLM-Provider ≠ .env: Entscheidend sind openclaw.json (Provider enabled, baseUrl, allowlist) und die Agent-Modelle, nicht nur das Environment-File.
Air-gapped heißt auch Embeddings klären: Ohne Cloud-Embeddings braucht es entweder lokale Embeddings oder „Memory off“ als erster Meilenstein.
Ollama-API-Modus bewusst wählen: Native Ollama-API ist in OpenClaw explizit vorgesehen; der OpenAI-kompatible Modus kann Einschränkungen haben.
Wazuh-seitig minimal berechtigen: Der Autopilot nutzt Wazuh API und ggf. Active Response. Für Tests separate API-Credentials und strikt benötigte Rechte vorsehen.
Alternativen für „offiziellere“ LLM-Use-Cases: Wenn das Ziel primär Alert-Enrichment/Threat Hunting ist, gibt es offizielle Wazuh PoC-Ansätze (z. B. LLM Alert Enrichment, lokale LLM Threat Hunting mit Ollama/Llama 3).

Fazit

Das Umstellen von Wazuh-Openclaw-Autopilot auf Ollama ohne Cloud-Keys ist weniger „Code ändern“ als „Konfiguration richtig setzen“: Installer ohne Tailscale starten, Wazuh-Verbindung in .env eintragen, in openclaw.json Ollama aktivieren (und Claude/OpenAI deaktivieren), Agent-Modelle vollständig auf ollama/... drehen und für den ersten air-gapped Erfolg Memory/Embeddings deaktivieren. So bekommt man einen belastbaren Testpfad für „autonomous SOC“-Workflows, ohne Daten nach außen zu geben.