@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

@pfsjap said in Snort Subscriber rule in suricata: @bmeeks Do you recommend those tweaks in the Sticky Post also for igc? I don't know. I did not create that post - another user contributed the information there. Different NICs of course can have different customizable settings. You will need to research the particular flavor of igc chip your NIC has to see what might apply. There are families of NIC controller chips that all can use the same generic FreeBSD driver, and each variant in the family might have its own unique settings that another vendor's igc NIC does not share.

@bmeeks thank you again. Appreciate the response and detailed explanation

@bmeeks Dear bmeeks, thank you for this info. I will wait for the update. Greetings, Arti.

See my reply in this thread (to a similar post of yours): https://forum.netgate.com/topic/183539/suricata-alerts-logs-view-broken-due-to-advanced-configuration-pass-through/6.

@michmoor said in Suricata Alerts/Logs View broken due to Advanced Configuration Pass-Through: @cyberconsultants I wonder if this is related to my other forum post i put up today. I got no logging for a rule. I know its working but nothing is in the alerts tab. There was a bug report upstream in Suricata some time back about certain circumstances where the logic would drop a packet but not log the reason (alert). I was thinking that was addressed, but maybe it was not fully fixed ??? It's also possible that a rule may have a noalert tag in it. That suppresses alerts. Not sure how that impacts a DROP action, but I would expect such a rule to also not drop the traffic. I have never tested that, though. The noalert tag is part of the flowbits logic for rules, and allows a given rule to trigger a flowbit state without generating a corresponding alert for that trigger. If you are using SID MGMT to change all the rules in a given category to DROP, then perhaps you are also changing some flowbits noalert rules to DROP when typically they are set for ALERT. Just a guess as I have not investigated this, but perhaps that results in an unanticipated situation in the Suricata binary.