@bmeeks Thank you. Excellent suggestions. My head was too much in a GUI mode. Never would have thought of a regexe. I'll stretch my Google-Fu and see if I can come up with a nice one-liner. Cheers.

@Ramosel said in Snort Update Procedure: @bmeeks said in Snort Update Procedure: And "yes", I retired back in February of 2014. I worked as a contractor in a "work from home" job starting in 2015 for about 2 years, but then retired for good at the end of 2017. Just enjoying life now as an official "Old Fart" . But I have not gotten to the "you kids get off my lawn" stage yet. Well, ya got some catching up to do... you'll get there... especially with the crap going on these days. I do reserve my right to complain about "the crap these days", even if I'm not all the way to "you kids get off my lawn". Oh, and both my wife and I like to complain about how much stuff costs now compared to "the good old days".

@PalisadesTahoe said in After upgrade to pf+ 23.09 Surricata says it's starting but..: Noticed this morning that Suricata 7.0.2 was now available in the packages repository. I've upgraded and switched one of my LANs back to using Hyperscan. Although it seemed to run an little bit longer before crashing, it did eventually do so with the same error: "Hyperscan returned fatal error". Not sure if we were expecting Hyperscan to also be updated, but it is still at 5.4.0, which is odd since 5.4.2 has been out since 2023-04-19. No, no change in the HyperScan library yet. I need to first see if I can reproduce the problem. The upstream Suricata team says 5.4.0 should be okay, but that definitely 5.4.1 is broken for Suricata. The fact 5.4.0 suddenly is giving issues is puzzling to the upstream guys, too. And just to keep things clear-- there are currently two reported issues with Suricata, and they are NOT related. One is the issue with a Signal 11 fault when Legacy Blocking Mode is enabled with the Kill States option checked. That bug has been hopefully identified and fixed. Some new binaries will appear soon reflecting that fix. I believe some posts in this thread are actually a result of that bug and not necessarily the HyperScan one. The second bug appears to revolve around the Intel HyperScan library. That one is now under investigation. I initially thought 7.0.2 would take care of that, but it apparently has not. So, now I will see about replicating the issue so a fix can be identified for it. This one may take longer to find and fix, and so is likely not to be part of the upcoming package update correcting the Signal 11 fault.

@JonathanLee said in Snort and Paid Rule Subscriptions: @mcury I am going to get one to test items with soon. I have the 4B it even has 64 bit options. I have a raspberry pi 3b, it has only 1GB of RAM, so it is constantly running on swap. It is running a samba-ad-dc, freeradius, apache2 server with php and ssl, and a unifi controller, it is too much for it hehe I also have a raspberry pi 4 with 4GB that I'm using for Graylog server, but unfortunately Graylog loves RAM and 4GB is not enough. So my plan is to move Graylog server to Raspberry Pi 5 8GB, move everything that is running in the raspberry pi3 to raspberry pi 4 and then install KVM in the raspberry pi 3b. I'll use KVM to manage my computer through tailscale, I'll be able to turn it off, choose what OS I'll boot, boot to Linux or Windows as I desire..

I think I may have found the bug. If I am correct, it's actually in the FreeBSD libpfctl library and not directly in the Snort code. I'm waiting on the Netgate kernel developer I'm working with to either confirm my finding or show me where I went off track .

@ronv42 said in After update to 23.09 revewing log files in Suricata produces a PHP memory allocation error: @bmeeks Thanks I am exploring that directory right now. If I delete the logs there would that cause any issues? No, deleting files there is not a problem with one caveat. If you delete a current file (meaning one of the files without a UNIX timestamp appended), then the currently running Suricata instance on that interface may cease logging until it is restarted or the proper SIGHUP is issued to signal it to re-initialize the log files it was using. Rotated files will have a UNIX timestamp appended to their filename. "Active" files will not have a timestamp appended.

@Gblenn said in SURICATA QUIC failed decrypt - filling my logs: @bmeeks Yes that makes sense of course. And that made med realize that 8.8.8.8 is also in the default pass list so that's probably why my other attempt, bypassing pfsense resolver, were not blocked either... Tried a different DNS server and now it shows up in the block list. AND, I suppose I also managed to show the drawback of legacy mode, with "package leakeage". First attempt, I do get a response back: nslookup something.onion Server: dns.sse.cisco.com Address: 208.67.222.222 *** dns.sse.cisco.com can't find something.onion: Non-existent domain Second attempt, fails - blocked: nslookup something.onion DNS request timed out. timeout was 2 seconds. Server: UnKnown Address: 208.67.222.222 Yep. The number one drawback of that mode of operation. At least the first packet (and usually several in the flow) get past before the IDS/IPS has enough data to issue a verdict on the traffic. Inline IPS Mode does not have that problem. Nothing is passed on from the NIC until the IDS/IPS has finished analzying and come to a verdict on the flow.

