3.2.0 Detailed Changelog

Every change in IDSTower 3.2.0. The Changelog summarises this release in a few minutes of reading; this page is the full list, for when you want to know exactly what changed.

3.2.0 - (1-11-2026)

Changes:

• New Feature: Set when indicators expire after they are created, or make them never expire. On the Indicators Management page, Indicators Actions -> Set Expiry… sets the expiry of the selected indicators or of every search result, and the pencil next to Expires At on an Enabled or Review indicator’s page sets it for that indicator. Choose a number of weeks from now, Never Expire, or the end of a specific day. Only Enabled and Review indicators change; Disabled, Whitelisted and Expired ones are skipped, and the result says how many. A Review indicator’s page now shows its expiry date too. See Setting an Expiry Date.

• New Feature: IDSTower now warns you before your license expires. From 90 days out, the footer of every page and Settings → License count down to the day (“Your IDSTower license expires in 45 days (12 October 2026)”) and link to the renewal instructions; until now the first sign was IDSTower stopping on the day the key expired. Every tier gets the notice, including the free Standard key, which also expires after 12 months and is renewed free of charge, and it disappears as soon as a valid key is entered. On a 30-day trial key it starts 7 days before the trial ends, reads “Your IDSTower Professional trial ends in 5 days” (or Enterprise), and links to the pricing page.

• New Feature: Change the priority, target or threshold of many rules at once from the Rules Actions menu: Change Selected Rules Priority, Change Selected Rules Target and Change Selected Rules Threshold. Each offers Reset To Default, which removes the override so the selected rules follow their rule text again. Reset To Default in Change Selected Rules Action now works the same way; it used to copy the rule text’s current action into the rule, so a later change of the action by the vendor never reached your sensors.

• New Feature: Added support for Ubuntu 26.04 LTS (Resolute Raccoon), both as the operating system of the IDSTower server and as a managed Suricata host. The installation script treats 26.04 as fully supported instead of warning that it is untested, and Suricata 7 and 8 are deployed to Ubuntu 26.04 hosts from the official OISF repository for that release.

• New Feature: Kali Linux (rolling) is now supported, as the operating system of the IDSTower server and as a managed host, both for a Fresh deployment and for onboarding an Existing Suricata installation, as on Debian and Ubuntu. Until now a Kali deployment failed, and the installation script refused Kali. Suricata comes from Kali’s own repository, so the “official repository” option offers the major version Kali ships (Suricata 8 as of Kali 2026.3); Filebeat 7, 8 and 9 come from Elastic’s repository, and Ansible and MariaDB from Kali’s. On a Kali system that is not fully up to date, the installation script first upgrades the C library (libc6) and waits for systemd to restart, so that this upgrade cannot break the MariaDB installation. Every Kali release is supported. The steps are in Installation on Kali Linux (Rolling).

• New Feature: Added support for Raspberry Pi OS (64-bit), as the operating system of the IDSTower server and as a managed Suricata host, including both on one Pi (see Installation on Raspberry Pi OS (64-bit)). It is handled like Debian 13 (Trixie), which it is built on, with the arm64 packages of IDSTower, Suricata and Filebeat. The 32-bit image, which identifies itself as raspbian, is not supported: use the 64-bit image. The Built-In (offline) packages repository has no aarch64 packages yet, so an offline Arm deployment needs the User-Custom repository with your own arm64 packages. Validation on real Arm hardware, Raspberry Pi included, is still pending: installing IDSTower is tested on emulated 64-bit Arm containers, but deploying Suricata and Filebeat to an Arm host has not been validated end to end, because those containers cannot run Suricata’s traffic capture. We would be glad to hear how it goes on your device.

• New Feature: The documentation now carries a third-party components list: every open-source component IDSTower ships, with its version, license and source, for the backend, the web interface and the Ansible automation. It is generated from each release’s build, for security, procurement and vendor reviews.

• Improved: The rule editor now tells the rule text’s values apart from yours. Its action, priority, target and threshold each show the value IDSTower applies: one you changed is marked Overridden, with the rule text’s value and a Use the rule text’s value button (Remove the override when the rule text has none); the others read From the rule text. Your sensors and exports get your overrides and, for everything else, the rule text’s values, so a vendor’s update reaches every value you did not change (the Target Keyword heuristics still add a target where the text has none). Choosing the rule text’s own value removes the override. The new Overridden filter on the Rules Management page lists the rules that have an override. In export filters, Overriding Rule Action is now Rule Action (Applied), the action your sensors get, and Original Rule Action is now Rule Action (Rule Text), the action the rule text says; the new Rule Action Override matches your override alone, with is set and is not set; the priority has the same three fields, and Rule Priority (Rule Text) now takes the range operators. Saved export filters keep selecting the same rules, with two exceptions the export page describes (Adding IDS Rules Export). On upgrade, the values an earlier version stored differently from the rule text become your overrides, so your sensors get the same rules, except an action you last reset with Reset To Default, which now follows the rule text; each rule’s history (Professional and Enterprise) shows what the upgrade did, by System: Upgrade to v3.2.0. Some kept values were never set by anyone (left over from an older revision of the rule, or from a vendor editing it in place): review them with the Overridden filter; Reset To Default returns the selected rules to their rule text. Exports of the rules whose priority, target or threshold IDSTower used to rewrite change once in spelling, not in values, and in STIX exports those rules get new object ids.

• Improved: Exports to AWS Network Firewall now include the rules with a reject action instead of leaving them out. A reject rule with the tcp protocol is exported as it is; every other reject rule (for now including TCP application protocols such as http or tls) and every rejectsrc, rejectdst and rejectboth rule is exported as drop and listed as a warning in the AWS export’s run dialog. A reject action you set on a rule, which the AWS export used to ignore, now applies there too. After upgrading, the first AWS export therefore makes AWS Network Firewall block traffic it did not block before, and the added rules count toward the rule group’s capacity (an export at capacity leaves out the rules with the highest SIDs). AWS exports run every 15 minutes, so review your rules with a reject action or a reject override before you upgrade.

