I’m experiencing an issue where Suricata crashes when processing PCAP files captured from CAPEv2. Whenever I attempt to analyze these PCAPs with Suricata, the suricata.service unexpectedly stops.
When it stops, the Suricata service crashes (with the result ‘exit-code’.), making the socket inaccessible by the cape-processor.
The “/var/log/suricata/suricata.log” has recorded “Unable to create thread with pthread_create() is 11” error.
I’ve also detailed this issue further on the CAPEv2 GitHub repository: Issue #1717.
command used to launch the Suricata process.
There were 3 ways (which all has the same issue) that suricata was used:
Using Suricata command:
cape@capev2-virtual-machine:/opt/CAPEv2$ suricata -c /etc/suricata/suricata.yaml -r /opt/CAPEv2/storage/analyses/1/dump.pcap
i: suricata: This is Suricata version 7.0.0 RELEASE running in USER mode
E: privs: capng_change_id for main thread failed
cape@capev2-virtual-machine:/opt/CAPEv2$ ps aux | grep suricata
cape 4533 99.9 0.9 392808 328192 ? Rs 13:48 0:09 /usr/bin/suricata -D -c /etc/suricata/suricata.yaml --unix-socket
Using CAPEv2 build in python script utility to call suricata service:
capev2@capev2-virtual-machine:/opt/CAPEv2$ sudo -u cape poetry run python utils/process.py 1
2023-08-29 13:44:52,882 [Task 1] [modules.processing.suricata] WARNING: Failed to get pcap status breaking out of loop: [Errno 104] Connection reset by peer
/opt/CAPEv2/utils/…/lib/cuckoo/common/abstracts.py:987: FutureWarning: Possible nested set at position 5
exp = re.compile(pattern, re.IGNORECASE)
Using CAPEv2 itself, part of the code contain the calling of suricata command.
It looks like pthread_create is returning with a no resource available error. This is mostly likely a system level issue, some hardening perhaps, preventing Suricata from creating processes.
One thing to try is disabling limit-noproc. In your suricata.yaml look for the following:
security:
# if true, prevents process creation from Suricata by calling
# setrlimit(RLIMIT_NPROC, 0)
limit-noproc: true
And set limit-noproc to false and retry again. If this helps, we might be running into a conflict against some local system level hardening and our own attempt at hardening.
Either way, it looks like the kernel is preventing Suricata from creating new processes and threads. Suricata itself doesn’t turn this hardening measure on until all the threads are created.
There is also an issue when suricata.yaml contains run-as section that is not empty and you attempt to run Suricata as a non root user. Suricata needs to be started as root to properly change/drop privileges back to that user. This feature is primarily used when monitoring live networks.
If the primary usage is PCAPs, it would probably be best to not have a run-as section, and just start Suricasta as a non root user.
In short, having a run-as section requires starting Suricata as root.