Deployment Types

When you create a cluster, the first step of the Cluster Setup Wizard asks how IDSTower should take charge of your Suricata hosts. There are two choices, and the one you pick decides how much of the host IDSTower touches.

Fresh Installation

IDSTower installs Suricata itself and fully manages it from then on: it installs the packages, owns the configuration, deploys rules and IOCs, controls the services and monitors their health.

This is the right choice for a host that is not yet running Suricata, or one you are happy for IDSTower to take over completely.

Note

If IDSTower finds Suricata already installed on a host during a Fresh deployment, it stops before changing anything on that host and tells you which host is affected, so a mistyped hostname cannot silently replace a working installation. If you did intend to replace it, tick Take over the existing Suricata installation and continue.

Onboard Existing Suricata

IDSTower connects to hosts that already run Suricata over SSH and adopts what it finds, rather than installing anything. This lets you bring an existing deployment under management — for monitoring, for rules, or eventually for full configuration management — without rebuilding it.

What IDSTower detects

During onboarding IDSTower inspects each host and discovers, per Suricata instance:

  • the systemd service that runs it

  • the configuration file it was started with

  • its rules directory and its log directory

  • the network interfaces it is monitoring

  • the path of the Suricata binary

  • the installed Suricata version

Rather than assuming a layout from the distribution name, IDSTower asks the host directly — which is what allows it to onboard hosts whose paths do not match their distribution’s convention.

Warning

IDSTower replaces the existing Suricata configuration only if you tick Configuration Management during onboarding. It then stops and disables the existing Suricata services, deletes their configuration and unit files, and deploys its own configuration, once you have ticked I understand that existing Suricata services will be stopped and configuration will be overwritten. The same step offers Backup existing Suricata configuration before onboarding, ticked by default, which first archives each host’s existing configuration to /var/lib/idstower/backups/suricata-pre-onboard-<timestamp>.tar.gz. See Enabling Configuration Management later for what the archive holds.

Without Configuration Management no backup is taken, because the configuration stays in place. The one edit IDSTower can make to it is the opt-in Auto-register rule files in suricata.yaml option, which adds IDSTower’s rule files to suricata.yaml.

Reviewing the detected instances

The wizard shows what it found on each host so you can confirm or correct it before the cluster is created. Values IDSTower could not determine are left for you to fill in; a host that reports no usable Suricata instance is reported rather than silently skipped.

Adding hosts later

An onboarded cluster is not frozen. You can add further hosts to it afterwards from the cluster’s Hosts tab, and they go through the same detection flow. On a cluster with Configuration Management enabled, adding a host replaces its existing Suricata configuration; the Add New Hosts dialog offers the same backup option, ticked by default.

Which capabilities apply

A Fresh Installation is fully managed by definition — IDSTower installed Suricata, so every management capability is in force and there is nothing to choose.

Onboarded clusters are the ones with a choice: you decide how much of the existing installation IDSTower should take responsibility for, and you can change that at any time afterwards. See Management Capabilities.