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

@jpgpi250 said in Newly Registered Domain Threat Intel Feeds for Suricata:

@bmeeks

I'm looking at this youtube, about datasets. on 21:58, the dataset source is added. I've been looking at the pgfsense/suricata interface, but can't find where a dataset file (source) is added.

I assume this is possible, just need to know where...

thanks

suricata version is 6.0.13 on pfsense 2.7.0-RELEASE (amd64)

Currently dataset source files are not supported within the GUI. Datasets are a relatively new feature in Suricata and support for them has not been added to the GUI.

When I first saw your post and quickly reviewed the link you provided, I assumed it was regular text rules.

@Euman said in suricata (core dumped) after GeoLite2-Country database update:

I think this is the issue and am waiting for results:

I had "Live Swap" enabled

Enable "Live Swap" reload of rules after downloading an update. Default is Not Checked When enabled, Suricata will perform a live load of the new rules following an update instead of a hard restart. If issues are encountered with live load, uncheck this option to perform a hard restart of all Suricata instances following an update.

While everything is possible, I'm not sure how this setting would contribute to a Signal 10 Bus Error. Maybe there is an outside change the extra RAM use when this feature is enabled causes the use of a particularly problematic physical chip address ???

@bmeeks

Thanks for the clarification. I'm guessing something happened during the unusual (I'm calling it that since it's not standard Linux behaviour to uninstall and reinstall in order to update a package) process. Knowing that and ensuring I have a config backup before any package update I'm not too worried.

Lots to learn (and unlearn) as always getting into a new system. Really appreciate the help from the forum.

@bmeeks Thanks Bill. Ill reach out to them on their forum and on Twitter.

@bmeeks I agree I actually reported this IP and the .31 to IC3 because of this blanket type HID door discovery enumeration within my IP blocks. That attack one is new to me. I admit I do like to watch the WAN as you can monitor what's going on very well with the IPS/IDS. Again it takes some time to get it useable so you can see and have it no disable your internet access as you have seen with my many reports :)