[Oisf-users] Reloading configuration not possible without restarting Suricata?

[Timo Sigurdsson]

Hi,

I'm new to Suricata and installed Suricata 4.1.2 on my Debian-based router/gateway that gets its external connection via PPPoE with dynamic IPv4 and IPv6 addresses. I added hooks to my PPPoE client daemon as well as DHCPv6 client daemons that update the Suricata configuration (HOME_NET variable) each time a new IPv4 address or IPv6 prefix is received. My problem is that the new configuration becomes effective only after a full restart of Suricata. This is unfortunate, since I receive new addresses at least once a day and the restart takes a while, so there's always a short period during which Suricata is not running merely since the addresses changed.
I found an old bug report [1] that implies that updating variables through a reload signaled by USR2 should work. I tested this, however, and couldn't verify this. Reloading via the Unix socket and suricatasc doesn't work either.

Here's what I tested:
1) Run:
  suricatasc -c "conf-get vars.address-groups.HOME_NET"
to determine the current value of $HOME_NET
2) Change the value of HOME_NET in suricata.yaml
3) Reload Suricata either via:
kill -USR2 $SURICATA_MAIN_PID
or:
suricatasc -c ruleset-reload-nonblocking
4) Wait for the reload to complete
5) Re-run:
suricatasc -c "conf-get vars.address-groups.HOME_NET"
and see that the output hasn't changed.

I also tried this with other configuration items. It seems that changes to the suricata.yaml file are ignored during a reload.

So, my question is: Is there really no way of updating at least the address variables without a full restart of Suricata?

Note: My hook scripts don't actually change suricata.yaml, but separate yaml files that are included in the address-groups section of the main configuration file. During a reload Suricata actually logs that the files are included, but the values used (or shown by suricatasc) are the old ones. I also tested changing suricata.yaml directly without the includes, but that doesn't seem to make a difference.

Thanks and regards,

Timo

[1] https://redmine.openinfosecfoundation.org/issues/1277