There is, I believe, a Snort Subscriber Rules mailing list you can subscribe to. Search for it on Google. You might find an answer to your question there.

I suspect anyone can submit a rule to the Snort team for consideration and inclusion in their set of rules. And I would expect an organization such as CISA (US-CERT) to have considerable clout with the Snort rules team.

Go do some Google research on flowbits in Snort (and Suricata uses them as well). They are the mechanism that allows a sort of primitive "state engine" to be created by rules so that some additional logic can be applied,

Here is an example I have used in the past to explain what flowbit rules are all about. Suppose there is a given exploit that comes down only in PDF files. Rules would detect the exploit code by doing pattern matching on the content of packets. So when a rule saw the matching content in a packet (or several packets if the exploit payload is large), then it triggers. But a pattern is simply a collection of bits either turned on or turned off. In this example, the pattern is only malicious when it is contained within a PDF file. It would certainly be possible for other types of files to by sheer chance contain the same pattern. One possibility might be a simple GIF image. So how can the rule know what type of file is being downloaded so that it can only trigger when it detects the pattern in a PDF?

This is where flowbits come in. You have flowbit rules that sense different types of activity (PDF file download, Chat session opening, etc.). These rules then set bit flags that other rules can later examine to see what's happening. When you have rules that check certain flowbits before alerting, and those flowbit rules are not enabled, then the "checking rule" will never fire because its flowbit logic check will fail. Consider my earlier example of the PDF file download. If the flowbit that says "PDF download in progress" is not set, then my malicious payload detection rule won't fire because it will check the "PDF download" flowbit before firing. So the idea behind auto-flowbit rules is that the Snort GUI application will determine what flowbit rules are required by the active rules you have selected, and then it will make sure those flowbit rules are activated. Any rules it automatically enabled will be listed in the Auto-Flowbits category on the RULES tab.

The Snort Subscriber Rules always tag their flowbits rules with the "no-alert" keyword so that the rule fires and sets the appropriate flowbit, but it does not generate an actual alert. The Emerging Threats folks for some reason fail to do that. They do not put the "no-alert" keyword in their flowbit rules. Thus their flowbit rules will trigger actual alerts as well. That is why you are getting the block from that ET-Chat rule that is listed in the Auto-Flowbits category. Your best course of action with those ET-Chat rules that got sucked in by the auto-flowbits logic is to suppress them by GID:SID. That will prevent the actual alert and thus the block, but it won't prevent them from setting the appropriate flowbits.

@bmeeks Complicating the issue the other folks upstream is HardenedBSD 12.1.

Thank-you @bmeeks for the learning experience. Bumping the memory alloc to 128GB solved the problem.

Best regards!

What version are you running, I'm on 3.2.9.14_1 and it looks fine here.

Screenshot 2020-09-14 at 21.13.43.png

Okay, gotta setup cert. and setup MITM Transparent SSL in Squid.

I just loaded LightSquid, wow.

@1OF1000Quadrillion I would use a DMZ ... this reference will help you:
https://www.youtube.com/watch?v=QFk5jX-oeSo

So before we start, my problem was that my default $HOME_NET wasn't anywhere near broad enough, because of the configuration of my network. My network is fully NATed and includes all RFC1918 addresses, so since those RFC1918 hosts that are on non locally-attached networks are creating the traffic I want to inspect, and the default $HOME_NET is just locally attached networks, I did the following. If this isn't your problem, this won't help you, but here we go:

I went to Firewall - Aliases and made an alias called InternalIPs that contained the RFC1918's: 172.16.0.0/12, 10.0.0.0/8, 192.168.0.0/16 I went to Services - Snort - Pass Lists tab and created a new pass list , checked off all the auto-generated IP Addresses, and added my InternalIPs alias by name in the "Assigned Alias" field I then went to the Snort Interfaces Tab (under Services - Snort still) and under general settings for the relevant interface (LAN in my case), in "Home Net" under "Choose the Networks Snort Should Inspect and Whitelist" I chose the pass list I created in step 2, and also clicked "View List" and verified that all the networks I wanted to inspect traffic from were included. Save and then go back to Snort interfaces, stop and then start snort and see if stuff starts showing up.

Of course also check the normal stuff - both Sourcefire OpenAppID Detectors options checked off in Global Settings, up-to-date AppID signatures in the Updates tab, you've got the right rulesets selected in the <Interface Name> Categories tab, and you've got both options under Application ID in the <Interface name> Preprocs tab checked off.

Hope this helps!

@bmeeks said in Suricata INLINE mode ban IP after X attempt:

@Cool_Corona said in Suricata INLINE mode ban IP after X attempt:

@bmeeks said in Suricata INLINE mode ban IP after X attempt:

