It was the HTTP inspect rules. Thanks for the help!

@bmeeks said in Snort exited on signal 11 (core dumped):

Sounds like it is working from your description.

Yes, you're right - Snort is not stopping after the "signal 11 core dump". I made a temporary "workaround" stopping the core dumping in pfsense. (not very elegant but ... until next binary ... 😊 )

@bmeeks said in Some news about upcoming Suricata updates:

Are you testing "through" pfSense or "from" pfSense? That can make a big difference. The most valid test is through pfSense. Meaning from a host on your LAN through the firewall out to a WAN testing site.

LAN Host -> pfSense -> speedtest.net
If you know a location to test with multiple connection, I can try. Also I tried p2p connections like torrents, it reaches 786 Mbps at best.

While running a speed test through pfSense, run top and see how many CPU cores are running Suricata. I would expect threads to be distributed among the cores, especially in "workers" runmode. Also note that each time you change the runmode setting, you need to stop and restart Suricata.

Suricata was stopped and restarted each time I changed the settings. Also I gave each instance of Suricata 1 minute to settle down.
2 with 2 , 3 with 1, 1 with 1 cores, it fluctuates during the speed tests. Also Suricata is enabled on 2 interfaces, and only 4 cores

And finally, remember that a speed test usually represents a single flow, so that will factor into how the load is distributed. A given flow will likely stay pinned to a single thread and core. On the other hand, multiple flows (representing different hosts doing different things) will balance across CPU cores better. This is due to how Suricata assigns threads and flows using the flow hash (calculated from the source and destination IPs and ports). So a simple speed test from one host to another is not going to be able to fully showcase the netmap changes. On the other hand, multiple speed tests from differents hosts, all running at the same time, would represent multiple flows and should balance better across the CPU cores. That would better illustrate how the multiple host stack rings are contributing.

@steveits Thank you!

@jm1384 said in Suricata v6.0.0_13 Package Update -- Release Notes (pfSense DEVEL branch only):

Hi bmeeks,
I have upgraded my pfsense 2.5.1 on stable branch to 2.5.2 stable branch but the suricata package installed is 6.0.0_14.
I don't know why.

The suricata package for 2.5.2 branch is 6.0.0_14 ?

Thank you !

Yes, some of the GUI updates made it into the Release branch.

The new 6.0.3 update should be posted for the Development Snapshots branch (or it will be shortly). That Pull Request has been approved and merged.

@bmeeks
There may actually be multiple suricata processes running in which case you could kill each PID of each suricata individual process or you can kill all of them easier in one command with pkill:
pkill suricata

@barakat_abweh said in Snort actions in the logs:

@bmeeks
thanks bro I'll consider it, but also the netgate team should consider giving that option to the users and consider the upgrade to snort3 so we can benefit the multithreading feature available in snort3

About a year ago I started work on a Snort3 package, but grew very frustrated with the effort and abandoned it. I've since cooled down a bit (or maybe time has erased the memory of that former pain ... 🙂), and so I've started back on some very preliminary work on Snort3. Nothing even remotely close to release, though.

I've decided that an easier path for Snort3 might be to just let users start with a fresh, clean plate. Don't migrate any settings except maybe the pfSense interfaces where Snort was configured, and if they match up close enough, perhaps migrate the rules configuration. Things are just too different in Snort3 to cleanly migrate all of the Snort 2.9.x settings. It was attempting to code that migration that led to my high frustration level.

The fix for this issue has now been posted to both the DEVELOPMENT and RELEASE branches of pfSense CE and pfSense+. The GUI package version is 4.1.4_3.

To maybe make you feel better, I run Snort on my LAN with the IPS Balanced policy along with some of those ET-Open categories I mentioned earlier. I see maybe one or two DROPs per month in my logs. Ironically, if you see lots of DROPs, that really should make you quite nervous about the overall security of your network. Because that would mean a lot of your LAN hosts either are, or were, visiting questionable sites or doing questionable things (and thus may be infected with malware of some sort).

Edit: some additional info ... I mentioned in one of my earlier posts above that my favorite policy was "IPS Policy Connected". That's the policy I recommend to all users new to administering an IDS/IPS. So that's the context of "favorite" in my earlier post. Once you gain experience with the IDS/IPS, you can move to something like "IPS Policy Balanced". I don't suggest anyone go beyond that unless you are protecting military secrets or access to all the UFOs stored at Area 51 ... 🙂.