• Improved: The rules and indicators updates every managed host pulls from IDSTower (suricata_rules_update.sh and suricata_indicators_update.sh, once per Suricata instance on every scheduled run, and on every host at once after a feed update) are much faster and use far less memory on the IDSTower server. We measured the 3.1.1 and 3.2.0 Docker images one at a time, against the same MariaDB 10.11 server set up like a production one, with a real deployment’s data (51,764 ET Open rules and 9,686 indicators), taking the median of three rounds. The rules file a Suricata instance pulls took 13 s on every pull with 3.1.1, which rebuilt it for every pull on installations without Custom deployment-mode rules (see the bug fix below). 3.2.0 builds it in 4.6 s (measured on the first pull after the service starts), and every later pull takes 0.12 s while the rules stay unchanged, about 110x faster. The server’s memory peak during that first pull fell from 1.0 GB to 0.3 GB. Four instances pulling at the same time, which both versions answer by building the file, used to take 17.5 s and peak at 3.4 GB of memory; they now take 3.3 s and peak at 0.3 GB. With IDSTower limited to 1.5 GB of memory, 3.1.1 failed three of those four pulls, while 3.2.0 answered all four in 4.5 s (one round). The gain grows with the number of hosts pulling at the same time. The indicator files are unchanged byte for byte; the rules file changes once, in the spelling of some priority, target and threshold values (see the rule editor entry above), not in what the rules do.

• Improved: The indicator files every managed host pulls (IP-reputation categories, indicators and rules; FQDN and SHA256 dataset lists) are now kept on disk like the rules file and exports, rebuilt only after an indicator changes, and shared by the requests that arrive during a rebuild. Measured as in the entry above, with 50,000 more indicators (10 attributes each, 59,686 in all), the first pull after the service starts, which builds each file, went from 42.4 s to 0.13 s for the IP-reputation indicators, from 15.8 s to 0.11 s for the SHA256 dataset and from 5.1 s to 0.12 s for the FQDN dataset. Building the two dataset files now adds 8 MB and 1 MB to the server’s memory instead of 143 MB and 67 MB. An unchanged file is served in 10–25 ms instead of 25–105 ms, and a rebuild’s memory stays flat as the number of indicators grows. AdvancedSettings.RulesFetchChunkRows and AdvancedSettings.IndicatorsFetchChunkRows set how many rules and indicators are read from the database at a time, which bounds the memory a rebuild uses. The files are byte-for-byte unchanged.

• Improved: Exports and the per-host rules files are now generated and served with a bounded amount of memory, however large the ruleset and however many exports or Suricata instances there are. This was the biggest cause of IDSTower running out of memory on small instances. Generated files are now kept in /var/cache/idstower (AdvancedSettings.GeneratedFileCachePath sets another directory), which is emptied when the service starts. Measured as in the rules and indicators entry above, generating a rules export of 51,764 rules adds 97 MB to the server’s memory instead of 322 MB, and once every rules file, indicator file and export had been served, IDSTower held about 0.5 GB instead of 1.5–1.7 GB; an idle IDSTower uses about 190 MB in both versions. Simultaneous downloads of the same export now share one generated file instead of each multiplying the memory cost.

• Improved: Managed hosts now get freshly compiled rules as soon as compilation finishes. A host that asked while IDSTower was still compiling, as every host does right after a feed update, used to skip that run and keep its old rules until the next one. The request now waits up to AdvancedSettings.GeneratedPayloadWaitSeconds (default 30 s); if compilation is still running, IDSTower answers 202 Accepted with a Retry-After header (AdvancedSettings.GeneratedPayloadRetryAfterSeconds, default 30 s) and the old “compilation is still under process” text, and the updated suricata_rules_update.sh retries up to 3 times within the same run; update scripts deployed by an earlier version keep working. A reverse proxy in front of IDSTower needs a read timeout above GeneratedPayloadWaitSeconds (30 seconds by default), or it times out first and the hosts log a failed rules update. How long generated files may be reused is now set with AdvancedSettings.GeneratedPayloadCacheLifetimeMinutes (default 360).

• Improved: A threshold you set in the rule editor or the bulk change is now checked the way Suricata loads it: the threshold, limit and both types need seconds, and backoff needs track by_flow, a count from 1 to 65535 and a multiplier from 2 to 65535, and takes no seconds. Until now a threshold Suricata refuses could be saved, and the rule then failed to load on your sensors. backoff and track by_flow need Suricata 8; Suricata 7 does not load them. A threshold set before 3.2.0 that Suricata 8 refuses, such as a backoff with a track other than by_flow or without a multiplier (which 3.1.x documented as optional), never loaded on your sensors: the upgrade removes it where the rule text has its own threshold, so the rule now loads with that one, and records this in the rule’s history; where the rule text has none, it is kept for you to correct.

• Improved: The Docker image now includes the operating system’s security updates available when the release was built. The 3.1.1 image carried 8 pending Ubuntu security updates, among them openssl, libssl3t64, the PAM libraries and perl-base. The updates are applied when the image is built, never when a container starts, so starting a container stays reproducible and needs no network access.

• Improved: A feed update no longer shortens an indicator’s expiry. When a feed lists an indicator again, its expiry date moves later but never earlier, so an indicator you set to Never Expire, or to a later date, keeps that expiry, and lowering a feed’s Expire Indicators After no longer shortens the expiry of the indicators it has already imported.

• Improved: Setting up a cluster, adding hosts to it and resetting its SSH trust are much faster. Since 3.1.0 these operations logged in to the host again for every command, over 1,200 SSH logins to set up a one-host cluster; they now log in to each host about once per step (validating, deploying). Each step still logs in with its own credentials, so a wrong password is refused even right after the right one was accepted, whatever an ansible.cfg or group_vars on the IDSTower server say about SSH connection sharing. In our tests on an Ubuntu 24.04 host, deploying the cluster took 121 s instead of 252 s, validating the host 75 s instead of 129 s, and adding two hosts to a cluster finished more than four minutes sooner; hosts further from IDSTower gain more. If IDSTower cannot create a private folder for these connections in its temporary directory, it logs a warning and logs in for every command, as before.

