Bug #1497
closedconfusing interface configuration
Description
In the .deb packages there are both /etc/default/suricata and /etc/suricata/suricata.yaml
First one has options IFACE and LISTENMODE but if "af-packet" is chosen as listen mode than IFACE option iscompletely ignored and the value from suricata.yaml is taken instead. With no error messages about options overlap etc.
This is highly confusing and a real nightmare to troubleshoot. Would be much, much better if interface to work could be configured in one single place only. Otherwise if such an option overlap detected than it have to be fatal error preventing suricata from starting at all instead of silently choosing potentially incorrect interface.
Updated by god lol almost 9 years ago
Updated by Victor Julien almost 9 years ago
These are meant to be a drop in replacement for the ones packaged by Ubuntu (which bases them on Debian), so they support what the Debian maintainers have created. It's only used by the packages init script, so you can bypass it easily.
Updated by god lol almost 9 years ago
I've failed to parse previous comment. Could you please reformulate that into simpler English?
Updated by Peter Manev almost 9 years ago
- Status changed from New to Closed
It means that it is difficult to facilitate one script and one config that will fit all possible user case scenarios.
For you it is af-packet , for some other user it might be pf-ring, for a third pcap...nfqueue.
you can have a look at the /etc/init.d/suricata script to get a better understanding/view why.
The script however gives a good/default/working out of the box base that you can further use to build upon and adjust for your particular deployment scenario.
Thank you
Updated by god lol almost 9 years ago
This bug is not about preferred default values - it's about the fact that those values are configurable through 2 (!) completely separate files with unclear preference with regards to each other. Would be much more clear if it were only 1 single file where I have to change whatever is default without bothering to look someplace else.
Updated by Peter Manev almost 9 years ago
Suggestions for addressing this are always welcome for feedback.
Updated by god lol almost 9 years ago
Simple really: kill all the option in /etc/default/suricata which have their equivalent in /etc/suricata/suricata.yaml
Having multiple locations to configure the same thing does not add "flexibility" - it adds confusion by violating single-source-of-truth principle.
Personally I would just remove /etc/default/suricata completely, although I guess leaving there RUN, RUN_AS_USER and SURCONF would suit most people.
Updated by Victor Julien almost 9 years ago
The reason it's there is that Debian package (the one the debian project maintains) has it. Ubuntu thus also has it (they take it from Debian). As Ubuntu has it, we have it too in our PPA. This is because the goal of the PPA is to provide a seamless upgrade path from the distro-versions.
The file is only used by the init script, not by suricata itself.
Updated by god lol almost 9 years ago
So, wouldn't having the same file with minimal number of options (even simple RUN=yes would do) suffice for upgrade path?
Updated by Victor Julien almost 9 years ago
I don't see how. The default file determines IPS vs IDS mode for example. So we couldn't leave that out.