Messages

Understood, but no I am not "asking us to do away with security measures". It is the original (and hails from the pulled-pork/oinkmaster days with Snort if you have used IDS that long) way.

You do not have to use it, OPNSense has designed their own way to enable/disable rules and the policy system works. It does not let you 'edit' the rules - and yes, if you know what you are doing, you can increase your security with a few useful rule edits.

Here's a git repo I made with some 'suricata-update' config examples to help people get started.
https://github.com/j0nny55555/noiseless-suricata-update

The 'suricata-update' method is the way that ships with Suricata by default (and is already present on the OPNSense, it gets installed w/suricata) but OPNSense does not use it. IMHO, the GUI that should be made for the OPNSense should use 'suricata-update' in the background and then we can disable/enable/modify/drop rules very quickly as it works quite fast.

If you are like me and have an aging box running your OPNSense, the 'suricata-update' method will put a decent tax on the system resources... so now I have a docker container run the same suricata version on my OPNSense and build my rules file that I have the OPNSense download. It is pretty clever, fast, and resource light on the router as another beefy box does all the rule building heavy lifting (regex mods can get heavy on 200k+ rules).

Please read this - the way everyone else does it with Suricata is 'suricata-update', so, to do 'suricata-update' on OPNSense you will have to change some things...

https://www.nova-labs.net/using-suricata-update-on-opnsense/

Thank you for the note about RSS in older hosts (desktop hand me downs), can confirm. Getting good throughput even after disabling RSS and getting a huge power cost save in the process. Didn't realize RSS added that much load to an older CPU.

Edit: to any others with older CPU hand me down hosts, if you have over 1 Gbps fiber, you will likely need to enable RSS to get the speed/throughput you are paying for. It will cost you a little more in watts, but, you have to make the choice if you want to "get the rest of it".

Also, want to mention that CrowdSec is not an IPS. It can parse a Suricata fast or json log, but that does not make it an IDS/IPS.