• Improved: Exports are much faster and use far less memory, most of all with a large ruleset or indicator set and on small instances. Measured as in the rules and indicators entry above, generating an IDS rules export of 51,764 ET Open rules went from 13.7 s to 2.4 s (5.8x), and generating an IOC export of 59,681 indicators from 1.7–2.4 s to 0.13–0.33 s (6–13x, depending on the format). Downloading an export again while its content is unchanged is about as fast as before (within a few milliseconds). The gain grows with the size of the export, and threat-intelligence feeds such as MISP commonly attach around 70 attributes to each indicator. IOC exports carry the same content as before. Rules exports change once, in the spelling of some rule values, as the rule editor entry above describes.

• Improved: Configuration and environment problems that stop IDSTower from starting are now reported as a single actionable line instead of a stack trace. Each message names the setting or path at fault and its current value, the system error, what the failure prevents, and the command or setting change that fixes it: a cache directory the service user cannot write to, for example, now prints the chown command to run and the setting that points elsewhere. Genuine internal errors keep their full stack trace.

• Improved: A managed host that refuses IDSTower’s SSH connection now says which credential it refused and what to do. Such a host used to fail at the Gathering Facts step with “Failed to connect to the host via ssh: idstower@sensor01: Permission denied (publickey,password).”, which looked the same as a firewall rule, a renamed SSH user or a host that was down. On a host already in a cluster, the message now says the host rejected the cluster’s SSH key, for which login, and why this usually happens (the host was reimaged, or its container was recreated rather than restarted, which discards the key IDSTower installed in authorized_keys), and gives the remedy: Cluster Actions → Reset SSH Trust, then Update Hosts Config. With credentials you have just entered (adding a cluster or hosts, or resetting SSH trust), it points at the SSH User Account and SSH Authentication fields instead. Ansible’s message is still shown underneath.

• Improved: Reaching a license limit is now explained before you fill anything in. Adding a host beyond what your license covers used to fail with “You will exceed the license limit of allowed number of IDS Hosts of 1” only after you had entered the host and its SSH credentials, and creating a cluster only after the whole Cluster Setup Wizard had been filled in. Both now check the limit when they open and say, in place of the wizard, what the license covers and how to go further; for a new cluster, whether the cluster limit, the Suricata instance limit or both are in the way. A Standard license is pointed at the free 30-day Professional trial, and told it can go back to Standard afterwards; a trial at buying a full license; and a paid license at adding instances to it. The limits themselves are unchanged.

• Improved: The notices for features your license does not include now say what the feature does and offer its free 30-day trial, which is issued instantly, instead of only asking you to purchase: Role-Based Access Control (Settings → Users: custom roles, and any role other than Admin), API Keys, the AWS Connector, rule change history, and more than one Suricata instance per host. The Add Role dialog, which you could fill in on any license only to be refused on submitting it, now shows the explanation in place of the form, and the Roles field of the Add User dialog says why only Admin is offered. The API Keys and AWS Connector dialogs now say up front what the license allows; neither is blocked any harder than before, so an API key can still be created on any license and, as before, answers 403 to every call when the license does not include the feature. An Enterprise license that covers no AWS regions is pointed at support instead of the trial. The rule history notice no longer appears briefly on every license while the page loads, and every license message names the same place to enter a new key: Settings → License.

• Improved: Setting up a cluster, or resetting its SSH trust, now says plainly when the cause is on the IDSTower server. A missing ssh-keygen, a documented prerequisite, used to be reported as an “Unexpected error encountered while preparing new cluster setup, details: …”; the message now stands alone and names the package to install: openssh-client on Debian/Ubuntu, openssh-clients on RHEL/CentOS and relatives. When the configured EncryptionKey no longer matches the one the stored cluster credentials were encrypted with (after the key was rotated, or a restore from a backup taken with a different key), IDSTower said only “Decryption failed - data may be corrupted or key may be wrong”; it now says that none of the stored SSH credentials can be used until the original key is put back.

• Improved: Adding a rules category is easier to find. The rule editor, for an existing rule or a new one, has a New Category button (Create First Category when there are none yet) next to its Category list that creates the category and selects it for the rule, and the Category filter of the rules list now offers New Category at the top instead of the bottom.

• Improved: The installation script now checks the CPU architecture before installing anything, and stops on one IDSTower is not published for, such as a 32-bit armhf or i386 system. It used to install the database, Ansible and the rest first, and only then fail at the IDSTower package.

• BugFix: Fixed a security gap that let every signed-in user change the Indicators Alerting settings, whatever their role. These settings decide whether IDSTower alerts on malicious IPs, domains and files at all, and whether expired indicators are deleted. Changing them now needs the Update Indicators Alerting Settings permission, which the built-in Admin and Detection Engineer roles have and the Analyst and Auditor roles do not. Custom roles that should change these settings need that permission added.

• BugFix: Fixed a security gap that let another user with an account on the IDSTower server read the SSH private key IDSTower uses for a cluster operation. During an operation, IDSTower keeps the cluster’s private key, or the key you uploaded for a new host, in a file in the server’s temporary directory (/tmp), and that file was readable by every user for a moment after it was created, long enough to open it and read the key once it was written. The file is now private to the idstower user from the moment it exists, and IDSTower refuses to write the key to a path that already exists, such as a link someone placed there. Only servers with other local accounts, of people or of software, were exposed.

• BugFix: Fixed a crash or forced restart of IDSTower during a cluster operation (killed for lack of memory, stopped with kill -9) leaving the cluster’s SSH private key, or the key you uploaded for a new host, in the server’s temporary directory (/tmp) until the next reboot or the operating system’s clean-up of old temporary files. IDSTower now overwrites and removes such leftover key files when it starts and every hour while it runs, once they are older than the longest an operation can run: the larger of the Install / Upgrade / Configure Timeout and Start / Stop / Validate Timeout in Settings → Advanced, plus an hour. It removes only the key files it creates, never one an operation in progress uses. With the default timeouts, a leftover key is removed when IDSTower starts or, if IDSTower started again right after the crash, within about two and a half hours.

