Hi all, [...] >>> As a suitable alternative location, one might think of something along >>> the lines of /var/lib/suricata/rules -- FHS states that the contents of >>> /var/lib should reflect a program’s variable internal state while >>> running [2], and the rules may be a special case here (as they change >>> the internal state of Suricata only when loaded or reloaded). It is also >>> stated that the user should never need to modify these files, but I am >>> not sure whether this also includes using a specific automation tool >>> such as oinkmaster or pulledpork for that purpose. >>> Still, this sounds like the best option. Any comments? [...] >> >> thinking again about this, I believe you are right. >> >> However, this movement is something I would like to coordinate with >> upstream (CC'ing Victor), >> since it doesn't make sense to me to point in Debian to one location >> while Suricata upstream points to another (in docs, recommendations, >> defaults, etc.) >> >> @Victor, any comment? [...] > > We're discussing this internally currently, but we tend to agree. > However we want to have a good look at what it would mean for users.
Absolutely.
> Ideally we'd update Suricata to support multiple rule locations cleanly.
That would be great! I would love to be able to do something in
suricata.yaml like:
rules:
- rule-path: /var/lib/suricata/rules
rule-files:
- etpro-trojan.rules
- etpro-malware.rules
- etpro-mobile_malware.rules
- etpro-worm.rules
...
- rule-path: /etc/suricata/rules
rule-files:
- decoder-events.rules
- stream-events.rules
- dns-events.rules
- app-layer-events.rules
- modbus-events.rules
- tls-events.rules
...
to, for instance, separate Suricata-specific rules (that might be
bundled with a Suricata release and hence I would consider OK in /etc)
from externally updated rules (such as ETPRO etc.)
Any opinions?
Cheers
Sascha
signature.asc
Description: OpenPGP digital signature
