Building Hermes in a Homelab: UniFi, Wazuh, and AI-Assisted Network Anomaly Detection

The first Hermes post described the idea: a UniFi Dream Machine sends security telemetry into Wazuh, and Hermes acts as a read-only analysis layer that helps explain what may be unusual.

This follow-up is about building a practical first version in a homelab.

The goal is not to hand an AI agent the keys to the network. The goal is to build a useful pipeline:

UniFi logs → Wazuh alerts and history → Hermes investigation → human decision

Start with observation. Make the data trustworthy. Tune the noisy parts. Only then consider limited response automation.

What you need

A simple homelab version can run on one reasonably capable Linux server or VM:

• A UniFi Dream Machine or other UniFi gateway
• A Linux VM for Wazuh
• Enough storage for retained logs
• A separate small VM, container, or service for Hermes
• A private management VLAN or otherwise protected management network
• A password manager or secrets store for service credentials

For a modest home network, 4 CPU cores, 8 GB of RAM, and 100 GB of storage is a reasonable starting point for Wazuh. If you retain a lot of events or add several endpoints, plan for more storage before you need it.

Step 1: Put the security components on a management network

Before sending a single log, decide which systems are allowed to talk to Wazuh.

The Dream Machine should be able to send logs to the Wazuh server. Hermes should be able to query Wazuh. Ordinary client devices should not be able to reach the Wazuh management interfaces.

At minimum:

• Assign Wazuh a stable IP address.
• Keep Wazuh and Hermes on a management VLAN if your network supports one.
• Allow inbound syslog only from the Dream Machine's IP address.
• Allow Hermes to query only the specific Wazuh API or indexer interface it requires.
• Do not expose Wazuh's dashboard, API, or indexer directly to the public internet.
• Use unique credentials and change any default passwords before connecting real data.

Step 2: Install Wazuh and verify the dashboard

Install Wazuh using the deployment method that fits your homelab: single-node, Docker-based, or a more distributed installation if you already have the resources.

Before integrating UniFi, make sure Wazuh itself is healthy:

1. Sign in to the dashboard.
2. Confirm the manager, indexer, and dashboard services are running.
3. Check that you can view alerts and use the Dev Tools area.
4. Create a dedicated administrative account for setup, then a separate lower-privilege account for Hermes.

Wazuh stores triggered alerts in wazuh-alerts*, which can be queried through the indexer API. That makes it a useful source for a read-only analysis service such as Hermes.

Step 3: Configure Wazuh to receive UniFi syslog

Wazuh can receive syslog from firewalls, routers, switches, and other network devices that cannot run a Wazuh agent. Its syslog receiver can use TCP or UDP and should restrict accepted senders with an allowed-IP setting.

A basic Wazuh configuration might look like this:

<ossec_config>
  <remote>
    <connection>syslog</connection>
    <port>5514</port>
    <protocol>tcp</protocol>
    <allowed-ips>192.168.10.1</allowed-ips>
    <local_ip>192.168.20.10</local_ip>
  </remote>
</ossec_config>

Replace the example addresses with your Dream Machine and Wazuh server addresses.

A few practical notes:

• Use a non-privileged port such as 5514 if that suits your design.
• Prefer TCP when your UniFi version supports it and reliable delivery matters.
• If you use UDP, keep the path local and trusted; UDP is simpler but does not provide delivery assurance.
• Do not open the listener to an entire untrusted network range "just to make it work."
• Restart the Wazuh manager after changing its configuration.

Step 4: Send UniFi system and security logs to Wazuh

In current UniFi interfaces, log export is generally configured under:

Integration → System Logging / SIEM

Choose SIEM Server, enter the Wazuh server address and port, then select the log categories that matter. UniFi system-log exports can use Common Event Format, or CEF, and can include security, system, and client-activity events.

Start with a deliberately small set:

• Security events
• Gateway or firewall events
• Client connection events
• Administrative actions
• Configuration changes

Avoid turning on every category immediately. A noisy data source makes early tuning harder and can hide the events you actually care about.

Once enabled, generate a few harmless test events:

• Connect and disconnect a known device.
• Attempt to visit a blocked test domain, if you have a safe policy for testing.
• Change a noncritical network setting and change it back.
• Trigger a known firewall deny rule from a test device.

Then verify that the events arrive in Wazuh.

Step 5: Normalize before asking Hermes to reason

At this stage, Wazuh may have received logs without fully understanding every field inside them. That is normal.

The first goal is not perfect detection. It is confirming that the raw data is present, timestamped correctly, and tied to the right gateway.

Inspect several events and identify useful fields:

• Source IP and source MAC address
• Destination IP, hostname, port, and protocol
• VLAN or network name
• Action: allowed, denied, blocked, authenticated, disconnected
• Device name or client identifier
• Rule or event category
• Timestamp