• BugFix: Fixed managed Suricata hosts reloading their rules on every scheduled rules update, every 5 minutes by default, even when nothing had changed; with a large ruleset a reload takes minutes, so Suricata spent most of its time reloading. A host now reloads only when its rules or indicators have changed. Where the Suricata configuration does not name its unix-command socket (Suricata’s own default suricata.yaml leaves unix-command.filename commented out, and many existing installations added to IDSTower keep it that way), each of those reloads was a full restart, so inspection stopped every 5 minutes and /var/log/idstower/rules_updates.log showed “No usable unix-command socket for instance … (status=, checked: ); falling back to a service restart”; these hosts now reload live through Suricata’s default socket. Also, a restart postponed because an IDSTower operation was running on the host is now made by the next update run, and a failed restart to load new IP-reputation categories is followed by a reload; before, both left new rules or indicators unloaded until the next change. The reload on every run and the skipped reload after a failed restart affected IDSTower 3.0.0 to 3.1.1; the restarts in place of reloads and the postponed updates affected 3.1.0 and 3.1.1.

• BugFix: Fixed managed Suricata hosts, AWS Network Firewall rule groups and exports getting out-of-date rules or IOCs for up to 6 hours after the following changes: deleting an IDS rule, on a Suricata instance whose deployment templates give it only part of the rules; deleting a rule category with Inject Category on; moving a host to another configuration group, or deleting its group; editing an AWS connector’s rule variables; and changing a rule or IOC while a host’s file was being generated or while a rules import or feed update was still saving. Exports also kept serving deleted IDS rules and IOCs (including the expired IOCs the daily clean-up removes), the old transformation after the default transformation settings (Settings -> Rules) changed, and the previous license’s item limit, so an export stayed at the Standard license’s 10 items after a Professional license was activated. Each of these changes now takes effect at the next request, so appending &disableCache=true to an export URL is no longer needed after them. Deleting a category now also records a Category change in the history of each rule revision it is removed from.

• BugFix: Fixed applying configuration (Update Config, Refresh stale config, saving the cluster’s settings, changing its capabilities) starting or stopping every Suricata instance of a config group to match whichever instance came first, starting instances you had stopped or stopping Suricata on every host of the group. Each instance now keeps its own state: instances recorded as running are restarted on the new configuration, those recorded as stopped are stopped, and Filebeat is restarted on every host whose configuration was applied (on an onboarded cluster without the Service Control capability the services are left as they are). A newly added instance is recorded as stopped on a Fresh cluster, so it stays stopped until you start it, and as running on an onboarded cluster. After upgrading, the first configuration update stops any instance that is running but recorded as stopped, typically instances added to a Fresh cluster on 3.1.x, so check your instances’ states after that update and start the ones that should run. When a host’s configuration was applied but a service could not then be started or stopped, the operation now completes with a warning naming the host and the reason, the host no longer needs a configuration update, and a cluster Settings or capability change is kept rather than rolled back.

• BugFix: Fixed renaming a Suricata instance destroying what that instance had accumulated on its host. The next configuration update treated the old name as a deleted instance: it deleted the instance’s log directory, with every alert, network transaction and stats record it had written, together with its downloaded rules, IP-reputation files and datasets, silently and beyond recovery. Renaming now moves /etc/suricata/instance-[Name]/ and /var/log/suricata/instance-[Name]/ to the new name with their contents, while deleting an instance still removes them. To tell the two apart, IDSTower writes a .idstower-instance-id file into each instance’s directories: when a cluster or host is deployed, and on hosts deployed by an earlier version at their first configuration update. Upgrading to 3.2.0 marks every host as needing that update, so run it before renaming anything; until a host has had it, IDSTower keeps the log directory of an instance it cannot identify and reports its path for you to remove by hand.

• BugFix: Fixed a status you set on an indicator undoing itself. Enabling, disabling, reviewing or whitelisting an indicator on the Indicators Management page set its expiry date to 01/01/0001, so it was marked Expired again within the hour and, with Delete Expired Indicators on (the default), deleted by the nightly cleanup. Disabled and whitelisted indicators, including ones set by a file import or through the REST API, also expired at their expiry date. Either way, a false positive you had disabled or whitelisted came back as Enabled on the next import from a feed. Disabled and Whitelisted indicators now never expire by themselves: they keep their expiry date but do not expire, and enabling or reviewing an Expired, Disabled or Whitelisted indicator keeps its expiry date, or gives it 42 days if fewer than 42 are left. Before upgrading, list your Expired indicators: the first update of each feed after the upgrade re-enables the ones a feed still lists. After upgrading, set the status again of any indicator you had disabled, put in review or whitelisted that is back as Enabled.

• BugFix: Fixed a large indicator import (a threat-intelligence feed, a file upload or an API call bringing in more than 10,000 indicators) losing every remaining indicator when one batch of 10,000 failed to save, while the import still reported success and the feed was not imported again until its content changed. A batch can fail when an indicator stored earlier differs from the incoming one only in letter case, or on a database deadlock. Now only that batch is lost, and the rest of the import is stored.

• BugFix: Fixed a vendor’s edit of a rule not reaching the rule’s action, priority, target, threshold, message and classtype when the vendor kept the rule’s revision number, which vendors often do. The rule page showed the old values, and the Rules Transformation options (on by default) could write them over the vendor’s text on your sensors and in exports. These values, and the tags IDSTower reads from the rule text, now follow the text on every feed update. This also stops the IDSTower log filling with “Skipping target keyword insertion” warnings.

• BugFix: Fixed upgrading Filebeat or Suricata leaving its service in the wrong state. After a Filebeat upgrade, Filebeat was left stopped on every host, so log shipping stopped until it was started by hand; after a Suricata upgrade that reported success, the instances kept running the previous version until their next restart. Upgrading now puts the services back into their configured state: instances configured as running are started, or restarted on the new version; instances you had stopped stay stopped; and Filebeat follows the state of the host’s Suricata instances. A service that fails to come back up is now reported. On an onboarded cluster without the Service Control capability, an upgrade no longer stops the service, which IDSTower could not start again there.

