The pfSense Snort AppID de-cipher sorcerer's code file with case sensitive messages: --> 1696920726080-textrules2 (1).txt
Sid range: 1000000 - 1003371

Total 3,371 AppID rules you can use with the custom option.

Use this with AppID enabled and place it as custom to use all the AppID snort snubs with custom text rules.

https://forum.netgate.com/topic/183210/guide-snort-s-appid-custom-rules-quick-guide-to-blocking-example-shows-openai-chatgpt-or-itunes

This also has tictok in it.

https://redmine.pfsense.org/issues/15035

@denis_ju Snort does not work for me past version .11 on ARM processors

@repomanz said in Snort doesn't want to start after latest upgrade to Snort 4.1.6_12:

I didn't notice there was a pfsense update before I went to latest snort.

Get in the habit of always going to the pfSense Dashboard first, let the "update check complete", and if a pfSense update is avaiable, do not update your packages before first updating pfSense- unless you specifically go and choose "Previous stable version" in the UPDATE menu. But usually if you do that, the new package version you are after will not show as new packages generally appear only for the newest pfSense release.

@Euman said in Surricata alerts NULL ip address:

@bmeeks Hi friend, .

I looked closer at this versioning:

suricata security 7.0.2_1 High Performance Network IDS, IPS and Security Monitoring engine by OISF.

Package Dependencies: suricata-7.0.2_4 
https://freshports.org/security/suricata

I copied the pkg dependencies version

7.0.2 would have been the version that left the offending line.

Thanks. If you have not seen any other instances, it may have just been some type of corruption in the file. That log is a text file processed by PHP code in the GUI to parse out the various fields. One of the fields apparently parse out incorrectly for some reason.

For now I think it can be safely ignored. If it happens again, post back to this thread and I'll investigate further.

@wolfsden3 said in SNORT: promiscuous mode disabled + promiscuous mode enabled error + exited on signal 11 (core dumped):

Hey guys / gals / they / thems, etc...

I did the 2.7.1 update on one of the boxes I had this issue with > re-enabled kill states > haven't had a problem.

Did 2.7.1 resolve this SNORT issue is some magical way? I think SNORT is the same version but I didn't confirm this.

Many Thanks!

As @SteveITS mentioned in his response with this link:

https://forum.netgate.com/topic/184112/important-snort-and-suricata-package-announcement-probable-bug-in-legacy-blocking-module/

There is a thread where I am posting updates. I will put them in the original post at the top of that thread.

@fernoliv said in I can't start Suricata 7.0.0.2 on Pfsense + 23.09:

Thanks @bmeeks but in my case, even with the "kill states" option unticked/unchecked Suricata still not starting and still running.

The kernel process is return on the System Logs the message below:

(suricata), jid 0, uid 0: exited on signal 6 (core dumped)

I'm going to wait for the fix be turned available via pfSense repositores (patches or a new 23.09.1 release) to overcome that issue.

Signal 6 is an entirely different error. That means Suricata is missing some critical dependency or something vital is not initializing.

What kind of hardware do you have? Is it Intel AMD64 or ARM based?

Remove the packge, reboot the firewall, then try installing the package again.

@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!