Management Capabilities¶

Management capabilities define what aspects of Suricata IDSTower manages for a cluster. Each one can be turned on or off independently, so you can let IDSTower monitor a deployment without letting it touch the configuration, or manage rules and IOCs while leaving package upgrades to your own tooling.

Important

Capabilities apply to clusters onboarded from an existing Suricata installation. A Fresh Installation is fully managed by IDSTower — it installed Suricata, so it manages every aspect of it — and has no capability settings to choose or change. The Enabled Capabilities panel described below is shown only on onboarded clusters.

For an onboarded cluster you choose the capabilities when the cluster is created, and you can change them at any time afterwards.

The six capabilities¶

Capability	What IDSTower does when it is enabled
Health Monitoring	Collects metrics, service status and resource usage from the hosts.
Rules Management	Pushes IDS rules and threat-intelligence indicators (IOCs) to the Suricata hosts.
Log Management	Cleans up Suricata log files automatically, by retention period and disk usage.
Service Control	Starts, stops and restarts the Suricata services.
Package Management	Installs, upgrades and manages the installed Suricata/Filebeat versions.
Configuration Management	Owns and deploys `suricata.yaml` and the cluster’s configuration profile.

Viewing and changing capabilities¶

On an onboarded cluster, the Summary tab shows an Enabled Capabilities panel listing all six with a tick or a cross. To change them, click the edit icon on that panel, adjust the toggles and confirm.

On a Fresh Installation the panel is not shown at all: every capability is in force and there is nothing to configure.

Note

Changing a capability only re-runs work on the hosts when it actually affects them. Turning a capability off removes what IDSTower had put in place for it, except Configuration Management (see Enabling Configuration Management later), and IDSTower tells you up front when that is what will happen.

Log Management settings¶

When Log Management is enabled, IDSTower installs a cleanup job on each host. It is controlled from the cluster’s settings:

Setting	Default	Meaning
Enabled	on	Whether the cleanup job is active on the hosts. Turning it off removes the job while keeping the capability enabled, so it can be switched back on without reconfiguring.
Retention (days)	`90`	How long Suricata log files are kept before deletion.
Disk utilization threshold	`50`	Disk usage percentage above which logs are deleted regardless of the retention period.
Run frequency (minutes)	`15`	How often the cleanup job runs.

Rules Management without Configuration Management¶

On an onboarded cluster you can push rules without handing IDSTower ownership of suricata.yaml. For Suricata to load those rules, its configuration has to reference them, so IDSTower offers to register the rule files for you.

When Auto-register rule files is enabled, IDSTower appends entries for idstower_suricata.rules, idstower_iprep_indicators.rules and idstower_datasets_indicators.rules to the existing rule-files: list in the detected suricata.yaml, inside clearly marked block delimiters.

Important

This is a deliberately minimal and reversible change, scoped to appending those entries — it does not give IDSTower ownership of the configuration file. It is off by default: you must opt in. The markers are removed again when the cluster is uninstalled.

This option applies only to onboarded clusters that do not have Configuration Management enabled. With Configuration Management enabled, IDSTower owns the file and registers the rule files as part of the configuration it deploys.

Enabling Configuration Management later¶

Configuration Management can be enabled on an already-onboarded cluster from the edit dialog of the Enabled Capabilities panel. Under Configuration Profiles, pick a profile for each installed software that does not have one yet. After the take-over, the configuration on the hosts is the one generated from that profile, so check first that it carries the settings your existing installation runs with.

Warning

Enabling Configuration Management replaces the existing Suricata setup on every host in the cluster. On each host, IDSTower:

archives the existing configuration, if the backup option below is ticked;
stops and disables the existing Suricata services;
deletes their configuration files and systemd unit files;
deploys its own configuration from the chosen profile and registers its own service units.

Backup existing Suricata configuration before taking over is ticked by default. The archive holds the configuration directory, rules directory and unit file of each Suricata instance, and is written on the host as /var/lib/idstower/backups/suricata-pre-onboard-<timestamp>.tar.gz. The take-over also deletes two things the archive can miss: /etc/init.d/suricata on Debian and Ubuntu, and the files directly under /etc/suricata/ (suricata.yaml, classification.config, reference.config, threshold.config, rules/) when no instance’s configuration file is in that directory itself. Copy them yourself first. It never leaves the host, so keep an off-host copy of your own as well. Untick the option only if the backup step keeps failing and you already have that copy.

The change runs only after you tick I understand that existing Suricata services will be stopped and configuration will be overwritten.

If the change fails, only the setting is rolled back. Configuration Management shows as disabled again, but on the hosts the take-over already reached, the services stay stopped and the files stay deleted. Fix the reported error and enable Configuration Management again; each attempt writes a new archive, so the oldest one holds the configuration from before the first attempt. To go back instead, restore the host from that archive by hand (list its contents first with tar -tzf): IDSTower has no restore action. Turning Configuration Management off does not undo a take-over either; it only stops IDSTower managing the configuration.