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.
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.
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.