• BugFix: Fixed starting, stopping and restarting services failing, or silently missing an instance, after a Suricata instance was renamed, added or deleted and before the host’s configuration was applied: the action named a service the host did not have yet (for example conf-yaml-loader: failed to open file: /etc/suricata/instance-<new name>/suricata.yaml), or a stop reported success while a deleted instance kept running. IDSTower now refuses to start, stop or restart anything on a host whose configuration changes are not applied yet: apply them with Refresh stale config in the hosts tab, or Update Config on the cluster page, which also restarts the running services on the new configuration. An action on several hosts still runs on the hosts that are up to date and names the ones it skips. A Suricata or Filebeat version upgrade is refused while any host it covers has changes not applied yet, so the cluster is not left on mixed versions. After upgrading to 3.2.0, every host needs its configuration updated before its services can be started, stopped or restarted from IDSTower.

• BugFix: Fixed actions chosen from the hosts tab’s Actions menu for all hosts, or for the selected hosts, running on a single host instead, including Remove From Cluster, which could remove a host you had not selected. The menu reused the host or instance last picked in that tab (by opening its instance editor or config group dialog, a service fix link, or an instance’s delete button), so start, stop, restart, Change Config Group, Remove From Cluster and Change Monitored Interfaces named that one host or instance and acted on it alone. They now always act on the hosts they name.

• BugFix: Fixed changing or upgrading a cluster’s Suricata configuration profile discarding your edits to custom-config.yaml, in the Default Config Group and in custom Config Groups. Your edits to it are now kept across the change, while an untouched one takes the new profile’s version, as the other template files, such as suricata.yaml and threshold.config, still do. If you changed or upgraded a profile before, for example when moving to 3.1.0, your earlier custom-config.yaml is still in the Config Group’s configuration history, so you can copy your settings back from there.

• BugFix: Fixed Change Selected Rules Category taking every selected rule out of its category when the dialog was confirmed without choosing one. The dialog opened on – Select Category –, which meant “no category”, with its Change button already enabled, so one click stripped the category from every selected rule, or from every rule in the search result, and nothing on screen said so. The dialog now asks whether to move the rules to a category or remove them from their category; the button names the action (Move to Category or Remove Category), and moving stays disabled until a category is chosen. Removing the category no longer adds an entry to the change history of selected rules that had none.

• BugFix: Fixed installing or upgrading Filebeat leaving a host unable to install or update any package. On Ubuntu, and on other apt-based distributions IDSTower does not name specifically, editing the Elastic repository line IDSTower adds (for example to add allow-weak=yes) made the next Filebeat install or upgrade append a second, unedited copy; a second definition of the same repository in another file did the same, on Debian hosts too. apt then refused to read any package source (Conflicting values set for option ... regarding source), breaking every later package operation, Suricata’s included. IDSTower now keeps the Elastic repository in a single deb822 file, /etc/apt/sources.list.d/idstower-elastic-<major>.sources, which replaces the entry earlier versions wrote (a .list file on Ubuntu, a block in /etc/apt/sources.list on Debian) with no manual action needed. Any other file in /etc/apt/sources.list.d that defines the Elastic repository for the Filebeat major version IDSTower installs, hand-made ones included, is deleted whole, other repositories in it included: move those out before you upgrade Filebeat. Files for other Elastic major versions are left alone. Hosts also get the python3-debian package, which a host restricted to a local mirror needs available there. The next Filebeat install or upgrade repairs an affected host; until then, deploying a cluster or upgrading Suricata and Filebeat together still fails on it.

• BugFix: Fixed adding, onboarding, deploying to and upgrading Debian 11 (Bullseye) hosts failing with 404 Not Found since Debian 11’s long-term support ended on August 31, 2026. Debian’s mirrors (deb.debian.org, security.debian.org and the mirrors of Debian’s AWS and Azure images) still list the bullseye-security packages but no longer serve many of them, among them curl, rsync, gnupg2 and Suricata’s own dependencies. When a Debian 11 host takes bullseye-security from one of those mirrors and can reach archive.debian.org (checked through apt’s own proxy settings), IDSTower now adds the same suite from archive.debian.org in its own file, /etc/apt/sources.list.d/00-idstower-debian-archive-security.sources, when it validates the host and whenever it applies the host’s configuration. It never edits the host’s own package sources, and removes its file once the host defines the suite itself, can no longer reach archive.debian.org, or no longer runs Debian 11; the file stays on the host when IDSTower is uninstalled. On a Debian 11 host your cluster already has, the file comes with the configuration update every host needs after upgrading to 3.2.0 (step 11 of the upgrade guide), so add a log shipper to such a host only after that update has run. Debian 11 no longer receives security updates, so plan to upgrade these hosts.

• BugFix: Fixed every Suricata deployment, validation or upgrade failing on Debian hosts that already define the Debian backports repository IDSTower uses with an explicit option, typically check-valid-until=no or trusted=yes on Debian 11’s archived backports: IDSTower’s own entry for the same repository made apt refuse to read any package source (Conflicting values set for option ... regarding source), so the host could not install or update any package. IDSTower now uses the host’s existing backports definition and adds its own, in /etc/apt/sources.list.d/00-idstower-debian-backports.sources, only when there is none; the block earlier versions wrote in /etc/apt/sources.list is removed on the next Suricata deployment, validation or upgrade. The next Suricata upgrade on an affected host, or its validation when it is added to a cluster, repairs it; a cluster deployment or a Filebeat-only install or upgrade does not, because other package steps run first. On Ubuntu hosts, the clean-up of duplicate OISF Suricata repository definitions no longer deletes a sources file that only mentions the OISF PPA in a comment.

