Wrong (?) configuration for Suricata classification & reference

[kam193]

Describe the bug
Trying to understand issues with Suricata (still not unclear, the only relevant log is pcap_next_ex(): -2), I've found out two small issues - Suricata reports missing additional config files:

[32 - Suricata-Main] 2024-09-13 13:20:18 Warning: classification-config: could not open: "/etc/suricata/classification.config": No such file or directory
[32 - Suricata-Main] 2024-09-13 13:20:18 Error: classification-config: please check the "classification-file" option in your suricata.yaml file
[32 - Suricata-Main] 2024-09-13 13:20:18 Error: reference-config: Error opening file: "/etc/suricata/reference.config": No such file or directory
[32 - Suricata-Main] 2024-09-13 13:20:18 Error: reference-config: please check the "reference-config-file" option in your suricata.yaml file

After verifying config generated by the AL service and the file system, it's turned out files exist, but in the /usr/local/etc/suricata/ directory, while the config points to the /etc/.

To Reproduce
Steps to reproduce the behavior:

1. Start suricata service
2. Connect to the container console and read log from /usr/local/var/log/suricata/suricata.log

Expected behavior
This is an open question. The fix is trivial, but my question to Suricata & AL experts is: does it matter? Does it change anything in how AL treats the results, or if Suricata is successful in the analysis?

The Suricata documentation points that it helps to better understand the purpose of rules, but maybe AL just does not use it and thus, it's an intentional misconfiguration?

Screenshots

Environment (please complete the following information if pertinent):

• Assemblyline Version: 4.5.0.45
• Suricata service: 4.5.0.34

Additional context

[cccs-rs]

So far I don't think it impacts AL's analysis using Suricata:

classification-config looks to provide some enrichment in the logs produced, which could make the output "prettier" to read but I think the omission of that configuration shouldn't cause a problem.

reference-config looks like another way of enriching the alerts generated based on OISF's reference.config which also shouldn't impact the performance of the Suricata service.

Those particular lines in the suricata.yaml file seems to have been there for the past 7 years, so it's possible these are old configurations that were just copy-pasted from another environment even though they don't apply in this case.