UniFi

What it watches

• Firewall + IPS/IDS events from the UDM/USG
• Admin audit — controller logins, config + firmware changes
• Client connect/disconnect + roaming activity
• Rogue-AP + DHCP-anomaly detections
• Port-forward + WAN-rule changes

MITRE ATT&CK coverage

Tactics this connector gives CyberCLI visibility into.

Every matrix-covered event_type on the passthrough lane — pinned by the engine's coverage matrix. The right column shows the operator-friendly phrase the dashboard renders. High-severity AI-lane signals are summarized in What it watches above (Warden + Herald handle those); the rest take the substrate's passthrough lane (no AI tokens burned).

What it helps you catch

UniFi events arrive from the controller's Events API + DPI engine. The 20 fields we read carry the full network picture: who the client is (MAC + vendor), where they're going (destination IP, port, app, DPI signature), what the controller flagged (threat category, action taken), and what already happened (block, allow, alert). Enough context to verify a threat and authorize a UniFi-side response without leaving the dashboard.

{
  "event_id": "evt_2026051213_002",
  "site_id": "site_main",
  "timestamp": "2026-05-12T13:01:00.000Z",
  "type": "dpi_threat",
  "severity": "high",
  "client_mac": "aa:bb:cc:dd:ee:ff",
  "src_ip": "192.168.1.42",
  "dst_ip": "198.51.100.99",
  "dst_port": 443,
  "ap_mac": "00:11:22:33:44:55",
  "hostname": "usg-edge",
  "rule_id": "ips_signature_42",
  "message": "DPI signature match: known C2 destination"
}

Field count + sample event auto-derived from src/cybercli/connectors/unifi/vector.vrl at build time. Numbers update the moment the engine's parser changes — no drift.

Close more of the kill chain

UniFi covers 3 of 14 ATT&CK tactics. Pair it with these to widen coverage:

CrowdStrike Pro

+9 new tactics

SentinelOne Pro

+9 new tactics

Wazuh

+9 new tactics

How to connect

1. 1 In your UniFi controller, create a read-only API user / API key.
2. 2 Run `cybercli onboard unifi` with the controller URL + key (vault-stored).
3. 3 CyberCLI polls the controller API for events.
4. 4 Confirm in the dashboard's Connectors panel. (UniFi Protect camera events arrive as the Pro tier matures.)

Already deployed Ubiquiti gear? Generate an API key in your UniFi controller → `cybercli onboard unifi`

Pre-flight

1. 1

   Confirm UniFi OS 5.0+ / Network 9.3+

   The SIEM Server forwarder shipped in UniFi Network 9.3.43 and stays the canonical syslog surface through 10.x. On older firmwares the menu structure below doesn't exist and the legacy Remote Logging panel must be used instead.

2. 2

   The CyberCLI host's IP is reachable from your UDM-Pro on UDP 514

   UniFi managed devices forward via UDP syslog (not HTTPS, despite the SIEM Server label). The UDM-Pro must be able to send to your CyberCLI host's IP on UDP 514. Inter-VLAN routing has to allow it.

   ping -c 2 <cybercli-host-ip>   # from the UDM-Pro's terminal if SSH is on, or from any device on the management VLAN

3. 3

   Vector substrate is up on the CyberCLI host

   If `cybercli setup install-syslog` hasn't been run, port 514 isn't bound and every packet the UDM-Pro sends bounces with ICMP port-unreachable. The UDM-Pro silently retries forever without surfacing the failure in its UI.

   sudo ss -lnup | grep :514

Configure

1. 1

   Onboard the connector in CyberCLI first — multi-IP form for UDM-Pro 9.x+

   On your CyberCLI host

   UDM-Pro 9.x/10.x routes its syslog from whichever interface reaches the collector — usually the LAN-side IP, NOT the management IP you configured in the controller UI. The single-IP guard form silently aborts the right events. Pass BOTH IPs separated by a comma: the management IP (so when you look at the connector record, it tells you which appliance) and the egress IP (so the VRL guard actually accepts the wire).

   command

   cybercli setup add-syslog-source --connector unifi --source-ip 10.10.0.1,10.100.0.1

   first IP (canonical)

   <UDM-Pro management IP, e.g. 10.10.0.1>

   Becomes the slug + identity for forensic queries.

   second IP (egress)

   <UDM-Pro LAN-side IP on the VLAN that reaches CyberCLI, e.g. 10.100.0.1>

   Find with `ip route get <cybercli-host-ip>` from the UDM-Pro.

   Why this

   Without the second IP the substrate is functionally invisible — packets arrive, Vector's syslog source parses them, and the VRL `if src_ip != management_ip { abort }` drops every single one. Zero error surface, zero events. This is the single most-common silent failure on UDM-Pro deployments.

