The Setup Process

The platform is open source under Apache 2.0. Deploy it on any Linux host or VM and run the setup wizard. It walks you through four steps: deploy, scan, connect, and go live.

setup-wizard — discovery
Step 1: Platform deployed
Linux host — 4 vCPU, 8 GB RAM allocated
 
Step 2: Subnet scan complete — 10.0.0.0/16
8 devices discovered via port fingerprinting:
10.0.1.1 443/tcp → FortiGate
10.0.1.2 22/tcp → Cisco IOS (SSH banner match)
10.0.10.50 8006/tcp → Proxmox VE
10.0.10.51 8006/tcp → Proxmox VE
10.0.20.10 5985/tcp → Windows (WinRM)
10.0.20.20 22/tcp → Linux (OpenSSH 8.9)
 
Step 3: Connecting devices — 6 of 8 verified
Type-specific credential forms, live connection testing
 
Step 4: Generate config & go live
customer.yaml auto-generated from wizard inputs

How Device Discovery Works

The wizard does not rely on SNMP, network topology databases, or manual device lists. It performs an active scan of the subnets you specify, using a combination of ARP sweeps, ICMP probes, and TCP SYN pings to find every live host. Devices that block ICMP are still discovered through TCP probing.

Once a host is found, the wizard performs port fingerprinting to determine the device type. This is not simple port matching — it combines open port signatures with service banner analysis:

  • 443/tcp with FortiOS HTTP header → FortiGate firewall. Credential form: API token + hostname.
  • 8006/tcp with PVE API response → Proxmox VE. Credential form: API token ID + secret.
  • 22/tcp with Cisco SSH banner → Cisco IOS/IOS-XE. Credential form: SSH username + password + enable secret.
  • 22/tcp with OpenSSH banner → Linux server. Credential form: SSH username + password or key.
  • 5985/tcp or 3389/tcp → Windows. Credential form: Domain\user + password (WinRM/HTTPS).

Key insight: The credential form adapts to the device type. A FortiGate does not ask for an SSH password. A Linux box does not ask for an API token. The wizard shows only the fields that device type needs, reducing errors and confusion during onboarding.

Live Connection Testing

Every credential is tested against the actual device before saving. When you enter an API token for a FortiGate, the wizard makes a real API call to /api/v2/monitor/system/status and verifies the response. When you enter SSH credentials for a Cisco router, the wizard opens a real SSH session, authenticates, and runs show version to confirm access.

There are no silent failures. If a connection test fails, the wizard tells you immediately — wrong password, unreachable host, certificate error, or permission denied. You fix it before moving to the next device, not three days later when the collector starts throwing errors in the logs.

setup-wizard — connection test
Testing: 10.0.1.1 (FortiGate)
[REST API] GET /api/v2/monitor/system/status
Connected — FortiGate-60F, FortiOS 7.4.4, SN: FGT60F...
 
Testing: 10.0.1.2 (Cisco IOS)
[SSH] Connecting with KexAlgorithms=diffie-hellman-group14-sha256
Connected — Cisco ISR 4331, IOS-XE 17.06.05
 
Testing: 10.0.20.10 (Windows)
[WinRM] HTTPS/5986 — NTLM authentication
Failed — Access denied. Verify username/password and WinRM HTTPS listener.

Auto-Generated Configuration

Once all devices are connected and verified, the wizard generates a complete customer.yaml from your inputs. This file defines every device, its connection parameters, credentials (encrypted), collector assignments, and polling intervals. No hand-editing. No YAML syntax errors.

The generated configuration is not a minimal skeleton that requires manual tuning. It includes:

  • Device hostnames, IPs, and types with correct collector assignments
  • Encrypted credentials stored in the appliance’s credential vault
  • Polling intervals tuned per device type (5-minute health cache for firewalls, real-time SSH for routers)
  • SIEM integration if a Wazuh instance was discovered during scanning
  • Syslog forwarding configuration for devices that support it

Deployment

The platform runs on any Linux host. Clone the repo, install dependencies, run the setup script. Deploy it on bare metal, in a VM, or in a container — your choice.

What Happens After Setup

Once setup completes, the platform starts its collectors immediately. Within minutes, you have live VIRP-signed data flowing from every connected device. The AI assistant is ready to answer questions about your infrastructure, and the anomaly baseline starts building from cryptographically verified observations.

If you add new devices later, the wizard can be re-run at any time to discover new hosts and add them to the configuration. Existing connections are preserved — the wizard only adds what is new.