@Cool_Corona said in Suricata INLINE mode ban IP after X attempt:

@bmeeks

Yeah. Could it be done in INLINE mode as well??

No, keeping count of how many times a given IP has triggered a given rule is not possible in the current code for either mode of operation (inline IPS or Legacy Blocking). It just happens that Legacy Blocking sort of accomplishes that by blocking an IP completely the first time it triggers any ALERT rule.

Could that feature be ported to INLINE mode?

Could what feature be "ported"? There is no such feature available with either mode, so there is nothing to "port" to Inline Mode.

I was simply stating that because of how Legacy Mode blocking works (by stuffing the IP address from an alert into the snort2c pf table), that a single alert by an IP is sufficient to get that IP totally banned. If I make Inline IPS mode do that, then it is no longer Inline IPS mode because you could not selectively block only certain types of traffic from an IP. It would be all or nothing.

That would be really nice.

There are several third-party tools available that do things like that (including fancy charts). Check out an ELK or Grafana setup.

Here is a link to a recent thread posted by @kiokoman detailing his Grafana setup: https://forum.netgate.com/topic/156330/pfsense-firewall-and-suricata-log-to-grafana-with-logstash-worldmap-panel.

@bmeeks Thank you Bill!

I've re-read that, this time comprehensively, along with a complete read of "Taming the Beasts", truly a beast of a thread! While a lot of the material appears to be out-of-date, I definitely absorbed a lot from them and gained even more appreciation for the efforts from folks like you. I'm still a bit stunned by the sign off by @jflsakfja

Among the things I have learned, if I have these correct:

It is great to know about using a config file for disabling rules!
Notes on my TODO list: SID Management, "Enable Automatic SID State Management" Add disableSid.conf Reference disableSid.conf under Disable SID File. State order should be "Disable, Enable"

event_filter seems like it could be a good step before going full-draconian disable on a rule.
TODO: find out if these can go into a config file too.

The use of comments in disable lists is very helpful.

I may want to add some "golden rules" to ID and put a quick end to port scanners, but don't think these will be helpful until I am setting up an installation where I need to open ports and am ready to go full-monty and start blocking. Something like this I think:
drop tcp $EXTERNAL_NET any -> any !$MY_OPEN_PORTS (msg:"Golden Rule TCP"; classtype:network-scan; sid:9900001; rev:1;)
drop udp $EXTERNAL_NET any -> any !$MY_OPEN_PORTS (msg:"Golden Rule UDP"; classtype:network-scan; sid:9900002; rev:1;)

However, I am starting to wonder whether I can possibly have the time required to keep snort properly configured, as I don't support networks for a living, I develop software. I anticipate that many will say "maybe not, but then you won't have the time to deal with intrusion/malware either", and I would have to agree with that.

I have two use cases to consider:

Home/office network (protection from internal actors)
Pretty happy with all of the protection afforded by pfSense, VLAN-capable switches/APs, and pfBlockerNG-devel, but I recognize the limitations, especially with family laptops spending time connected to other networks. I love the idea of using Snort to identify and stop acquired malware.

Cloud-based web servers (protection from external actors)
Simply keeping the bad guys out and combatting DoS, I guess that's it?
(in addition of course, to keeping all software up-to-date, best practices, and all)

Certainly, I can cobble together a greatest hits collection of rules to disable, but that seems like such a leap of faith to me. Is that my best course of action? For both use cases?
thanks!
Bill

Just in case anyone else has this issue. With suricata 5, just about any "strangeness" with a certificate gets marked as "invalid certificate". One such case is a missing Subject DN, which is the case with Active Directory LDAP certificates (they use Subject Alternative Name instead). It appears that with suricata 6 this will trigger an app-layer-event:tls.certificate_invalid_subject flag (most TLS issues now have their own flag), but that there are no alerts associated with this so hopefully it will go away.

@Michael9876 said in Need help with snort block rules:

Thanks for the detailed answer @bmeeks.

So in my case as a beginner:
What should I understand by "tune" rules, what are the possibilities?

Some rules will likely need to be disabled. It is quite common for a number of the HTTP_INSPECT preprocessor rules to false-positive with today's web technology and the widespread use of HTTPS. This link contains a long thread with input from a number of experienced IDS/IPS admins. It is a great place to start learing about "tuning" your IDS/IPS --

https://forum.netgate.com/topic/50708/suricata-snort-master-sid-disablesid-conf

@bmeeks - Bill - I've been meaning to log on and say thanks for your reply. I read it a while back but I wasn't in a position (or condition) to reply. I sincerely appreciate you taking the time to reconsider my initial response. IMHO making an effort to put yourself in someone else's shoes shows strong character. Thank you.

