TLDR;
What if we add a dynamic feature to address-group vars via fqdn strings in the list? Have Suricata resolve and add/remove as ( static +/- ( dynamic +/- updates) ) or whatever works better.
The long:
There are several dynamic IP hosts on my network that the local FQDNs get updated for (hostname.homelab.home) and it would be useful to use address-groups of lists of local FQDNs that Suricata would periodically resolve according to the OS DNS stack or in Suricata stack via a list of specified DNS Servers. The later might be preferred, as the extra control could be very useful.
The vars are used in mapping a few bypass rules, as well as some of the suspicious and HTTP rules have been modified using suricata-update to use address-groups.
In addition to the list of IPs found in address-group vars, if there could also include FQDNs that Suricata would find the IPs (ipv4 and ipv6) for and dynamically update that address-group var according to the new IPs. It might be nice to have an age off time period there too, as well as a setting about how often to update each fqdn enhanced now dynamic list. The update would keep any otherwise now ‘static IP’ or ‘static Subnet’ additions or removals that are part of the address-group.
The alternative is, and it is a bit much, to make a shell script to update the vars in the suricata custom.yaml file for me. The host is FreeBSD and I’ve had the darndest time trying to get a shell script that will resolve the IPs for the FQDNs and then dynamically update the var entries in custom.yaml. In short, that’s what I’m slowly still after - it is just a tall leap so far.
My thoughts are this might be a really useful feature for many of us, and would mean I could just keep really clean and recognizable address-group vars.
Thanks for the feature suggestion! Have you considered adding it as a Redmine ticket?
Easier for the team to track, and to filter in terms of feedback given (e.g. is this something we would consider, but would ask the community to maintain? Something else?)
Hope the last half year plus has treated you well Ju! Got to thinking about it and it seemed that if the FQDN storage required use of a Redis DB Cache, that would make sense, and further, wanted to see what the availability would be to be able to ‘surciatasc’ update group/port vars and/or other config level details that could persist in a Redis DB Cache (at the start of Suricata, it could populate a configured Redis cache with config state (and per tenant I would presume), and then we could issue updates to the config in Redis, and request Suricata reload/restart to use new-state in Redis?
It seems Redis is used with Suricata already but the existing Redis integration feature is for event output, not state/config? Please correct me if I am wrong!
Wanted to update the feature request with these details… but wasn’t sure if that would delay it or if it is even getting traction in its current request form, and if an update/re-request might be in order?
While I haven’t worked with this part of Suri yet, from what I can see, that’s indeed the case.
So, as of now, I imagine that an external script/ process could be run to maybe update some Suricata config with the new-state in Redis, if one wanted…
Unfortunately, I don’t think the feature request got very far, yet, in terms of team’s assessment. I think that if you have more to add, be it for description or possible development approaches, these are welcome
I ended up not asking this before, but would you be up for working on this feature yourself? This could certainly speed up things in terms of this being developed – as you can imagine.
