Skip to main content

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 :443 with 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.