If UniFi's CEF fields are not being parsed the way you need, create a custom Wazuh decoder and a few narrow rules. Do not begin with dozens of rules. Start with the three behaviors most relevant to your network.

For a homelab, strong early candidates are:

1. A new device joining a trusted or management network
2. Repeated blocked outbound connections from the same client
3. A device reaching a destination or port it has never used before

Step 6: Build a baseline before calling anything anomalous

A network is full of behavior that looks odd without context.

Smart televisions contact unfamiliar content networks. Phones roam between access points. Game consoles download large updates at night. Cameras generate a burst of traffic after a firmware update.

Give the system time to learn the normal shape of the network.

For the first two to four weeks, collect:

• Typical destinations per device
• Typical ports and protocols
• Typical active hours
• Typical outbound volume
• Common denied events
• Known device roles: camera, workstation, NAS, television, IoT sensor, phone

A simple baseline does not need a machine-learning platform. A small database can track first-seen destinations, event counts, rolling averages, and a device's normal hours.

Hermes should compare new activity to this baseline instead of asking, "Is this globally suspicious?" The better question is, "Is this unusual for this specific device on this network?"

Step 7: Give Hermes read-only access

Hermes should begin with no ability to change the Dream Machine, Wazuh configuration, firewall rules, VLAN assignments, or user accounts.

Wazuh provides both a server API and an indexer API. Server API calls use short-lived JWT authentication, while indexer queries can search alert data stored in Wazuh indices.

Create a dedicated Hermes account with the smallest practical permissions:

• Read alerts
• Read selected index data
• Read approved device or agent inventory
• No user management
• No configuration changes
• No active-response permissions
• No firewall or UniFi credentials

Store its credentials as secrets, not in source code or a prompt.

Hermes should query a bounded time window and a bounded set of fields. It does not need unrestricted access to every historical record in order to investigate a single device.

Step 8: Build Hermes as a simple investigation pipeline

The first version can be small:

1. Retrieve recent high-value Wazuh alerts
2. Group related events by device, destination, and time window
3. Compare the group to that device's baseline
4. Calculate a transparent risk score
5. Ask Hermes to write an evidence-backed summary
6. Send the summary to a dashboard, email, ticket, or review queue

A useful event package might look like this:

{
  "device": "garage-camera-02",
  "ip": "192.168.30.44",
  "time_window": "2026-10-13T02:00:00Z to 2026-10-13T03:00:00Z",
  "observations": [
    "184 blocked outbound connections",
    "37 first-seen DNS names",
    "3 new external IP addresses",
    "activity occurred outside the device's usual hours"
  ],
  "baseline": {
    "normal_destinations": "camera-vendor cloud services",
    "normal_active_hours": "06:00–23:00"
  }
}

Hermes can turn that package into a concise explanation, but it should not make up evidence that is not present.

A good response includes:

• What happened
• Why it differs from normal behavior
• Which events support the conclusion
• What remains uncertain
• The next safest investigative step

Step 9: Create a small set of meaningful anomaly rules

Do not try to detect everything. Start with rules that can be tested and tuned.

A practical first rule set might include:

• New device on management VLAN: Review device identity and network assignment.
• Repeated blocked outbound connections: Check destination, process, and device role.
• First-seen destination plus unusual volume: Investigate destination reputation and traffic pattern.
• Unusual DNS failure burst: Check for typos, misconfiguration, malware, or tunneling behavior.
• Internal port sweep pattern: Review source device and isolate only with human approval.
• Admin login or configuration change at an unusual time: Verify the administrator and change context.

The goal is not an impressive number of detections. It is a small number of alerts that people will actually investigate.

Step 10: Keep response automation behind approval

Once Hermes reliably produces useful reports, add a human approval step before any action.

A safe workflow is:

Hermes detects and explains
        ↓
A human reviews the evidence
        ↓
Hermes drafts a response
        ↓
An approved automation performs the change
        ↓
Wazuh verifies the result

For example, Hermes might recommend moving a suspicious IoT device to a restricted VLAN. It can prepare the proposed change and explain the expected impact. A person should approve it. The actual configuration change should be performed by a controlled workflow with logging and a rollback path.

That boundary matters. AI should make the operator faster and better informed, not silently become the network administrator.

The first success metric

Do not measure success by the number of alerts Hermes produces.

Measure whether it saves time during real investigation:

• Did it collect the relevant evidence correctly?
• Did it reduce dashboard hopping?
• Did it identify useful relationships between events?
• Did it avoid false certainty?
• Did the recommended next step make sense?
• Did it help you find an issue you would otherwise have missed?

If the answer is yes, the homelab version is working.

Hermes does not need to be autonomous to be valuable. A read-only agent that helps turn fragmented network events into a clear investigation story is already a meaningful improvement over staring at logs alone.