How the connector works
The connector exists to answer one question safely: how does a cloud service read your Wazuh alerts without you exposing anything?
The model: dial out, pull through
your network Mobius cloud
┌───────────────────────────────┐ ┌──────────────────────┐
│ Wazuh indexer node │ │ │
│ ┌──────────────────────────┐ │ mTLS │ connector gateway │
│ │ mobius-connector │──┼────────►│ (session held open) │
│ │ ├─ indexer :9200 (local)│ │ :443 │ ▲ │
│ │ └─ manager :55000 (local)│ │ │ │ queries │
│ └──────────────────────────┘ │ │ Mobius pulls │
└───────────────────────────────┘ └──────────────────────┘
- The connector dials out over
:443with an mTLS identity issued at enrollment, and holds the session open. - Mobius pulls on demand: it sends read queries down the session; the
connector executes them locally against the indexer (
:9200) and the Wazuh manager API (:55000) and returns the results. - The connector never pushes data on its own, and the indexer / Wazuh API credentials never leave the node.
Guardrails
- Read-only allowlist. The query router only executes a fixed allowlist of read operations. The single write path — the Incident Response action — is a separate, explicitly-gated call (see Incident response).
- Per-target health probes ride the heartbeat, so the console can tell you which side of the connector is unhealthy (indexer vs manager API).
- Single-use enrollment. The token from the environment card enrolls exactly one connector; the service then runs tokenless with its mTLS identity stored locally.
Why not expose the indexer?
The legacy model — a publicly reachable :9200 and the customer's indexer
password stored in the cloud — is exactly what this replaces. With the
connector, nothing in your network listens for Mobius, and Mobius holds no
credential that could reach your data if leaked.