Questions about Suricata Multi-Tenancy Configuration Changes and Service Restart

Hello,

I have some questions regarding Suricata’s multi-tenancy configuration management:

  1. When a tenant’s configuration is modified, does Suricata require a complete service restart to load the new configuration?

  2. If a service restart is required, how does this affect traffic analysis for other tenants? Are there any ways to avoid impacting other tenants during configuration changes?

  3. Specifically, for tenant-specific configurations, which changes require a full service restart versus just a configuration reload:

    • Modifying classification-file
    • Changing reference-config-file
    • Updating address-groups variables
    • Other tenant-specific parameters

I’m trying to understand the best practices for managing tenant configurations while minimizing service disruption in a production environment.

Thank you for your help!

Best regards

Hi,

I was just working on this and i’ve done it like this:

suricata.yaml:

detect-engine:
- rule-reload: true

after modifying any of the rules I do:

suricatasc -c ruleset-reload-nonblocking

source: 9.3. Rule Reloads — Suricata 8.0.0-dev documentation

I think as described in the manual this way there is a minimal service disruption on analyzing traffic.

Can I ask you what do you mean with a multi-tenancy configuration, you are running infrastructure for multiple clients on your system ?

Regards,
Steven

Hi,

Suricata can reload rules and rule variables without a complete service restart (I’m assuming you mean restarting the suricata process).

Suricata’s multi-tenancy documentation shows how to configure Suricata support for multiple-tenants.

The basic tenet of multi-tenancy (pun intended :-)) is to provide different rules, reference and classification config files, and rule variables for each tenant.

suricatasc supports reloading individual tenants when the rules, config files, and/or rule variables change.

Thank you for your response. As Jeff Lucovsky mentioned, multi-tenancy is what we’re referring to. Additionally, I have also practiced the relatively lossless rule reloading that you described.

Thank you Jeff for the detailed explanation. Now I understand that multi-tenancy in Suricata allows:

  1. Different configurations for different tenants including:
    • Different rules
    • Different reference files
    • Different classification config files
  2. And using suricatasc, we can reload configurations for individual tenants without affecting others.

I’ll check out the multi-tenancy documentation you linked for more details on the setup process.

I was a little bit too fast when not fully awake :slight_smile:

I understand after reading the post again, also interested in this topic did not know this was even possible.

From my understanding having a quick view at the Multi-Tenancy documentantion is that every VLAN can have its own ruleset, would be something to test for me in the future.

@ aaaaaaarror I was a little bit too fast when not fully awake :slight_smile:

I understand after reading the post again, also interested in this topic did not know this was even possible.

From my understanding having a quick view at the Multi-Tenancy documentation is that every VLAN or device (IPS not supported here, device looks like a network interface in the example) can have its own ruleset, would be something to test for me in the future.