• BugFix: Fixed re-running the installation script on a host that already has IDSTower installed (after a first attempt failed partway, or to repair an installation) locking that installation out of its own database. Each run generated new credentials and changed the database password at once, but rewrote appsettings.json only a dozen steps later, so a run that stopped in between ended at Access denied for user 'idstower'@'localhost'; a new encryption key left the stored SSH credentials of every managed cluster undecryptable, with no way back. The script now reuses the encryption key, database user and password the installed IDSTower runs with, and stops and explains the choice when the credentials file an earlier run left behind, wherever it is, contradicts them. A database server that is not running and an administrator login the script has not been given are now reported with what to do about each, instead of a bare Error in script - exited with status 1.

• BugFix: Fixed the Change $EXTERNAL_NET to Any rules transformation turning rules that exclude $EXTERNAL_NET into rules Suricata refuses to load. With the option on, !$EXTERNAL_NET was deployed as !any and a negated list such as ![$EXTERNAL_NET, 192.0.2.0/24] as ![any, 192.0.2.0/24], which Suricata rejects with “Complete IP space negated”, so those rules never ran on your sensors; a variable whose name merely starts with EXTERNAL_NET, such as $EXTERNAL_NET_DMZ, became the invalid address any_DMZ. The option now replaces $EXTERNAL_NET only in a rule’s source and destination addresses and only where it is not negated, and leaves negated uses and longer variable names exactly as written.

• BugFix: Fixed rule imports, rule feeds and the rule editor refusing rules whose address list has spaces after its commas, such as alert tcp [10.0.0.1, 10.0.0.2] any -> $HOME_NET 445 (…), with “IDS Rule has invalid or missing Source Port.” Suricata loads these rules, but feeds and uploaded rule files silently lost them, and adding or editing one by hand failed. Address lists with spaces, including negated or nested ones such as ![10.0.0.1, 10.0.0.2], are now accepted. When such a rule is exported to AWS Network Firewall, the spaces are removed from its address lists, as they already were from its port lists, because AWS Network Firewall does not accept them.

• BugFix: Fixed IDSTower exiting with a success code when it failed: a start aborted by an unusable directory, a contradictory setting or an unreadable database version; a start that could not reach or initialise the database; a server that could not bind its configured address; a mistyped option; and the command-line options --init-database, --add-user, --change-password, --delete-user, --list-users and --check-license, which printed [IDSTower][Error] ... and still reported success. So Restart=on-failure never fired after a failed start, container orchestrators saw a healthy exit, and scripts using idstower --init-database || exit 1 walked straight past a failure. Every failure now exits with code 1; successful runs, --help, --version and declining a confirmation prompt still exit 0. The Docker image also exited with success for every missing required environment variable (EncryptionKey, Hosting__URL, the certificate settings and all four Database__*), so docker ps -a showed Exited (0) and restart: on-failure never fired; those now exit 1 as well.

• BugFix: Fixed a dollar sign inside a user-added rule attribute value, a rule URL or a rule category name corrupting the generated rule when the rule had no metadata keyword of its own: $$ became a single $ and $& was replaced by the text around it, which left a rule Suricata could not load. The value is now written into the metadata keyword exactly as entered.

• BugFix: Fixed indicator dates from threat-intelligence feeds being shifted by the IDSTower server’s time-zone offset on a server not set to UTC: the First Seen and Last Seen of indicators from the abuse.ch ThreatFox feed, and the MISP Timestamp, MISP First Seen and MISP Last Seen of indicators from MISP feeds and MISP API feeds. At UTC+4, for example, ThreatFox times were 4 hours early and MISP times 4 hours late. Indicators imported from now on carry the right times, which the Indicators page shows in your browser’s time zone. Dates already stored are corrected only when a feed delivers the indicator again and it is not disabled or whitelisted: ThreatFox and MISP feeds do so on their next update that brings new content, but a MISP API feed only re-delivers attributes edited in MISP since its last update, so most indicators it imported before keep their shifted dates.

• BugFix: Fixed domains under an internationalised top-level domain being dropped. A domain in the xn-- form that DNS and threat-intelligence feeds use, such as xn--b1adbn5abjhj1h.xn--p1ai (.рф) or shop.example.xn--fiqs8s (.中国), was not recognised as a domain: feeds and file imports skipped it, adding it on the Indicators page listed it among the skipped indicators, and the Public API refused it. Such domains are now imported and added like any other domain, and reach your sensors. A domain written in Unicode, such as пример.рф, is still not recognised; add it in its xn-- form.

• BugFix: Fixed the scheduled rules and indicators updates on a managed host silently doing nothing when curl is not installed on it, for example after the host was reimaged, or a container host was rebuilt from an image without it. The host stayed on its old rules and indicators indefinitely. The update scripts now stop with an error naming the missing curl in /var/log/idstower/rules_updates.log and /var/log/idstower/indicators_updates.log.

• BugFix: Fixed the scheduled rules and indicators updates on a managed host stopping before they updated anything, with nothing in /var/log/idstower/rules_updates.log or indicators_updates.log to say why, when ss listed a listening socket without the process that holds it, when systemctl could not answer for a moment, or when ss itself failed. The host stayed on its old rules and indicators for as long as that lasted. The updates now go on, and find the unix-command socket of an instance the lookup could not place from its Suricata configuration. Affected IDSTower 3.1.0 and 3.1.1.

• BugFix: Fixed IDSTower generating the full rules file again for every rules pull from every host, instead of reusing the one it had already generated, on installations that use no Custom deployment-mode rules. This was needless load on the IDSTower server that grew with the size of the ruleset and the number of hosts. The rules files themselves were always correct.

• BugFix: Fixed license keys being rejected because of how they were copied. A license key is three blocks of characters separated by dots, and double-clicking it selects only one of the three; pasting that produced IDX12741: JWT must have three segments (JWS) or five segments (JWE). IDSTower now says “This looks like only part of a license key: it has 1 of the 3 sections… double-clicking selects only one of them.” Surrounding spaces, a line break an email client inserted mid-key, and the invisible characters that copying from an HTML email inserts are now removed before the key is checked and saved, everywhere a key can be supplied: the activation page, Settings → License, the --set-license-key command line option, and a key already stored by an earlier version. A key that is genuinely wrong is reported without the token library’s internal error codes.

