Let's start first with answering your question about the Protocol rule. That rule is coming from the set of built-in Suricata rules that are part of the base package. I forget exactly what the name of that category is at the moment, but if you look under the RULES tab at the list of categories in the drop-down selector you will find some that have "Events" in the name. Those are the built-in Suricata rules. They always get enabled by default. You can suppress that particular rule alert, or you can completely disable that rule SID. Click the red X under the GID:SID column to disable the rule, or click the plus (+) sign to add it to a Suppress List.

Now lets talk about ALERT versus DROP. All rules from the vendors (both the Snort and Emerging Threats teams) come with the rule action set to ALERT. If you want some rules to alert only and others to actually block traffic, then you need to change the ALERT action to DROP for those rules that you wish to block traffic. There are two ways to do that. And for the Snort rules, if you choose to use an IPS Policy, there is a third "sort of" way I will describe last.

The most straightforward way to change ALERT to DROP is to click on the rule action icon on the RULES tab (or you can also do this on the ALERTS tab). A modal dialog will pop up giving you the option to choose the rule action. This works fine for a few rules, but it very time-consuming for lots of rules.

So on to option #2. Use the SID MGMT tab and the features there. The dropsid option is what you want. Open up the sample file on that tab and read through it (you will see the sample files after you click the checkbox to enable SID management). The are ample comments sprinkled throughout with examples. There is also a Sticky Post at the top of this sub-forum describing how to use the SID MGMT feature here: https://forum.netgate.com/topic/128480/how-automatic-sid-management-and-user-rule-overrides-work-in-snort-and-suricata. The SID MGMT feature is a very powerful tool for managing your rules. I highly recommend taking some time to read up on it and experiment with it. A virtual machine is a great place to play with the option to see how it works.

Finally, if you are using the Snort rules with Suricata and enable an IPS Policy (on the CATEGORIES tab), then you have an option to let the IPS policy metadata embedded within the rules govern whether the action is ALERT or DROP for each rule. The Snort team embeds IPS Policy metadata in their rules (only the Snort rules, the ET rules do not have this, so ignore this for ET rules). This policy metadata associates a given rule with one of the pre-defined IPS Policies such as "Connectivity", "Balanced", etc. It also provides alternate rule actions for the various policies. There is a drop-down selector on the CATEGORIES tab (when you enable IPS Policy and have the Snort rules enabled) that lets you choose to have the package code automatically change rule actions for you from ALERT to DROP for those rules in your IPS Policy choice that the Snort team recommends be DROP.

@killmasta93 said in Recomended Categories?:

@bmeeks
Thank you so much for the reply,
so forgot to mention currently running webserver, with email server zimbra,
as for OpenAppID rules your right not worth it, normally the idea is to keep secure the ports i have exposed to the internet. As for the ET rules what setup do you have taking in consideration that you might not have webserver or email server.
And as for the snort text rules didnt really find any documentation of this

Thank you

The selections you showed in your first post match up with what I would choose from the ET set. There is actually quite a bit of duplication between the Snort and ET rules, and that just logically follows, since the threats themselves are what the rules are targeting. Thus the detection mechanisms have to be the same. Yeah, it's possible one set of rules targets some obscure threat another does not, but all the popular threats are handled by both sets of rules.

Sorry.

My example was disabled.

With this it works and I can save myself the work of activating everything.

Then I only have to look at what is newly added and disabled.

Thank you very much for your help.

@teamits said in Suricata widget only giving alerts on WAN. No LAN alerts:

@bmeeks said in Suricata widget only giving alerts on WAN. No LAN alerts:

The LAN is a much better place in almost all cases

