IDSTower v3.1.0 — Onboard existing Suricata installations

Community Announcements
1

This release changes something that made IDSTower a non-starter for a lot of people here, so it seemed worth posting.

The old problem. Until now IDSTower could only manage Suricata installations it had performed itself. If you already had Suricata running — tuned, in production, configured the way you want — the answer was “reinstall it our way”. That’s a bad answer, and it was the single most common thing users told us.

What changed. When you create a cluster you now pick Fresh (installs and manages Suricata, as before) or Existing. For Existing, IDSTower connects over SSH and detects what’s already on the host:

  • systemd service units, including multiple instances per host
  • suricata.yaml location and the rules/log directories it actually references
  • which interfaces each instance monitors
  • binary path (asked from the host, not guessed from the distro) and version

It takes a backup of the existing configuration before changing anything.

The part worth knowing if you’re sceptical. Adoption is not all-or-nothing, and it isn’t a one-time decision either. An onboarded cluster has six capabilities — Health Monitoring, Rules Management, Log Management, Service Control, Package Management and Configuration Management — and you enable or disable each one independently, at any point, from the cluster’s page.

So you can start with monitoring only: IDSTower reads state and reports, and doesn’t write anything to your hosts. Add Rules Management when you’re ready to let it push rules. Leave packages and service control to your own tooling indefinitely if that’s how you work. Turn something off again if you don’t like it.

Configuration Management is the one that takes ownership of suricata.yaml, and it’s the one most people will want to leave until last — enabling it on an already-onboarded cluster runs a guided take-over rather than overwriting what’s there.

Other bits relevant to this crowd:

  • Suricata 8 support; multiple instances per host with isolated configs
  • Full threshold keyword support in the rule editor, including backoff/multiplier and the newer tracking modes
  • Rule and IOC updates now fall back to a service restart when a zero-downtime reload isn’t possible because the unix-command socket is unavailable. Previously the new rules were written to disk but not loaded until the next restart — this bites distro-packaged installs whose unit can’t recreate /run/suricata after a reboot. If the socket exists but the reload itself fails (bad ruleset), it does not restart, and the running ruleset stays up.
  • A guard that refuses to deploy over a host where Suricata is already installed, so a mistyped hostname can’t replace a working sensor

IDSTower is commercial, with a free tier that covers a single host — enough to point it at one sensor and see what it does.

Links:

One thing we’d genuinely like to hear: if you have a Suricata setup you would not hand to something like this, what specifically stops you? The capability model exists because that question got asked once already — the answer was “I’ll let it watch, I won’t let it write” — and we suspect there are constraints we still haven’t modelled.