Suricata-update ERRCODE: when suricata -T runs

Rules
1

Hi,

I am running suricata v6.0.1. I am using suricata-update to manage my rules. I use the update.yaml (defaults) file, and I have the disable/enable/modify configuration files defined, I specify ignore: of several rules files, and I specify url download of rules. (ETPRO). I do not specify a test command. I left that at the defaults.

Suricata update is working as expected up until the end:
Testing with suricata -T
Error ERRCODE: SC_ERR_FOPEN(44) Error opening file /tmp/tmpxxxx/fast.log Permission Denied
Error ERRCODE: SC_ERR_INVALID_ARGUMENT(13) output module “fast”: setup failed

I have suricata running on several servers, and I am not seeing a difference that explains the errors.

Any thoughts?

Thanks!

2

So it works on some servers, but not this one?

When Suricata-Update runs suricata -T it uses a temporary log directory under /tmp, and in this case it looks like the user running Suricata-Update can’t write to it. Can the user you are running Suricata-Update as create files in /tmp?

3

Hi Jason…Yes I am running suricata-update as root on the server, which is why I am scratching my head as to why I am getting a permission error. /tmp is 777.

4

I haven’t tested if this would actually cause issues or not, but do you have a run-as section in your suricata.yaml?

5

I do have run-as defined to user/group suricata. Interesting I did not think of this. On the servers that appear to be happy I have run-as commented out. I tested this and that appears to be the issue. I would have been digging for some time to identify that. I use one server to typically handle suricata-update and pushing of the rules, but in my development space I sometime need to run it local.

Thank you Jason for the quick response and the pointer.

6

Thinking out loud here, without run-as, suricata wouldn’t drop from root.

In the interest of continuing to drop down to the suricata user, if I fix all permissions back to suricata user : group, I get this error:
<Error> -- [ERRCODE: SC_ERR_FATAL(171)] - capng_change_id for main thread failed

Any ideas on how to fix this? I tried this, which failed (same error as above):
sudo setcap cap_net_admin,cap_net_raw+ep /usr/bin/suricata

7

In the .yaml file under run options, remove the hash from the following lines, and change the user & group to the following:

run-as:
user: suricata
group: suricata

Then in command line run the command:

chown suricata:suricata /var/log/suricata/*

Then run: systemctl restart suricata

And BAM Bob’s your uncle!

8

This doesn’t seem to work for me, I wonder if this is related to a newer Arch vanilla kernel somehow. I’ll try playing around with an LTS kernel instead and report back.