I set up a new router for a client today. When creating a new interface it defaults to WAN...I thought of this thread. Perhaps it should default to LAN? (this was Snort but I know it's the same code in pfSense). Possibly this is tied to the interface id (mvneta0 vs mvneta1 on this SG-2100).

Yeah, that's probably something I should think about changing. That was the way it worked years ago when I inherited maintenance of the Snort package and I never changed it. That default also got copied over to Suricata when I created that package.

@trumee said in Snort, S5: Pruned 2 sessions from cache for memcap. 292 scbs remain:

Hello,

I am running the latest snort 4.1.2_2 release. I am getting a bunch of messages in the log,

Jan 2 19:34:31 snort 99033 S5: Pruned 1 sessions from cache for memcap. 389 scbs remain. memcap: 8387565/8388608 (suppressed 361 times in the last 61 seconds). Jan 2 19:33:31 snort 99033 S5: Pruned 2 sessions from cache for memcap. 743 scbs remain. memcap: 8387767/8388608 (suppressed 10 times in the last 194 seconds).

Any idea what is causing this?

Thanks

Here are some links I found with a quick Google search using the terms "snort stream pruned sessions from cache for memcap". The first link is from the Snort mailing list, and it appears to have your best answer in the third reply in that thread.

https://seclists.org/snort/2008/q2/82

https://marc.info/?l=snort-users&m=139827350314791&w=2

https://community.sophos.com/utm-firewall/f/network-protection-firewall-nat-qos-ips/40244/bug-8-201-snort-gets-memcap-errors/138536

Thank you for that.

There must be someway to make that description clearer.

After removing the check, I didn’t immediately see blocked hosts, but after restarting suricata, I now have blocked hosts.

Greatly appreciate your response.

@luke404 said in feeding pfSense traffic to IDS running on a different host:

We would like to keep our pfSense systems small and tidy and that's why I'd like to run the IDS on a different host.

Have you considered using something like sguil or security onion to collect alerts from your sensors?

@fireodo I am reading those now again... but I just figured something out... It is only when there is an update downloaded from
Snort OpenAppID Detectors
My snort was updating every 12 hours, now daily, but the update that causes the issue is the exact same time as theSnort OpenAppID Detectors MD5 Signature date/time

Discussion continues here.

@peter_apiit said in Problem download Rules in Snort:

I uninstall pfblokerng solved the problem.

That's what I suspected. When you install packages like pfBlockerNG and then subscribe and activate a bunch of feeds for it to block things from, you open yourself up to lots of potential issues. As I mentioned in other threads, those IP lists (feeds to use the pfBlockerNG term) are frequently poorly maintained by their creators. By that I mean they contain IP address subnets that house perfectly legitimate services. Like half the world probably uses Amazon Web Services (AWS) infrastructure, and thus its IP subnets, to host a service. So when some IP List or Feed you activate in pfBlockerNG does a very poor job of policing the list of IP addresses it uses and just plops an entire AWS subnet on the list without carefully and critically checking what they've done, then legitimate stuff gets blocked when it shouldn't be.

I am not a fan at all of loading up a bunch of IP address feeds and blocking everything on those lists. Not a very good way to manage your firewall in my personal opinion. Unless you are diligent and examine the lists carefully and review blocks very frequently in order to whitelist stuff, then you will get nuisance blocks often. What happened to you is a perfect example of what I'm talking about.

@darvin said in Problems downloading custom rules in Suricata:

@bmeeks
Snort has the same problem...
Edit file /usr/local/pkg/snort/snort_check_for_rule_updates.php
Modify line 476: Remplace /md5 with .md5

Both need an update fix.

Update: (Snort AppID Open Text Rules)
Edit file /usr/local/pkg/snort/snort_check_for_rule_updates.php
Modify line 451: Remplace /md5 with .md5

Okay. Thanks!

@bmeeks "created some kind of fancy shell script" I'm not smart enough for that 😁
But thanks for the suggestion.
The other potential option is to use a lookup table on the backend log server.
I am using Graylog and it has the ability to do that, so it would create a new column and populate the category based on the SID match in the lookup table.

@josef said in Snort OpenAppID log flooding:

@bmeeks Ahhh - thank you. You have helped me greatly!
This simple suppression rule has solved my problem
threshold gen_id 1, sig_id 0, type limit, track by_src, count 1, seconds 60
Now I will only get 1 log per source IP to the same application within 60 seconds.

The gui should perhaps be updated because it says "Valid keywords are 'suppress', 'event_filter' and 'rate_filter'."
But actually threashold is also a valid keyword.

Thanks!!

I will add "threshold" to the tip. I'm working on the Snort 2.9.17 update over the next few days.

Note that gen_id 1, sig_id 0 will apply that threshold to all of your general rules. Probably not an issue for you, but just wanted to make sure you realize that. GID 1 is the ID for all the rules in all the user-configurable categories. There are some specialized GID values for the built-in Snort rules like HTTP_INSPECT and others. This is all explained in the official documention when looking up GID (Generator ID). This was why I asked the Snort team to consider creating that special GID for OpenAppID so those rules could be easily distinguished from all the other general text rules. But so far that feature has not been incorporated.

@cool_corona
the problem is not suricata,
could be a temporary problem on pfsense repo
or you have no internet working ( DNS or connectivity problems )
or you have routing issue

if you still have the problem read this
https://docs.netgate.com/pfsense/en/latest/troubleshooting/upgrades.html

@kiokoman Ugh, thank you! Working now!

@idontknowmeiguess said in Snort not downloading rules (pfSense 2.4.5-RELEASE-p1 & Snort 2.9.16.1):

@bmeeks SUCCESS! Disabling DNSBL was the solution. I thought that disabling pfBlockerNG would disable DNSBL at the same time, so I never checked it, well that's egg on my face.

Thank you for your help and patience, now it's time to see why DNSBL is blocking Snort updates.

DNSBL is somewhat separate from pfBlockerNG. What pfBlockerNG does is modify the configuration files for the unbound DNS daemon and then starts it with the new configuration. It will run with that configuration until it is changed again.

I pretty much guarantee you that one of the IP lists you are using is the cause of the problem. As I mentioned, some of those lists are very poorly maintained and consequently wind up with bogus data in them (meaning perfectly safe and legitimate IP address segments get marked as "bad" when they really are not).

@justme2 said in Filter and "not dropped":

@bmeeks

Actually, was thinking: Services -> <IDS/IPS Engine> -> Alerts

The ability to remove drops while doing regular spot checking and see what triggered an alert (not a "drop") - has become more interesting.

For: Services -> <IDS/IPS Engine> -> Interfaces -> <Interface> -> Rules, a means to reduce the list via a valid action type would be most appreciated.

Thanks!

Oh, I see. It's not hard to add the feature to that page either. I'll put that on the TODO list as well.