• BugFix: Fixed IDSTower writing nothing to its log file for the rest of the day after --init-database, --add-user or --change-password was run with sudo before IDSTower had logged anything that day. The day’s log file was then owned by root, and the service, running as the idstower user, could not write to it, without any error. The commands the installer prints for you to run by hand, if creating the admin user fails, now say to run them as the service user. IDSTower also takes ownership of its log directory at every start, which repairs one left owned by the wrong user (after restoring from a backup, for example), and if it still cannot write the file, it says so at startup with the chown command that fixes it. If you hit this on an earlier version, journalctl -u idstower has everything the file is missing.

• BugFix: Fixed IDSTower requiring the sudo utility on a managed host even when it connects as root. A stock Debian installation does not include sudo when a root password is set during setup, so adding such a host failed validation with “Provided user `root` does not have sudo Rights”, and a host given sudo only for the setup broke at its next configuration update once sudo was removed. IDSTower no longer uses sudo when the SSH login has user id 0. Hosts reached through a non-root account still need passwordless sudo; for them the check now tells a missing sudo apart from a user who may not use it, and says how to fix each. Connecting as root with a password still needs PermitRootLogin yes in the host’s sshd_config, which is not the Debian/Ubuntu default; choosing SSH key authentication in the wizard avoids that change.

• BugFix: Fixed IDSTower leaving up to seven temporary files per host behind whenever a configuration operation failed partway, timed out or was interrupted. On a busy installation they accumulated until the operating system refused to create another temporary file, and from then on every configuration operation failed for no apparent reason. The files are now removed when the operation ends, whether it succeeded or not.

• BugFix: Fixed removing a host from its cluster, or deleting the cluster, leaving a Suricata instance installed and running on the host when an instance had been renamed or deleted and the host’s configuration had not been updated since: the service under the instance’s old name, or of the deleted instance, stayed behind. Removal now removes every IDSTower Suricata instance service it finds on the host. Clusters onboarded with configuration management turned off are unchanged: IDSTower does not own their services.

• BugFix: Fixed IDSTower reporting “no existing installation” on a host that runs more than one Suricata instance from a binary outside the usual locations and the login user’s PATH, such as a Suricata built from source into /opt/suricata-8.0.1/bin, while its services were stopped. On such a host the existing-installation safeguard did not appear, so nothing stopped a Fresh deployment from installing over a working sensor and its configuration. IDSTower now finds the binary in the host’s Suricata systemd units however many there are. Hosts with a single Suricata unit, packaged installations, binaries on the PATH or in the usual locations, and running instances were detected correctly before.

• BugFix: Fixed a failed configuration update reporting every host of a config group as “Failed to update host configuration.” when it failed on only one of them (because Suricata was not installed there, for example), although the others had been configured. Each host now gets its own result: the failure names the host it happened on, and the hosts that were configured are no longer reported as failed or asked to update again. Hosts the run never reached (a timed-out run, or one that could not start) are still reported as failed, and the operation still fails whenever any host failed.

• BugFix: Fixed hosts with configuration changes not applied yet being reported as needing a restart. The warning next to such a host said it “needs a restart”, and the cluster banner read Restart Required with a Restart button, although what those hosts need is a configuration update, which is what that button actually ran. Restarting the host’s services instead fails once an instance has been renamed or added. The host warning, the banner (now Config Update Required) and its button (now Update Config) now say what is needed.

• BugFix: Corrected the export limit notice, which said the limit applied “in demo”: it applies to every Standard license. It now reads “On the Standard license an export contains only the first 10 items, however many its filters match”, offers the free Professional trial, and no longer appears briefly on every license while the page loads; exports themselves are unchanged. A truncated export now also says so in the file itself, which is what a firewall or a scheduled fetch actually reads: its header gains “This export is limited to 10 items by the Standard license, so it may not contain everything matching its filters”, only when the limit was reached.

• BugFix: Fixed exports (/exports/{id}) refusing a client that sends a Content-Type header other than text/plain with its request, such as application/json, with an empty 415 Unsupported Media Type instead of serving the export. An export URL with a malformed id or disableCache value now also answers 400 Bad Request with the reason as a # comment line, like the export’s other errors, where it used to answer an empty 406 Not Acceptable.

• BugFix: Fixed IDSTower answering 500 Internal Server Error with an empty body, instead of 404 Not Found, to any request that matches no endpoint and is not a GET or HEAD, for example a POST, PUT, PATCH, DELETE or OPTIONS to a mistyped, renamed or removed API path. An API client could not tell a wrong URL from a server fault, and each such request, which vulnerability scanners send to internet-facing installations, was logged as an unhandled exception (The SPA default page middleware could not return the default page '/index.html'). A GET or HEAD under /api, /integration, /exports, /ApiDocs or /swagger that matches no endpoint now also answers 404 instead of the web interface’s HTML page. Browsing the web interface is unaffected.

• BugFix: Fixed managed hosts logging a false warning in heartbeat.log while a rules or indicators update was reloading new rules: Per-instance metrics for <instance> are unavailable: socket ... exists but 'suricatasc -c version' failed. The Suricata process may be unresponsive, although the instance kept inspecting traffic and the update succeeded. The heartbeat now reports this at Info while an update is in progress, and keeps the warning for a socket that is genuinely unresponsive. A socket that does not answer while Suricata restarts is now also reported at Info on every host: the 3.1.0 fix for that case missed hosts with ss installed, the usual case, and hosts with a configured socket path. Only the per-instance metrics of that heartbeat were affected.

• BugFix: Fixed the scheduled indicators update stopping without a word in /var/log/idstower/indicators_updates.log when it could not write the indicators to the host, because the disk was full, the file system had turned read-only, or a directory could not be created. It now logs which directory or file it could not create or write, and stops. Affected IDSTower 3.0.0 to 3.1.1.

• BugFix: Fixed the health heartbeat of a managed host never being sent when the host has neither python3 nor python installed, so IDSTower heard nothing from that host. The heartbeat is now sent as usual, and IDSTower keeps showing the Python version it recorded when it deployed the host. Affected IDSTower 3.0.0 to 3.1.1.

