Your sensors are in production, tuned the way you need them. IDSTower connects over SSH, detects each Suricata instance, backs up the existing configuration, and adopts what it finds. Nothing is reinstalled; nothing changes until you say so.
During onboarding IDSTower inspects each host and discovers, per Suricata instance, what is actually there — asking the host rather than assuming a layout from the distribution name. That is what lets it adopt a host whose paths do not match its distribution's convention, including a Suricata you compiled yourself.
The wizard then shows you what it found on each host so you can confirm or correct it before the cluster is created. Anything it could not determine is left for you to fill in, and a host with no usable Suricata instance is reported rather than silently skipped.
Including a unit you wrote yourself, and the command line it was actually started with.
The configuration file the service was started with, and the rule and log paths it reads and writes.
Asked of Suricata directly where possible, so the answer is right regardless of capture method.
Resolved from the running process, so a source build or a custom install prefix is found correctly.
Each with its own service, configuration and interfaces. Managing more than one instance per host requires an Enterprise license.
An onboarded cluster has six management capabilities. Each is independent, and each can be switched on or off at any time afterwards — adopting a deployment does not mean surrendering it.
Collects metrics, service status and resource usage from the hosts.
Pushes IDS rules and threat-intelligence indicators to the Suricata hosts.
Cleans up Suricata log files by retention period and disk usage.
Starts, stops and restarts the Suricata services.
Installs and upgrades the Suricata and Filebeat versions. Leave this off permanently if you compiled Suricata yourself.
Owns and deploys suricata.yaml and the cluster's configuration profile.
Out of the box that means IDSTower manages your rules and reports the health of your sensors, and does not touch your suricata.yaml, your packages or your services. Turning a capability off later removes what IDSTower put in place for it, and IDSTower tells you up front when that is what will happen.
Onboard with monitoring only. IDSTower changes nothing on your hosts — you get central visibility of every sensor, and your deployment carries on exactly as before.
Enable rules management and stop editing rule files over SSH. Your customizations are preserved when feeds publish new revisions, and your suricata.yaml is still yours.
Configuration, services and package upgrades when IDSTower has earned it — or never. A backup of your configuration is taken before anything changes, either way.
Those go through a Fresh Installation: IDSTower installs Suricata itself and manages it fully from then on — packages, configuration, rules, services and health. There are no capabilities to choose, because IDSTower installed it and manages every aspect of it.
If IDSTower finds Suricata already installed on a host during a fresh deployment, it stops before changing anything and tells you which host is affected. A mistyped hostname cannot silently replace a working installation.
Onboarded clusters and freshly installed clusters live side by side in the same interface, with the same rules, feeds and IOC management across all of them.
An onboarded cluster is not frozen. Further hosts can be added from the cluster's Hosts tab and go through the same detection flow.
Yes. IDSTower resolves the real binary path from the running process rather than assuming a packaged location, and reads the version and build flags from the binary itself. Leave Package Management switched off and IDSTower will never install, upgrade or replace it.
Yes, and that is close to the default. Rules Management and Health Monitoring are on for a new onboarded cluster; Configuration Management, Service Control and Package Management are off. You can also turn monitoring off and run rules alone.
A backup of the existing Suricata configuration is taken on the host before anything is changed. With Configuration Management off, IDSTower does not own or rewrite suricata.yaml at all — your thresholds, suppressions and performance settings stay exactly where you put them.
Capabilities can be changed at any time from the cluster's Summary tab. Turning one off removes what IDSTower put in place for it, and IDSTower tells you up front when that is what will happen.
SSH access to each Suricata host, using credentials or a key you provide. There is no agent for you to install by hand, and IDSTower does not need to be reachable from the sensors.
No. Onboarding is available on every license, including the free Standard one, which covers a single Suricata instance. See the licensing page for how instances are counted.
A single self-supported host costs nothing, and the live demo needs no signup.
Try the live demo Get a free licensePrefer to read first? How onboarding works · What each capability controls · Our blog post on adopting a tuned deployment