Bug #2134
closedConfig test (suricata -T) return non-zero exit code if config is correct
Description
# suricata -V This is Suricata version 3.2.1 RELEASE # suricata -c /etc/suricata/suricata.yaml -T -v 7/6/2017 -- 14:21:57 - <Info> - Running suricata under test mode 7/6/2017 -- 14:21:57 - <Notice> - This is Suricata version 3.2.1 RELEASE 7/6/2017 -- 14:21:57 - <Info> - CPUs/cores online: 2 # echo $? 1
Suricata is installed official ubuntu ppa.
Files
Updated by Andreas Herz almost 7 years ago
- Assignee set to Anonymous
- Target version set to Support
I can't reproduce that, can you paste your suricata.yaml?
suricata -c /etc/suricata/suricata.yaml -T -v 7/6/2017 -- 22:34:20 - <Info> - Running suricata under test mode 7/6/2017 -- 22:34:20 - <Notice> - This is Suricata version 3.2.1 RELEASE 7/6/2017 -- 22:34:20 - <Info> - CPUs/cores online: 4 7/6/2017 -- 22:34:20 - <Info> - Running in live mode, activating unix socket 7/6/2017 -- 22:34:28 - <Info> - 38 rule files processed. 13069 rules successfully loaded, 0 rules failed 7/6/2017 -- 22:34:28 - <Info> - 13077 signatures processed. 1246 are IP-only rules, 5468 are inspecting packet payload, 8013 inspect application layer, 0 are decoder event only 7/6/2017 -- 22:34:32 - <Info> - Threshold config parsed: 0 rule(s) found 7/6/2017 -- 22:34:32 - <Info> - fast output device (regular) initialized: fast.log 7/6/2017 -- 22:34:32 - <Info> - eve-log output device (regular) initialized: eve.json 7/6/2017 -- 22:34:32 - <Info> - stats output device (regular) initialized: stats.log 7/6/2017 -- 22:34:32 - <Notice> - Configuration provided was successfully loaded. Exiting. [root@foobar ~]% echo $? 0
Updated by Pavel Selivanov almost 7 years ago
- File suricata.yaml suricata.yaml added
Here it is. It's almost default. default-rule-path is changed, because OSSEC generates alerts every time files is /etc are changed.
And Suricata is running fine with this config, just the check fails.
Updated by Pavel Selivanov almost 7 years ago
- File ltrace-suricata ltrace-suricata added
- File strace-suricata.22962 strace-suricata.22962 added
Here are strace and ltrace outputs. strace shows, that process end soon after opening emerging-icmp.rules:
stat("/var/lib/suricata/rules/emerging-icmp.rules", {st_mode=S_IFREG|0640, st_size=8563, ...}) = 0
open("/var/lib/suricata/rules/emerging-icmp.rules", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0640, st_size=8563, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3939211000
read(4, "# Emerging Threats\n#\n# This dist"..., 4096) = 4096
read(4, "pted-recon; sid:2100466; rev:5;)"..., 4096) = 4096
read(4, "vity; sid:2100463; rev:8;)\n\n#ale"..., 4096) = 371
read(4, "", 4096) = 0
close(4) = 0
munmap(0x7f3939211000, 4096) = 0
exit_group(1) = ?
+++ exited with 1 +++
Under ltrace process is runinng in infinite loop with pthread_mutex_init, last actions before the loop are:
29408 strcmp("memcap", "trackers") = -7
29409 strcmp("hash-size", "trackers") = -12
29410 strcmp("trackers", "trackers") = 0
29411 strlen("65535") = 5
29412 __memcpy_chk(0x7fff0af03fd0, 0x7fb34783abe0, 5, 24) = 0x7fff0af03fd0
29413 __errno_location() = 0x7fb3463796b0
29414 strtoull(0x7fff0af03fd0, 0x7fff0af03fc8, 10, 0x35333535) = 0xffff
29415 calloc(65536, 56) = 0x7fb3419e3010
29416 memset(0x7fb3419e3010, '\0', 3670016) = 0x7fb3419e3010
Updated by Andreas Herz almost 7 years ago
I can reproduce it with your config (just had to adjust the rules path). But it looks like your config file is quite old, so I suspect it's a config option. I did a diff of default suricata 3.2.2 config and yours and found several differences. Could you try to narrow it down which option it is?
Updated by Pavel Selivanov almost 7 years ago
- File emerging-icmp.rules emerging-icmp.rules added
- File suricata.yaml suricata.yaml added
Here is much shorter suricata.yaml, that reproduces this problem with suricata 3.2.2
And here is emerging-icmp.rules file, which seem to cause the problem. When you comment out line
- emerging-icmp.rules
problem disappears.
Updated by Andreas Herz almost 7 years ago
The issue is that you only include this rule file which doesn't include any rules. As soon as you enable one of the icmp rules it's working as expected. That's a bug in 3.2.2 but I couldn't reproduce it with 4.0.0-rc1 where you get the proper error message:
<Warning> - [ERRCODE: SC_ERR_NO_RULES_LOADED(43)] - 1 rule files specified, but no rule was loaded at all!
Updated by Pavel Selivanov almost 7 years ago
Well, it may be worth fixing this in currently stable 3.2 branch. If you expect number of affected old version users insignificant, this can be closed as "fixed in next version".
Updated by Andreas Herz almost 6 years ago
- Status changed from New to Closed
we will go with the fixed in next version route, thanks for reporting!