I also owe you an apology for overreacting. Life is just straight up fucking hard right now. Presumably for everyone. Personally, in addition to the daily drama of living in a world wide pandemic, I constantly feel like I'm teetering on the edge of being in over my head with my entire network environment. I upgraded too much shit too fast.

For the record, I've since done several pfSense restores and the correct maxmind key now shows up but Suricata still won't reinstall properly. With each new restore, I'm learning a bit more and finding things I setup wrong (older snort rules, snort subscriber rules won't download, some other stuff I can't remember). Each time i find another problem, the subsequent restore gets closer to working. Ultimately I always end up having to completely uninstall and reinstall Suricata, force an update of the rules, and everything seems happy.

Suricata is a bad-ass powerful tool. Thanks for all your hard work on it. I sleep better at night knowing it's working.

@septer012 said in Suricata Logs Mgmt Not Working?:

@bmeeks I am not sure that is the case, for my problem, as all of my logs are .log, and none of them have what I would expect a log rotation filename extension to look like.

suricata_igb119463: total 2565604 -rw-r--r-- 1 root wheel 780M Aug 23 00:41 alerts.log -rw-r--r-- 1 root wheel 942M Aug 23 00:41 http.log -rw-r--r-- 1 root wheel 0B Jul 29 00:22 stats.log -rw-r--r-- 1 root wheel 3.2K Aug 22 12:23 suricata.log -rw-r--r-- 1 root wheel 783M Aug 23 00:41 tls.log suricata_ngeth036678: total 2016516 -rw-r--r-- 1 root wheel 387M Aug 23 00:41 alerts.log -rw-r--r-- 1 root wheel 943M Aug 23 00:41 http.log -rw-r--r-- 1 root wheel 0B Jul 29 00:22 stats.log -rw-r--r-- 1 root wheel 3.2K Aug 22 12:23 suricata.log -rw-r--r-- 1 root wheel 638M Aug 23 00:41 tls.log

I guess unless it doesnt create the empty file without at least one log message, than that would make alot of sense.

What kind of hardware are you running Suricata on (Intel/AMD or ARM)? And what is the version of the Suricata package that you have installed?

@bmeeks thank you Bill! I'm ashamed that I didn't already read that before posting. I had developed the idea that suppression was "rule-atomic" if you will, but now I see the light!

Working beautifully:
#(http_inspect) BARE BYTE UNICODE ENCODING
suppress gen_id 119, sig_id 4, track by_dst, ip 69.59.224.0/19

@bmeeks said in Snort and pfblockerNG-devel:

Well, without some kind of error message indicating why Snort did not restart, I can't really help you. When you have a situation like that, if Snort will not restart from the GUI, then exit to a shell prompt and run this command:

There was no error - it simply was not starting automatically as expected! Starting manually was without errors.

My first guess, and this is purely a guess since there are no error messages to confirm my suspicion, is that the pfBlockerNG-devel package update swapped out some shared library that Snort uses. That could have caused a library version conflict. Reinstalling Snort would have brought back the correct library setup. But this is just a pure guess without any supporting evidence since I don't know what error message was being printed.

This is something I thought too - thanks for confirming my thoughts!

Have a fine Weekend,
fireodo

Quick Update on this.
After monitoring logs and Discord usage these alerts are %100 Discord. It happens on my own PC also but, I do not run discord for more than a few minutes at a time usually.

Oddly enough the alerts do not appear when discord is actually in use but start to appear shortly after minimization (to systray in my wife's case).

If it were google ads or something like that I would just suppress them however, it is the online-matrix ad-server company that the alerts are being cause by and AFAIK it is STILL being listed as a malicious ad/malware server.

SO, I am keeping them get blocked - blocking the STUN server seems to have no obvious affect on Discord functionality.

Thanks a bunch guys

This quote, is from back in 2012 from an author of the third, and most recent, book in the list. The final nail in the coffin for me! I'll just stick to the snort.org documents, thanks :)

From: Joel Esler <jesler () sourcefire com>
Date: Wed, 25 Jan 2012 12:18:56 -0500
Author, and the book was outdated when it was published, and people are still buying it and I still receive a check
from it. But if I could, I'd pull the book from every shelf, because all it does is make my current job as community
manager harder. It covered Snort version 2.6 and was written during Snort 2.5, if that tells you the age of the book.
There were several chapters (including several mistakes in my own chapter) that are just plain wrong. I edited
several chapters of the book, and the changes were so heavy that they deemed I essentially rewrote them, and they
couldn't publish them as I wrote them because then the original author wouldn't get paid.

Sorry for the late reply, you were correct. I created a passlist entry and then removed the IP from the blocked table and, boom. No more issues reaching the host.

Thank you again bmeeks, you are a wizard.