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 |
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, 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) |
|
How long Suricata log files are kept before deletion. |
Disk utilization threshold |
|
Disk usage percentage above which logs are deleted regardless of the retention period. |
Run frequency (minutes) |
|
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. Because IDSTower is taking ownership of a file it did not write, this runs as a guided take-over: you associate a configuration profile with the detected instances, and IDSTower deploys from that profile from then on.
Note
Take the usual care here — after the take-over, the deployed configuration is the one generated from the cluster’s configuration profile. Review that the profile reflects the settings your existing installation was running with before deploying it. The pre-onboarding backup taken when the cluster was created is still on the host.