Which IDS IPS rules do you prefer

[bimbar]

I basically agree with Patrick, but if you want to do it, there are rules I would activate without too much problems - for example the abuse.ch rules. You should definitely not activate all the rules.

[jonny5]

One - IDS > IPS - mainly because detection is inherently fault prone, blocking needed traffic means issues

Two - Enabling IDS rules via Policies in OPNSense's Policy management is okay

Three - Suricata has its own rule management detail that is already and installed and can be switched to
Switching to Suricata-Update from OPNSense's Policy Based IDS/IPS Rule Management - Using Suricata-Update on OPNSense
Also created a Github repo for Suricata-Update Config Files to give some actual SIDs/Regex that I use in my suricata-update runs - note - this repo has an update that I'm still finalizing, ah the to-do lists. The update isn't too major, just more disable, possibly one or two enable items and some modify rules that fix rule text issues I've found.

Four - There are likely bots/script-kiddies and zero if any VERY Unlikely APTs that are interacting with your IP. Blocking the script kiddies/inventory-the-internet traffic 'could' lighten the network load.

Five - Doing this without some level of data lake is not for the faint of heart, and data lakes aren't necessarily easy either but can work for focused searches / pattern checking. Graylog/Elastic/etc. can all be great places to send your syslogs (firewall/system/suricata) so you know about what's going on and if a rule modification is going to focus your IDS/environment more.

Six - This is really useful if you are actually hosting services, if there isn't anything being port forwarded into your network, then your IDS events will be few if any and mostly generated by your users. Most of the local user traffic based rules are extremely fault prone and of honestly little use. Enabling any Nginx/Apache/PHP/Wordpress/MySQL/Mariadb rules if you have a web host is easily a good idea.

Seven - The completeness number, neat. Encryption is a thing, and SSL/TLS/Encrypted traffic is of little use for IDS inspection, it won't be able to 'read' any other otherwise protocol/app level text/packet detail. If you are terminating the TLS for your hosted services using your Reverse Proxy in some DMZ zone and one or more Web Hosts in some Core zone, and have the proper setup (Reverse Proxy/Web Host/IDS) with XFF and as mentioned the back end services which must be set apart in a different interface/subnet/zone of your OPNSense, now you can read attacks inbound to your otherwise secure hosted Web Site(s) as the IDS can actually see it in the 'decrypted' traffic between the Reverse Proxy and the Web Host and inspect it. Your users' outbound/browsing activity is the hardest one to access, and requires you setup an internal CA PKI and install the Certs on your devices and setup it upon the Suricata... and it will eat your CPU alive I bet. Haven't done it, yet, might not ever lol.

If you are filtering/securing DNS, having IDS notice what is actually unwanted, have a Reverse Proxy in the mix, and using another OPNSense plug-in called CrowdSec, you can inspect your firewall logs and the Suricata logs to detect threats, and it will block them if they reach a threshold and then you can actually provide some level of 'corporate level network protection' for your network (Lite-NG-Firewall/Responsive-IDS/WAF/DNS-Filtering). It can turn a Reverse Proxy into a reactive WAF of sorts, impressive stuff. The CrowdSec block can work for all of your integrated Multi-Server setup (Agents - Parsers/Blockers/Appsec) and everyone else that uses CrowdSec depending on how you set it up (stay an island / share w/community).

CrowdSec can be a task to install, especially if you start growing it to be a Multi-Server setup but to say it is easily a catalyst to change the otherwise 'only logged' activity from your IDS into responsive action would be an understatement. Similar to Fail2ban or AbuseIPDB, but quite a bit more.

If you are sending data to them, you get larger access to their Community blocklist, mine is sitting at about 40k known threat IPs (HTTP/SSH/bots/etc.).
About that setup: CrowdSec Multi-Server with OPNSense Router

Lastly, I did write up how to enable mostly useful rules in OPNSense's Policy Management UI - but would earnestly recommend learning about suricata-update and familiarizing yourself enough with FreeBSD and where the folders are to 'switch over' to doing it with Suricata's native tool.