Suricata stops running

[psypro]

Problem :
Suricata starts, and works. But in a few minutes crash/stop working.
I have tried Suricata on my openbsd laptop openbsd 7.1 it runs for days no problem, and works.


Solution tryed :

a) As in pkg_readme

b) Remove -D

c )Trying configuration from laptop on 7.1 on my 7.0 firewall. Edited to correct firewall em0 interface(same problem )




History :

Firekeep (Firewall ) openbsd 7.0
Output from top :

  PID USERNAME PRI NICE  SIZE   RES STATE     WAIT      TIME    CPU COMMAND
54322 _suricat  10    0  593M  591M sleep/1   nanoslp   1:01  3.22% suricata

Firekeep# cat /var/run/rc.d/suricata                                                                                                                                    
daemon_class=daemon
daemon_flags=-i em0
daemon_logger=
daemon_rtable=0
daemon_timeout=30
daemon_user=root
pexp=/usr/local/bin/suricata -D -i em0

I trieed removing -D from (did not work)

Firekeep# rcctl start suricata            
suricata(timeout)
Firekeep# rcctl check suricata 
suricata(ok)
Firekeep# top
Firekeep# rcctl check suricata 
suricata(failed)
Firekeep#

Working config from laptop :

cat /var/run/rc.d/suricata  
daemon_class=daemon
daemon_flags=-i iwm0
daemon_logger=
daemon_rtable=0
daemon_timeout=30
daemon_user=root
pexp=/usr/local/bin/suricata -D -i iwm0
rc_reload_signal=HUP
rc_stop_signal=TERM

working config from laptop

cat /etc/rc.d/suricata      
#!/bin/ksh

daemon="/usr/local/bin/suricata -D"

. /etc/rc.d/rc.subr

rc_pre() {
	/usr/bin/install -d -o _suricata -g _suricata -m 0750 /var/run/suricata
}

rc_cmd $1

[psypro]

I gave up OpenBSD 7.0

Everything worked with OpenBSD 7.1.

Just following instructions from pkg_readme did the trick. in 7.1

[psypro]

In the 1000 of ip that pass trough the firewall, Suricata in just a few second gave me reason to look into what this is.. someone sneaking past my local dns, or some malware ?

04/17/2022-18:55:03.365699  [**] [1:2028380:2] ET JA3 Hash - Possible Malware - Neutrino [**] [Classification: Unknown Traffic] [Priority: 3] {TCP} 192.168.0.30:45262 -> 34.247.141.30:443
04/17/2022-18:55:04.085811  [**] [1:2028380:2] ET JA3 Hash - Possible Malware - Neutrino [**] [Classification: Unknown Traffic] [Priority: 3] {TCP} 192.168.0.30:34750 -> 3.248.141.252:443
04/17/2022-18:55:13.228591  [**] [1:2028380:2] ET JA3 Hash - Possible Malware - Neutrino [**] [Classification: Unknown Traffic] [Priority: 3] {TCP} 192.168.0.30:45274 -> 34.247.141.30:443
04/17/2022-18:55:16.268874  [**] [1:2210044:2] SURICATA STREAM Packet with invalid timestamp [**] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} 192.168.0.42:35457 -> 45.57.16.141:443
04/17/2022-18:55:32.558398  [**] [1:2028380:2] ET JA3 Hash - Possible Malware - Neutrino [**] [Classification: Unknown Traffic] [Priority: 3] {TCP} 192.168.0.30:35356 -> 54.74.94.149:443

[jggimi]

Originally Posted by psypro

Problem :
Suricata starts, and works. But in a few minutes crash/stop working.
I have tried Suricata on my openbsd laptop openbsd 7.1 it runs for days no problem, and works.

OpenBSD 7.1 does not yet exist as of this moment. I will guess you mean you have tried runing the application on -current, on a different system, and could not replicate the problem.

Disclaimer: I have no experience with Suricata.