@andrea-1 I have too problem how you!

Localization set eng or not? If not try set eng in pfsense and pass list can create.

The default values in Snort for "max_queued_bytes" should be sufficient for most all situations.

A common cause for seeing this error from Snort's Stream5 preprocessor is asymmetrical routing. Snort is seeing only one side of the conversation, and thus keeps queueing up bytes and never closing the session to recover memory. Likely Snort is never seeing the FIN/ACK part of the session transaction, as that would be the key to tell Snort the session is done and thus Snort can release the queue memory back into the pool for the next session to use. So when not seeing the end of previous sessions, and thus not cleaning up and recovering that memory, Snort will continue to allocate new buffer space for each session. Eventually it runs out of space, and that's the error you are seeing logged.

You can increase the amount of session queue memory, but I think that would be just a temporary fix. Examine your setup for asymmetrical routing. You can capture on the interface and examine the traffic in Wireshark to see if both sides of a session's conversation are being seen.

You've given us not a single log entry, so there is no possible way to know what might be wrong.

Go to the LOGS VIEW tab, select the suricata.log file in the drop-down there, and post its contents back here. If Suricata is encountering a startup error, it should be logged there.

Also check your pfSense system log under STATUS > SYSTEM LOGS. Post anything Suricata-related back here.

If you are getting current alerts, you may have a zombie process running. Check that with this command run from a shell prompt on the firewall:

If you see any running Suricata processes, kill them.

Edit: Oh, and last thing ... make sure you are running the very latest Suricata package. That will be version 6.0.0_12.

@bmeeks said in Can pfSense integrate with another device? (mirrored-port⇄API):

packets will leak unless you slow the network traffic down to a trickle and hold packets up on one box while the other box is inspecting them and then sending instructions over some kind of back chan

Thanks, this is incredibly informative. Just to be clear, my edge device and firewall is pfSense and it's also the one running Suricata (not inline though). I'm just experimenting with stuff for fun, and sure, anything's going to be super inefficient if it's not within kernel's reach but it must be at least better than diverting back and forth the full stream of data.

The big really big enterprise firewall-routers, something like TNSR or these 30-something core ASICs out there usually don't have these features. They do seem like they'd benefit from this approach but that's just speculation of mine, I came here to learn in the first place, I've nothing to teach. 😅

Thanks again!

@bmeeks Thanks, I didn't notice that option in interface settings. I did that and now I am monitoring the behavior of Suricata. Cheers

@bmeeks Thank you very much for your attention and help, thanks to this I have been able to carry out my laboratory perfectly. Thank you very much !!!!

@wrightsonm said in Suricata log rotation bug:

@bmeeks I would say that your suggestion isn't particularly good design practice.
There is already ajax being used on this page - see check_status() function.
The start / stop buttons should really get submitted as an ajax request that then updates the icons on the page onc completion rather than submitting the entire page and causing the described problem.

Secondly, the issue that the php page is at risk of a type of replay attack that is triggered when refreshing the page, that then causes multiple services to be started is less than ideal. The main php script should really take advantage of the logic contained within $_POST['check'] and use that to determine whether or not to start a new process to prevent the possibility of multiple services being started - i.e. add validation.

The code tries, as best it can within the limitations of PHP, to see if another instance is running before starting an instance. The problem is that the only way the code really has to determine if another process is running for the interface is to look for the PID file created in /var/run. Each interface has a randomly generated UUID associated with it at interface creation. That UUID is used to name the PID file, so the code can tell which interfaces have Suricata running, and be able to control them individually. However, it takes some amount of time for Suricata to start and create that PID file. If the user quickly refreshes back-to-back, there is no PID file yet from the first process, and so not seeing an existing PID, it assumes there is no existing process and thus starts a new process. Then you have two.

The Ajax section was added a few years ago to improve GUI responsiveness. It works by actually creating a new background PHP process to start the Suricata daemon. The Ajax loop then checks for the existence of the aforementioned PID file to determine whether Suricata is running or not. Prior to that, the GUI just sat there and "spun" with the web page totally unresponsive until the PHP function calls returned. That was not ideal, either.

If you have a better solution, please feel free to submit a Pull Request here: https://github.com/pfsense/FreeBSD-ports/tree/devel/security/pfSense-pkg-suricata. User contributions are welcomed.

@bmeeks
thanx, it's working fine now...