Hello,
I installed Suricata, enabled etpro and did the suricata-update, it ran fine without issues. Rule file was compiled into
-rw-r–r-- 1 root suricata 44133288 May 4 22:16 /var/lib/suricata/rules/suricata.rules
When I run suricata, it gives me this:
4/5/2021 – 22:24:42 - - stats output device (regular) initialized: stats.log
4/5/2021 – 22:24:42 - - Running in live mode, activating unix socket
4/5/2021 – 22:24:42 - - [ERRCODE: SC_ERR_FOPEN(44)] - could not open: “/var/lib/suricata/rules/classification.config”: Permission denied
4/5/2021 – 22:24:42 - - [ERRCODE: SC_ERR_OPENING_FILE(40)] - please check the “classification-file” option in your suricata.yaml file
4/5/2021 – 22:24:42 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /var/lib/suricata/rules/suricata.rules
4/5/2021 – 22:24:42 - - [ERRCODE: SC_ERR_NO_RULES_LOADED(43)] - 1 rule files specified, but no rules were loaded!
4/5/2021 – 22:24:42 - - Threshold config parsed: 0 rule(s) found
4/5/2021 – 22:24:42 - - 0 signatures processed. 0 are IP-only rules, 0 are inspecting pa
Tried everything, dir and file permissions, no luck. Everything seems to be in the right place. Suricata is running as root so that cause permission issues. No errors on update, but it just won’t load. Any ideas? TIA
It’s running as root so perm shouldn’t be an issue unless there is some caveat I’m not aware of.
Oddly the rule file is created with 600
-rw------- 1 root suricata 44171023 May 4 22:49 suricata.rules
But when I change to 644 it seems to work on et but not etpro
If it’s running as root, why does this matter? Is there a way to create the rule files with necessary permissions? Also, does suricata service need to be restarted after updating or it takes effect? Thanks
When using the RPM and starting Suricata with systemctl, Suricata will actually run as the suricata user, not root. So that is something to be aware of.
Thanks, that’s helpful! So it would make sense to add to the update cronjob the permission bits then. Once update runs, does the engine need to be restarted?
The engine needs to be restarted or sent a SIGUSR2 to reload the rules.
The idea with the RPM and the 2770 mode on /var/lib/suricata is that you can run suricata-update as root, or as a user in the suricata group to avoid using root altogether. I’ve never seen a need to update permissions as part of the cronjob, at least not on a default CentOS 8 install with default umasks, etc.