CrowdSec is much more like a modular Fail2Ban and when it reads a log entry that matches an attack pattern (CrowdSec's acquis.d folder and its conf files), can add that IP (IPv4 or IPv6) to a blocklist locally, and/or escalate it to CrowdSec for the 'hive' the be protected too. You setup the agents/parsers/blockers/etc. (a server is also a good idea for a Multi-Server install) and it will read which ever log files are about services it recognizes or you configure manually.

Agree with you about "don't drink the koolaid", but I will say security is only best in layers (and when monitored and followed up on, a SOC), and one should not think it will be easy to accomplish or be something that is in any way turn-key. If you are interested in a project and in the Computer/Network security career space, might be a good project to maintain. Exercise if you see it worth while.

One of the best/easiest ways to actually protect yourself is to use blocklists from reputable providers, which fundamentally, you are doing with CrowdSec - the only difference is you can be a part of the 'blocklist provider'. Again, not easy (and not a sure fix), but do able and IMHO not a bad idea (and something that will not break things if setup correctly).

IMHO, IDS good, IPS not so good.

Planning on coming back and reading the rest of your post because, wow, quite the valuable "check here first" list of things to know as you get into running an OPNSense. Thank you again!

Installed 8.0.1 - works in IDS (OPNsense 25.7.5-amd64 - we do not IPS)

Use the logging and have modded things to use 'suricata-update' instead of the Policy rule management OPNSense feature

All of which still works great! Seems there was minimal 'suricata.yaml' file modifications too, will follow up here after combing through the latest published Suricata config file example

It should be mentioned (and this might be more in plugin or core - looking for help/direction):
It has been difficult to keep a 'custom.yaml' file, which can allow us to customize the Suricata config even more
We significantly use this, and as we've disabled the OPNSense IDS update cron task our 'custom.yaml' file at /usr/local/etc/suricata/ does not get replaced any more. It would be neat to either now, or in the future see about having a way to have a heavily customized 'custom.yaml' for Suricata that stays around natively (currently if we modify the template it breaks on copy/import).

Extra - the suricata-update thing:
https://www.nova-labs.net/using-suricata-update-on-opnsense/

As the CrowdSec default firewall is only stopping incoming for items on the list, I wanted to upgrade how that feature worked, and honestly allow a few hosts I have to not be blocked by the firewall - an unfiltered host if you will.

So, I made my own "Hosts" based Firewall Alias, and have a Python script that will get the latest list and put it in there.

This took a little bit usually, and so I tried to see if I could thread the operation to increase speed, I might try to multi-process it next as the dual sends is about the fastest send (two sub lists, each about 30,000 items) and if there is a change I just update the whole sublist that changed and do a reconfigure.

Still, this takes too long as 10 seconds. The other kinds of aliases are interesting to me, such as Internal and External.

It would seem (and I did this too... but didn't understand how to 'reconfigure' or set the updates as active) that you can do it faster via pfctl via python, but, how do you reconfigure after updating a "Hosts" based Alias? Do the Internal or External Alias types not need a 'reconfigure' to have their populations be active in the rules that use them?

I'm fairly new to pf/FreeBSD so please do not take for granted anything I might 'should' or 'could' know, teach me!

Issue:
Last two updates, on restart, WAN has IPv6 address but no IPv4 address

Further:
The solve is easy, I just go to WAN interface and hit 'Save' at the bottom, it applies, and then I have an IPv4 address on WAN followed by a little later the IPv6 address shows up again on WAN. LAN interfaces have their IPv6 (and IPv4) details, but the missing IPv4 on WAN is initially keeping a few things from working after the update.

I will be able to do more testing later as far as the reboot w/out an update, but I do not have that change management window right now.

While I do not know much about OSPF, I have looked up a lot of tuning elements for OPNSense and FreeBSD as mine runs on older metal host and I'm doing 10G intranet.

https://calomel.org/freebsd_network_tuning.html

This website ^ has details about many tuning elements, but they use a different reference of values for kern.ipc.maxsockbuf and so while I do not think there is a limitation/drawback to increasing the value (much the opposite it seems), using a logical value seems wise.

For my router, I have the value set at: 614400000

Seems yours is already working, but who knows if there is odd grouping/read/writes to that space due to a unqiue value - that said, how this values comes to be seems pretty odd to me, and so I didn't do all the work necessary to evaluate your "33554432" - just wanted to share a resource I found that has helped lower buffer bloat and latency.

The specific part from their website that seems important:
# speed:   1 Gbit   maxsockbuf:   2MB   wscale:  6   in-flight:  2^6*65KB =    4MB (default)
# speed:   2 Gbit   maxsockbuf:   4MB   wscale:  7   in-flight:  2^7*65KB =    8MB
# speed:  10 Gbit   maxsockbuf:  16MB   wscale:  9   in-flight:  2^9*65KB =   32MB
# speed:  40 Gbit   maxsockbuf: 150MB   wscale: 12   in-flight: 2^12*65KB =  260MB
# speed: 100 Gbit   maxsockbuf: 600MB   wscale: 14   in-flight: 2^14*65KB = 1064MB
#
#kern.ipc.maxsockbuf=2097152    # (wscale  6 ; default)
#kern.ipc.maxsockbuf=4194304    # (wscale  7)
kern.ipc.maxsockbuf=16777216   # (wscale  9)
#kern.ipc.maxsockbuf=157286400  # (wscale 12)
#kern.ipc.maxsockbuf=614400000   # (wscale 14)

External hosts includes internal IPs, Internal hosts includes external IPs

I'm only in detection for 3 LAN Interfaces, I do have RSS enabled (it suggests I disable it... but it has been around for years now and certainly appears to work for everything else including Suricata)

The "Traffic Graph (Throughput)" Dashboard that shows activity, only shows activity for Upload, not Download (even if I speed test Up/Down, just shows Upload)

Any ideas, I'm completely new to Zenarmor and have a free account but have it integrated to their Cloud too?

That said, I have had a few detections for hosts going to odd FQDNs, not bad!

There's a patch:

Code Select Expand

opnsense-patch -c plugins a80156815
should've read the posts before posting... thank you everyone and Franco!!!

I have several WOL hosts on my network, and I can trigger them to turn on, that works.

What does not work is the 'active status' on the WOL Plug-in Dashboard on the OPNSense. Further, it seems you have to 'wake all' now from the Wake On LAN plug-in menu... it seems you cannot select a specific device to wake up when in the plug-ins menu?

As the CrowdSec Parser Agent that is installed will parse what it is told to from the `/usr/local/etc/crowdsec/acquis.d/*.yaml` and `/usr/local/etc/crowdsec/acquis.yaml` on the OPNSense, it is more about the detail there, and the Allowlists and other pre and post processing you configure.

That all said, by default the plug-in's CrowdSec Agent Parser will parse the firewall/pf logs. You can have it parse more, such as Suricata, and in this case it would be up to you to configure Suricata to only look at WAN or to have CrowdSec collect the logs and apply that filter logic in the acquis details and follow-up pre/post processing configs respectively.

The OPNSense CrowdSec plug-in also includes a Blocker Agent, it will listen to your LAPI (the Server side of your local CrowdSec plug-in) and update the WAN only blocklist the is configured as a part of the plug-in installation. This already meets your needs from what I understand.

!! Major extra / might not be on your focus !!:

You can do more to modify and retain your modification for the CrowdSec plug-in btw...

From using an external LAPI, to not using the Blocker Agent (keeping only the Parser Agent active on the OPNSense)

Then, making your own Alias and Firewall rules to use the CrowdSec list where and how you want

I have not published my how to on how to do this, as, it isn't really as good as I'd like it to be (it works but on a 10 second scale of update, and updates/refresh to the Alias active content, has took 7 seconds in the past) so once I learn how to update the data in the PF alias list on the back end of OPNSense... I'll post a blog entry on doing more with the CrowdSec feature. Likely I just need to look more into doing a manual install of CrowdSec's FreeBSD blocker on an OPNSense.

For your KEA DHCP, you are using IPv4 and IPv6?

Could you share if you are using DHCP Leases to track hostnames, or registering your hostnames in BIND or elsewhere?

I run my own BIND for my localdomain and I keep it tracking IPv4 and IPv6, but I'm a little strapped into ISC data/OPNSense API data, so without an extra box to test feature state transition I've been just waiting to see how it works for others first (KEA is still kinda new).

Thank you for any feedback, it is appreciated!!

Upgraded, all good

• Zenarmor(observer only mode)
• Suricata(modded)
• Crowdsec(modded)
• Wireguard
• Unbound
• ISC DHCP
• IPv4&IPv6 enabled for many zones

Huge thank you to all developers/maintainers/testers!! <3

In my experience, the script/cron-job that runs the OPNSense rule update via policy replaces several key files in the /usr/local/etc/suricata folder, and I believe threshold.conf is one of them

At the very least, when you do a rule build generally it is supposed to create or update that file from what I've learned with 'suricata-update' (the slightly more natural way to update rules). Will say, I feel like I only know the shallow end of the pool here, so, what actually happens and what is supposed to happen with threshold.conf is a bit unknown to me.

If you are wanting to get into more customization of Suricata and possibly use the natural stack of suricata to do things, possibly including using 'suricata-update' to make your rules files and such then please check out a blog post I made.

Using Suricata-Update on OPNSense

Follow this guide will have you turn off OPNSense's policy based rule update process and in this, you will get full control over the threshold.conf file. As already mentioned, how it gets created, and how it persists within the natural suricata/suricata-update space is still something I'm exploring.

If you didn't figure it out, this might help

You can create your own rules file, put namedfile.rules in /usr/local/etc/suricata/

You might add a rule like:

Code Select Expand

pass ip 10.10.10.2 any -> 10.10.10.3 any (msg:"Rule for Bypass Example 01"; bypass; sid:1000001; rev:1;)
If you edit the "installed_rules.yaml" file in the /usr/local/etc/suricata/ folder you can add your rules file to the list of "rule-files:"

There are other methods to do this, I believe you can using the GUI also setup bypass rules for hosts.