@bmeeks Upgrade done lazily, with no issues whatsoever. Literally the smoothest pfSense upgrade I have ever done.

@bmeeks Thank you for being on top of things and getting a fix out so quickly. Your good work doesn't go unnoticed.

@johnpoz said in Too many alerts: "ET SCAN Potential SSH Scan OUTBOUND": @denis_ju said in Too many alerts: "ET SCAN Potential SSH Scan OUTBOUND": I don't understand why ntopng causes so many alerts! Because you have discovery enabled - its trying to discover, so you yeah going to create traffic like that. You are right! This is the solution! Thank you! Not sure how you have ntop setup - but it shouldn't be doing discover to externals.. https://forum.netgate.com/topic/173693/suspicious-traffic Specific post with links to other posts https://forum.netgate.com/post/1055688 Does nobody search before they post? I'll read it carefully! Thank you!

@bmeeks I was afraid you were going to say that... It is in fact 50 plus different lists so I was hoping for something smoother... Perhaps I can find the complete list, with all of them so that I can just cut and paste... [EDIT] The list is of course in the LAN Categories tab, and can easily be used for copy paste into the SID Mgmt files

This issue is corrected in a forthcoming package update. I've posted a Pull Request for review and merging by the Netgate developer team here: https://github.com/pfsense/FreeBSD-ports/pull/1313. Look for a new 7.0.2 package version to appear soon.

@michmoor said in Suricata 7.0.0 Package Update for DEVEL Snapshots -- Release Notes: @bmeeks said in Suricata 7.0.0 Package Update for DEVEL Snapshots -- Release Notes: I'm not sure many users of some popular pfSense packages realize many of the packages are created and maintained by volunteers not associated with Netgate in any way. If the volunteer maintainer of a package leaves, that package dies on the vine unless Netgate devotes their time and resources to take over its maintenance. Obviously there are limits to how much Netgate can pour into "free packages" and still maintain rigorous development and support of core pfSense itself. Word to the wise -- never run a business-critical component on free volunteer maintained software that could disappear on you at any time . If you can also maintain said software yourself should the maintainer disappear, then that changes the equation. And this is the exact reason why i caution anyone running pfsense to keep package use to a bare minium or to none at all. The core pf project has developers on payroll so you know there will always be support there. Everything else is at the mercy of a 3rd party. For those who follow my other posts, this is why i am instructing people to stop using Squid. There is no maintainer for it at the moment. Redmines are open but no one is touching it because by all accounts there is no volunteer. The SquidGuard project is another one. I reached out to the dev (whos name is in the package) and he responded nicely saying he hasnt been involved in that for years. Thats just 2x packages i listed that by all accounts are not being maintained by anyone. I see your reasoning, but then why publish this: https://www.netgate.com/blog/suricata-vs-snort and state: "...The good news is that regardless of which solution you choose, it will be compatible with pfSense Plus software..." if you don't offer the proper support to the maintainer? Just wanted to understand what are the plans going forward with this package. If @bmeeks is hindered to build or maintain the package I wonder what will happen to pfblockerNG and other packages...Why this approach ?

Hi bmeeks ! Yep, my snort is running in Legacy mode. Noted for the alerts content, my settings "Remove Blocked Hosts Interval" is at 4 days but might be a good idea to set 1 hours like you mentioned. I have disabled the ET INFO and ET POLICY rules and so far it looks to be working. Let's see in the coming weeks. Thanks again for your responses, it helped a lot :)

You guys are amazing. Snort is an amazing tool. Remember Airsnort from the late 90s?

@pfsjap said in Suricata v7: @bmeeks Thanks, had it still been Suricata v6, I would have waited for 23.09 release, but now I'll try the RC. Suricata version in 23.05.1 has a problem with Run Mode. If I set Run Mode to Workers for both of the LAN interfaces configured, then one of them keeps logging "SURICATA STREAM pkt seen on wrong thread". Setting only one interface to Workers is ok. This is a recurring issue that has existed through several Suricata major versions. The upstream team has worked on several fixes, but so far as I can tell they have not been able to fully eliminate the issue. I think one reason for that is that the root cause has not firmly identified. There are theories, but apparently none are 100% correct as all the fixes based on the theories have not proven 100% effective. Workers Mode aligns the threading engine differently than AutoFP Mode. In Workers a given thread handles a packet from acquisition through decoding/detection and then to verdict (alert, drop, pass, etc.). In AutoFP Mode packet acquisition and processing are separated. There is a queue of threads for acquiring packets and handing them off to a separate queue of threads for the decode/detect/verdict processing.

Thank you for your patience and understanding Bill. Your efforts are greatly appreciated

Thank you! This explains it