• BugFix: Fixed IDSTower writing a Suricata binary path that does not exist into the service unit files it generates, on a host where Suricata is no longer installed (a package removed by a failed reinstall or upgrade, or a sensor container rebuilt from an image without it). On a cluster whose configured service status is inactive the update reported success; on an active one it failed later, with systemd’s status=203/EXEC. Applying or verifying a configuration, registering IDSTower’s rule files in an onboarded configuration, and starting or restarting a service now fail on that host alone, saying Suricata is not installed on it: reinstall the Suricata package on the host, or remove the host from the cluster and add it again. Stopping instances and disabling IDSTower’s management of the host still work. IDSTower also now looks for the binary as onboarding an existing installation does (on PATH, in the ExecStart of an existing Suricata systemd unit, in a running Suricata process, and in the usual install locations), so a Suricata built from source into a custom prefix is no longer reported as missing by a later configuration update.

• BugFix: Fixed a fresh deployment writing the wrong Suricata binary path into the service units it generates when the installed package puts the binary somewhere other than the usual location for the host’s distribution (/usr/bin/suricata on Debian/Ubuntu, /sbin/suricata elsewhere), such as a User Custom repository package built with the prefix /usr/local/bin or /opt/suricata/bin. The installation and the configuration both reported success, and then every instance failed to start with status=203/EXEC. IDSTower now asks the host where the binary is once the packages are installed. Deployments using the Built-In repository or the distribution’s own packages are unaffected.

• BugFix: Fixed installing or upgrading Filebeat on Ubuntu, Debian and other apt-based hosts failing with a misleading NO_PUBKEY D27D666CD88E42B4 error when the host could not download Elastic’s repository signing key, for example because curl was not installed or artifacts.elastic.co was unreachable. The key is now downloaded with retries and checked to be a valid key before it replaces the installed one, and a failed download is reported as what it is.

• BugFix: Fixed the installation script, and the Docker image when you pass it an administrator account to create, finishing without that account on slow hardware. Both waited 5 seconds for IDSTower’s prompts while creating the account, and IDSTower’s first start can take longer; they now wait up to 60 seconds.

• BugFix: Fixed startup failures reporting only part of the reason. A small syntax mistake in appsettings.json, the commonest cause, was reported as “Could not parse the JSON file” without the line number or the offending character; a comment started with # instead of // now reads '#' is an invalid start of a property name. Expected a '"'. LineNumber: 2 | BytePositionInLine: 4. The other failures that stop IDSTower from starting now show their complete error too: loading the HTTPS certificate (a wrong password, a file that cannot be read), validating the configuration, migrating the database schema, and initialising the database, which used to give the detail without saying which startup step had failed.

• BugFix: Fixed IDSTower crashing with an unhandled ArgumentNullException stack trace and a meaningless exit code (-532462766), instead of an explanation, when Logging -> LogFile was not set in the configuration file. IDSTower now names the setting and the file it expects, and exits with code 1.

• BugFix: Fixed a managed host receiving an empty 406 Not Acceptable instead of a readable 400 Bad Request when its rules or indicators request was rejected as malformed. The update scripts skip that run either way, but an operator re-running suricata_rules_update.sh or suricata_indicators_update.sh with --debug to find out why a host had stopped receiving rules saw nothing naming the cause. Those requests now get 400 with the reason as plain text, such as “Invalid Api Key.” or “The InstanceName field is required.”

• BugFix: Fixed the Suricata log clean-up not reporting a log it could not delete. On a file system that had turned read-only, or for a file protected by an immutable attribute, /var/log/idstower/logs_deletion.log said “Deleting Suricata log: …” and nothing more, so a disk the clean-up could not free looked handled. Each log it cannot delete is now reported as an error with the reason, and the clean-up goes on with the others. Affected IDSTower 3.0.0 to 3.1.1.

• BugFix: Fixed removing the logshipper putting the cluster’s health into Error (“Some services are not running”) until every host’s configuration had been updated, because the hosts go on checking the removed Filebeat until then. Health now counts only the software installed on the cluster, so after a removal it shows that the hosts need a configuration update, which stops them checking Filebeat, and the removal dialog says to run Update Config once it has finished.

• BugFix: Fixed hosts removed from a cluster staying selected in the hosts tab, so that acting on the selected hosts afterwards failed with “Host … not found in Cluster …”. Removed hosts now leave the selection as soon as the removal finishes, and the cluster list in the side menu now updates right after hosts are removed or added.

• BugFix: Fixed the edit icon of an instance’s Monitored Interfaces in the hosts tab opening an empty dialog (No hosts available to modify interfaces, titled on 0 Selected Hosts) when another instance’s interfaces had been edited or the dialog cancelled earlier, until the page was reloaded. It now always opens on the instance whose icon you clicked.

• BugFix: Fixed AWS Connector error messages showing raw placeholders instead of the values they name: an operator whose export failed was told “AWS Network Firewall in Region: {DisplayName} couldn’t perform the operation” rather than which region. Fifteen messages were affected, naming regions, rule groups, ARNs, export names and error details, among them the one shown when the connector is unlicensed. The IDSTower log always carried the right values.

• BugFix: Fixed the Delete Expired Rules After and Delete Expired Indicators After settings showing a value that was never saved. When a change was refused, for example because the user has no permission to change these settings, the error showed but the setting kept the refused value until the page was reloaded. It now goes back to the saved value.

• BugFix: Fixed the Deployment Targets line of a rule deployed with a custom deployment template showing undefined in place of the cluster of each targeted config group and the host of each targeted instance, for example Included Conf Groups: Default (undefined). It now names them, as the Template: badge in the rules list already did.

• BugFix: Fixed the grey overlay staying on screen after deleting an indicator from its details page, dimming the page and swallowing every click until a full page reload. This affected any dialog whose confirmation navigates away from the current page.

Please Follow the Upgrade Guide from v3.1.x to v3.2.0 to update IDSTower to this version.