If you wish to debug a crash of Suricata:

• Obtain a copy of the Suricata source code. Since the OpenBSD port of Suricata includes OpenBSD-specific patches, this is easiest to obtain with a copy of the 7.0 ports tree installed and a `make patch` command from /usr/ports/security/suricata as your working directory. For more on the ports tree, see ports(7) and related man pages.
• Install the `debug-suricata` debugging symbols package.
• Install the GNU debugger, the `gdb` package. The older built-in gdb(1) cannot debug most packages. The package debugger executable program is named "egdb" to distinguish it from the built-in gdb(1).
• Set the sysctl kern.nosuidcoredump=2 to enable core dumps of this setuid program to be stored in /var/crash/.
• After a crash, run the debugger with # egdb suricata /var/crash/suricata.core. A backtrace of the active thread can be obtained with the `bt` command, and if you want a backtrace of all threads you can use `thread apply all bt`.

If the application is hanging instead of crashing, the GNU debugger can be used to diagnose a running process with the process ID number. For example, if you use pgreg(1) to learn that the process ID of Suricata is 12345, then you can examine the running application with # egdb suricata 12345. A backtrace of the active thread can then be viewed with `bt`.

Armed with the source code and backtraces, you may be able to determine what has been happening, and why.You can set the debugger to any frame number within any stack backtrace to examine variables and step through the code. And, Suricata has a port maintainer you can reach out to if you need more assistance with diagnosis.

For a lot more on using the GNU Debugger, you can use $ info gdb. The info(1) documentation tool is quite complicated. I prefer to pipe all of its output to a simple pager, such as with $ info gdb | less.

[jggimi]

Originally Posted by psypro

In the 1000 of ip that pass trough the firewall, Suricata in just a few second gave me reason to look into what this is.. someone sneaking past my local dns, or some malware ?

LOOK at the traffic that has been flagged for your review. What are you presented with? What can you learn from it?

For example, here's the first log entry:

04/17/2022-18:55:03.365699  [**] [1:2028380:2] ET JA3 Hash -  Possible Malware - Neutrino [**] [Classification: Unknown Traffic]  [Priority: 3] {TCP} 192.168.0.30:45262 -> 34.247.141.30:443

1. The direction of traffic is outbound.
2. The source of the packet is 192.168.0.30. This is an address on your local network, as it is an RFC1918 address.
3. The destination address is 32.247.141.30. This is an address on the Internet managed by Amazon Data Services Ireland Limited, according to whois(1). The host(1) and dig(1) tools shows it has a default FQDN of "ec2-34-247-141-30.eu-west-1.compute.amazonaws.com."
4. The destination port number is 443, which is usually used for HTTPS.
5. The origination port number is a random high number, 45262, such as used by a browser.

Does the system on your local network at 192.168.0.30 operate a web browser?

This is a review YOU must conduct, so that YOU can determine if further research is needed or not for YOUR network. Otherwise, why are you bothering to run IDS software at all?

[psypro]

Thank you

Yes, it is a learning opportunity and I have learned from your prime analysis.

I basically use finished firewall from ISP or opnsense. But during the holidays I tried to put together an OpenBSD firewall.
So finally! have I got NAT, pf, and now also suricata.
Have tried for several years to get suricata to run, so I am very very happy that suricata runs straight out of the box on snapshots for 7.1 (with a few changes as stated in pkg readme)

[jggimi]

You should notice that I did not classify the record I suggested you examine as "safe" nor did I classify the report as a "false-positive" report. This could certainly be safe traffic, or it could be unsafe traffic.

Anything can be sent to TCP port number 443. Not just HTTPS traffic.

Zombie/'bot command-and-control traffic is often masked to have an appearance like ordinary, normal traffic.

Your responsibility, as Lord and Master of your own network, is to learn whether or not this report was a false-positive. And, if it was a false-positive, why it was a false-positive and flagged for your review.