2. 2

   Open the SIEM Server panel

   UniFi Network → Settings → Control Plane → Integrations → System Logging / SIEM

   This is the surface that ships syslog in current firmware. In the right-side drawer you'll see three radio options: Internally Stored, SIEM Server, and (older builds) Off. Pick SIEM Server. Despite the name, the wire format is plain RFC5424 syslog carrying CEF — there is no HTTPS handshake, no Splunk HEC, no API key. Any syslog UDP receiver that understands CEF works.

   Important

   DO NOT use 'Internally Stored'. That mode keeps logs on the controller only and never emits them to your CyberCLI host. The radio matters more than the Server Address field — a perfectly-typed IP under Internally Stored sends zero packets.

3. 3

   Set the destination + port

   Same panel · Server Address + Port

   Set the address and port. The UI doesn't reach back to verify; whatever you type is what the UDM-Pro will try.

   Server Address

   <CyberCLI host IP>

   Use the IP your UDM-Pro can actually reach — see preflight check 2. Hostnames work if your management VLAN has DNS for them, but raw IP is safer.

   Port

   514

   UDP. Vector also listens on TCP 6514 for encrypted forwarding but SIEM Server in current firmware emits plaintext UDP.

   Include Raw Logs

   on (recommended)

   Without this the CEF payload is structured-only and you lose the original message text — Warden's context window benefits from both.

4. 4

   Pick categories — at minimum Critical + Triggers + Admin Activity

   Same panel · Categories chip selector

   UniFi splits emitted events into 14 categories. The defaults are conservative; Critical, Triggers, and Admin Activity are the three you cannot operate without regardless of tier. Client Devices is noisy but valuable when paired with anomaly detection — leave it on for Pro and above.

   Critical

   on (mandatory)

   System-impacting events. Promoted automatically to high signal by the VRL pack.

   Triggers

   on (mandatory)

   Rule-fired events including firewall blocks + IDS detections. Promoted automatically.

   Admin Activity

   on (mandatory)

   Controller logins + config changes. First sign someone's in your management plane.

   Device + Client + Updates

   on (recommended)

   Noisier but feeds Warden the context it needs to correlate.

5. 5

   Save + apply — and click Send Test Event

   Same panel · top-right Apply button + Send Test Event link

   The save action commits the config to the controller. The Send Test Event button below the Port field emits a synthetic CEF packet with category=Critical immediately — this is the canonical instant-verify. If you see a packet land on the CyberCLI side within seconds, the wire path is good. If you don't, either the destination IP / port is wrong, the UDM-Pro send-socket is in the 9.x/10.x stuck-after-config-apply state (reboot the controller), or your inter-VLAN firewall is dropping UDP 514.

Verify

1. 1

   Confirm packets actually arrive on the wire (definitive test)

   sudo tcpdump -nni any 'dst host <cybercli-host-ip> and udp dst port 514' -c 5

   You should see

   IP 10.100.0.1.46312 > 10.100.0.206.514: ... length 396

   If this fails

   If 0 packets in 30 seconds AFTER clicking Send Test Event: the UDM-Pro is not emitting. Reboot the UDM-Pro (the SIEM Server send-socket is documented to stay closed until controller restart in some 9.x/10.x builds) and retest. If still nothing: check inter-VLAN routing + that no upstream firewall rule is blocking UDP 514 between your management and CyberCLI VLANs.

2. 2

   Confirm Vector parsed packets into events ndjson

   sudo zcat /var/opt/cybercli/syslog/events/unifi-<management-ip>/$(date +%Y-%m-%d).ndjson.gz | tail -1 | python3 -m json.tool

   You should see

   "cybercli_connector": "unifi", "cybercli_wire_format": "unifi_cef", "unifi_class": "wifi.connected"

   If this fails

   If packets are arriving (tcpdump above shows them) but the events file is empty: the VRL guard is aborting them because the source_ip in the packet doesn't match either IP you passed to --source-ip. Verify with `sudo tcpdump -nni any 'dst host <cybercli-host-ip> and udp dst port 514' -X` and look at the source IP — re-run `cybercli setup add-syslog-source --force` with that IP added to the comma-separated list.

3. 3

   Confirm the dashboard shows real events flowing

   open http://<cybercli-host-ip>:8090/connectors/unifi   # or your reverse-proxy URL

   You should see

   Last event: <timestamp within 1 minute>   ·   Events today: <non-zero>

   If this fails

   Substrate green (events file growing) but dashboard says zero: the syslog-ingest service may not be running. `sudo systemctl status cybercli-syslog-ingest` should show active (running) with recent log lines processing events.

Pitfalls (what bit us so it doesn't bite you)

Troubleshoot

FAQ

Go deeper