@code4food23 said in Puzzled about the number of Suricata instances needed for LAN and VLANs due to device showing up on both alert logs: Also sorry for the dumb question, but the IPs help see which device made the traffic to trigger the alert right? Hello, Forgive me (pls.) for butting into the conversation here, but Bill is absolutely right that the management of IDS/IPS systems is a challenge for many well trained administrators too. To run them in your home, I don't think it's absolutely necessary.... pfSense basically drops all unwanted traffic on the WAN interface +++++ if you use a well configured pfBlockerNG you are safe, this can be said. The Suricata, Snort can cause a lot of headaches, if you are not skilled enough to handle them, I would start with a VM install and practice before deploying it on my system. You can also get away with a lot of the abuse your family sends you when the internet isn't working in your home. (and it can limit a lot of other things in the background if it's set up wrong, which you haven't even discovered yet, FTP, SFTP, Torrent, P2P other, streams, etc.) BTW: The physical interface is the "igb_" interface (Intel PHY) that physically connect to the port (RJ45) on your pfSense box, those IDS/IPS systems listen to the traffic on the physical interface, so if you create virtual things (VLAN) on that interface, their traffic will pass through it, but as written the VLAN handling is not really functional at the moment (because of the tags) ++++edit: Don't get me wrong, I'm not trying to dissuade you and welcome to the team, but at least run it in alert mode first to avoid a lot of unwanted problems.

@bmeeks Thanks for the reply, i believe i have vtnet but in theory its pointless to try it out because the VLAN i need to block social network would also block on my LAN

@bmeeks Thank you for looking at this. I appreciate it. The Realtek's have been squirrelly. But I have not been able to find a solution to my lack of expansion ports and no intel usb3 nics.

@bmeeks Interesting I'm indeed running it on a vlan trunk, NUC only has one port.

@eveningstarnm Thanks a lot for your feedback!

@eveningstarnm said in suricata versus the latest version of snort: connect your test machine to a consumer Xfinity (Comcast) internet connection Yup Yes you are right it is America over there, although nowadays the invasive presence is increasing everywhere. The idea is good :) - (Xfinity + Comcast ISP) What I'd rather push is that it's not enough to just increase the number of unwanted events, you also need to increase the traffic (PPS) to see how the processing processor behaves on say a 40 - 100 Gig - f.e.: Netflix network BTW: although if I am correct - Netflix also uses a lot of FreeBSD stuff, because of the high traffic and of course the "pf" benefits

about a day or so after I raised this, the issue was addressed and successfully fixed. I haven't had an issue since. it all works great

@bmeeks You are probably right, wireguard is the last package to start... So I will import the aliases and see what happens.

@bmeeks Thanks for the quick response, I'll just wait for the patch to be processed internally then.

@cool_corona said in PID Error on starting INline IPS latest Suricata update: @bmeeks Hi Bill Neither is there in the system logs. No crashes related to Suricata. The only possible way a PID file for a Suricata instance can exist in /var/run is if a running Suricata process created it. The only way it can exist when attempting to start that same Suricata instance is if the previous running instance failed to delete it at shutdown due to a crash. The Suricata binary itself creates and deletes that file as part of its startup and orderly shutdown process. So the only way for the file to persist, if Suricata is not running on that interface, is for the Suricata process that originally created it to have crashed. That crash should show in the pfSense system log unless your log maybe got rotated out. If this was a one-time occurrence, then don't sweat it.

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.