CyberCLI
Sign in →

← All recipes · Connectors

Connect your first Wazuh manager

~12 minutes

Point CyberCLI at an existing Wazuh manager, watch the first alerts flow through the SOC pipeline, and verify the audit chain advances.

Last updated 2026-06-07 · 3 steps

§1

Prerequisites

§2

What you'll do

You'll create a least-privileged Wazuh API user, configure CyberCLI's Wazuh connector with the credential vaulted, and watch the first signals flow from a real Wazuh alert through the SOC pipeline to the dashboard /signals tail.

§3

Steps

Step 1

Create a read-only Wazuh API user

On the Wazuh manager, create a user with the `readonly` role and only the API endpoints the connector needs. The connector polls /agents (for inventory) and /alerts (for the alert stream).

If your Wazuh is behind a reverse proxy, note the FQDN + the TLS posture (self-signed certs need an explicit pin).

# on the Wazuh manager
$ /var/ossec/bin/manage_users add cybercli-readonly
# follow the prompts; record the username + password securely
Verify

From the CyberCLI host: `curl -k -u cybercli-readonly:<pw> https://<wazuh-host>:55000/agents` returns the agent roster as JSON.

Step 2

Run the connector install verb

CyberCLI bundles the Wazuh connector. The setup verb writes a connector manifest entry, vaults the credentials, and configures the polling cadence.

The vault prompts handle the password securely — you paste it once at the prompt, never on the command line, and it's encrypted with AES-GCM under the engine's master key.

$ cybercli setup install-wazuh
Verify

The verb prints `Wazuh connector enrolled` and `audit row recorded: connector_enrolled`. `cybercli doctor` now shows wazuh under the component inventory.

Step 3

Open /connectors → Wazuh and tail signals

The dashboard's /connectors page now shows Wazuh with a 'healthy' badge and an event counter that starts at 0. Within ~60 seconds the first poll lands and the counter begins incrementing.

Switch to /signals to see the alerts arriving as rows. Each row is a real Wazuh alert that's been normalized into a CanonicalEvent and gated by the AuthorityBridge.

Verify

Within 2 minutes /signals shows at least one row from Wazuh. The audit chain head advances; `cybercli audit head` returns a higher seq than before the install.

§4

Verify end to end

§5

Troubleshoot

Wazuh connector card shows health = red with 'auth failed.'

Cause The vaulted credentials are wrong, or the API user lost its role.

Fix Re-run `cybercli setup install-wazuh` to re-vault the password. If the auth still fails, verify on the Wazuh manager that the user still exists + has the readonly role.

Connector card shows health = yellow with 'TLS verify failed.'

Cause Wazuh's API certificate is self-signed and the connector is configured to verify (default).

Fix Either install a CA-signed cert on Wazuh (preferred), or configure the connector to pin the self-signed cert (in /connectors → Wazuh → Edit → `tls_pin_sha256`).

Events flow but /signals shows them all with disposition=FP-BENIGN.

Cause The AI lane is off OR the digest provider isn't routing yet (still booting). The events still record; only the AI-derived disposition is the default.

Fix Verify /settings → AI engine shows a non-off lane and the provider is healthy (`cybercli doctor` includes a benchmark). Once the lane is up, new events arrive with AI-derived dispositions.

What to do next

Install CyberCLI from scratch

From a fresh Ubuntu VM (or LXC) to a running engine with the dashboard open at /first-30-minutes, in about 8 minutes.
Wire the local AI lane via Ollama

Run the entire AI digest path on a local Ollama server — no API costs, no data egress, full sovereignty.
Author your first suppression rule

Tell the SuppressionMatcher 'this pattern is noise' once — and have every future matching event silently dropped, with the audit chain still capturing the suppression.