Messages

Just saw it show up!! <3

> Overall curious about the decision and if OPNSense is compiling their own Suricata

I'm rather curious what the actual question is here. Someone has to provide binary packages so it needs to be built? oO
...

After having made my initial post there, I realized I have more to learn/explore before I can ask such a question really. While I have compiled my own Suricata on Debian, I have not on FreeBSD.

I'm after customizing the downloaded rules in greater context, it will still be SID by SID, but, ideally using Suicata-Update or something like the old "pulledpork" or "oinkmaster" that Snort had we would be able to have a conf file that SID by SID has modifications to apply after getting the new rule file (post update, it re-set the changes if the source detail to fix is still there).

How can I post rule update have specific rules modified (sed/awk - ish but through a pattern tool like Suricata-Update (gotta explore this - still learning) or something like it) "$ANY" to "$EXTERNAL" or "$INTERNAL"?

So, in addition to being curious about PF_RING or AF-PACKET, because memory rings tend to run fastest, and wanting to tune impact to an aging process IDS, wanted to go after that tuning of the IDS and the rules being enabled. Use to manage Snort IDS hosts for an MSP of sorts in the past, day job is a little different now, but my hobby and passion remain.

In a effort to gain awareness of my own network, current state of rules, I went after enabling almost all rules recently and wrote up a guide to getting a great many rules but turning off some of the most noisy/troublesome.
https://www.nova-labs.net/opnsense-and-enabling-suricata-rules/

I plan on posting about my future Suritcata-Update explorations in about another 3 to 4 weeks or so (I hope lol!)

As somebody that also does this, I've noticed it is strongly advised to use /24 subnets, reverse DNS w/less than a /24 requires very very custom/unique reverse DNS stanzas.

Outside of this... I've made sure to use "$ORIGIN" more and my external BIND doesn't seem to favor it, as well as making sure I only put "PTR" not "PTR IN" for the reverse, again BIND seems to favor the PTR IN, and OPNSense DHCP seems to favor the PTR.

You are doing AD/DC BIND? Not doing this myself, so, not sure how that would change the 'dance' if you will. Best of luck!!

Looking to enable additional Suricata IDS Rules / SIDs? Just wrote a how-to w/screenshots, here we go!

TLDR;
https://www.nova-labs.net/opnsense-and-enabling-suricata-rules/

The how-to is a bit long, but outlined are three policy rules that once enabled allow a much wider/deeper view of the network traffic being inspected.

This will raise your CPU utilization, and if you do not add the third Policy, and disable a select few SIDs, can cause quite a bit of event/alert explosion as a few of the DNS/TLS/SNI rules fire each DNS resolution/TLS connection.

The guide starts by broadly enabling (first 2 policies), and then disabling (third policy) whole matching groups of rules based on the SID/rule meta. Thank you OPNSense, realized the population of each meta and then was able to focus on what to use to enable with minimal Policies.

Last section in the guide is where you will be individually disabling 20+ rules/SIDs which should not negatively impact your OPNSense router, we are keeping the individual rule mods in low populations.

Here's a first step before you even read the whole guide (you will likely want to have your OPNSense with a working internet connection to get through this guide and be able to get this initial step out of the way):


Please feel free to suggest modifications, or share your experience here.
Looking to learn more, but share what's being explored!

Have not attempted to use the new KEA

Have used ISC to do static reservations, and enable the Dynamic DNS feature to external BIND (Primary & Secondary), and finally just got all of the /24 subnetting squared away necessary for the Reverse DNS portion of the protocol to do its thing (/24s for each zone). All subnets populating, no syslog errors for DHCP registrations (also cleared up my pools - the static assigned used / dynamic pool space)!

This is to comment excitement for the new feature, I've been interested in using an IPAM, and setting up details that allow auto subnetting / DHCP pool expressions - seems this might enable that future quite nicely.

Of current transition to KEA primary need is:

• serve domain name
• serve domain suffix search
• enable dynamic dns with config of master bind, domain key, more or less the dynamic dns functionality that exists for ISC in OPNSense now

There's probably a reasonable list of features others have used for BOOTP/etc. though I'm not trying to swim in that pool that deep right now and cannot comment to their use or have any testability in that space.

Updates! We are back to Suricata 6, but as I've come to find out, no AF-PACKET support in Suricata 6.

Code Select Expand

root@opnsense:~ # suricata --build-info
This is Suricata version 6.0.15 RELEASE
Features: IPFW PCAP_SET_BUFF NETMAP HAVE_PACKET_FANOUT LIBNET1.1 HAVE_HTP_URI_NORMALIZE_HOOK PCRE_JIT HAVE_NSS HAVE_LIBJANSSON TLS TLS_C11 MAGIC RUST
SIMD support: none
..
Suricata Configuration:
  AF_PACKET support:                       no

After a little bit of reading, it would seem af-packet isn't a thing in FreeBSD.

What/how does one work with enabling/optimizing rings/RAM based memory network rings for Suricata to inspect (not IPS, just IDS w/the ability to 'catch-up' and not drop as few as possible, inspect near all packets)?

Please, any and all that can help me make sense of this - I've been a Linux user for a while, and FreeBSD is close enough for me to forget that it really is NOT Linux, and some scripting I did on FreeBSD let me know that double recently lol.

Thank you!! I can track that! ^_^

Was curious about update availability to CrowdSec 1.6.0?

I am running a Multi-Server setup with the OPNSense being the main LAPI with an external Postgres DB, it all is still working post upgrade to 24.1 but, all the other parsers in the Multi-Server setup are 1.6.0 and OPNSense is still running 1.5.5. :(

Thank you again Community and OPNSense Team <3

It appears we should be working to tune the "netmap" back-end/feature instead of "af-packet" for Suricata 7. There are options enabling it for eth0 all the same even in the conf file for Suricata 7 in OPNSense 24.1.

It seems I remember that Suricata 6 was compiled with 'af-packet', but Suricata 7 was not - can anyone verify this?

Was also curious about how difficult it would be for someone to compile Suricata 7 themselves and add features to it (examples: nDPI 3.4+, PF_Ring 7.8+, Luijit, Redis, GeoIP, eBPF, Profiling) and then install that to the OPNSense?

Overall curious about the decision and if OPNSense is compiling their own Suricata, and the possible future of doing pulled-pork/oinkmaster, or its modern Suricata-Update and the ability to maintain per rule modifications (set $EXTERNAL instead of $ANY for specific rules/SIDs, and other mods/updates).

Note: been upgrading from around 18 or so, 24.1 seemed to upgrade without an issue, and all traffic appears to be going as expected. Great work guys!! Just looking to know my unknowns! <3

Just figured this out, Reverse DNS more or less expects /24... mine isn't

https://serverfault.com/questions/313659/setting-up-reverse-dns-for-a-25-block-of-ips

The OPNSense dhcpd produces this error when configured to update to an external BIND 9.18:

Code Select Expand

Unable to add reverse map from 10.1.168.192.in-addr.arpa. to host02.localnetdomain.home: NOTIMP
The other Subnet (10.10.0.0/16) has no problem updating its Reverse DNS/PTR records

BIND 9.18 produces the following output, showing that the OPNSense did a 2nd type of update run if you will, where the OPNSense deletes, and then adds it back with the new DHCP Lease Token/Key:

Code Select Expand

18-Jan-2024 13:26:31.718 client @0x0db29810a378 192.168.1.1#53080/key opnsensedhcp: signer "opnsensedhcp" approved
18-Jan-2024 13:26:31.718 client @0x0db29810a378 192.168.1.1#53080/key opnsensedhcp: updating zone 'localnetdomain.home/IN': update unsuccessful: host02.localnetdomain.home: 'name not in use' prerequisite not satisfied (YXDOMAIN)
18-Jan-2024 13:26:31.718 client @0x0db29810a378 192.168.1.1#53080/key opnsensedhcp: signer "opnsensedhcp" approved
18-Jan-2024 13:26:31.718 client @0x0db29810a378 192.168.1.1#53080/key opnsensedhcp: updating zone 'localnetdomain.home/IN': deleting rrset at 'host02.localnetdomain.home' TXT
18-Jan-2024 13:26:31.718 client @0x0db29810a378 192.168.1.1#53080/key opnsensedhcp: updating zone 'localnetdomain.home/IN': adding an RR at 'host02.localnetdomain.home' TXT "348b58c0d6248dc90762834bf6540b121a"
18-Jan-2024 13:26:31.718 client @0x0db29810a378 192.168.1.1#53080/key opnsensedhcp: updating zone 'localnetdomain.home/IN': deleting rrset at 'host02.localnetdomain.home' A
18-Jan-2024 13:26:31.718 client @0x0db29810a378 192.168.1.1#53080/key opnsensedhcp: updating zone 'localnetdomain.home/IN': adding an RR at 'host02.localnetdomain.home' A 192.168.1.10

It does complete its task correctly, the A+TXT get Updated, it appears the Reverse DNS record is not.

The error is about the inability to update the Reverse PTR record for the FQDN to the IP. The OPNSense doesn't appear to attempt to remove it first, or, is there more to the allowing DHCP Reverse DNS / PTR between OPNSense and an external BIND?

Instead of putting (? really just learning about BIND here ?) the Reverse Records/PTR in the 'localnetdomain.home' Zone, I put it in a '1.168.192.in-addr.arpa.' Zone, could that be part of the issue and how should I go about resolving it? I've also tried to just have a '168.192.in-addr.arpa.' Zone in addition to the '10.10.in-addr.arpa.' Zone that I have. Interestingly, the 10.10/16 subnet has no problem updating. Maybe I should just finish migration over to 10.10?

It would seem others would want to set it up that way too, but again, I'm only learning about DNS/BIND in greater detail recently. Thank you again for making/developing/releasing OPNSense everyone!!

learned recently - check your NAT Reflection settings, all should be off, then UPnP with its 5351? port on the interfaces configured should work as the guides state

if you still need what NAT Reflection gave you, check out running your own install DNS/Bind

check your NAT Reflection settings, all should be off, then UPnP with its 5351? port on the interfaces configured should work as the guides state - learned recently

[Step 1]

It is currently not a feature, nor will I be available to make it one any time soon. Till then, here's how you do it:
https://www.nova-labs.net/homelab-opnsense-crowdsec-multi-server/

Step 1

The OPNSense CrowdSec plugin installs observing a few default logs from OPNSense (lighttpd/sshd/pf) but does not come configured for any Suricata log listening. A CrowdSec Acquis file must be created or modified to get the feature we are adding here and without this, the fast.log file will go unobserved, you will also need the CrowdSec Hub elements to enable the parsing/alerting for Suricata, so console into the OPNSense and enter the following command (ssh in, select option '8'):

Code Select Expand

cscli collections install crowdsecurity/suricata
cscli collections install crowdsecurity/whitelist-good-actors
cscli parsers install crowdsecurity/whitelists

Then after creating the following file, it is my recommendation to hit 'save' on the CrowdSec plugin GUI of your OPNSense, this appears to reload instead of restarting the service as desired.

/usr/local/etc/crowdsec/acquis.d/suricata.yaml:

Code Select Expand

---
filenames:
  - /var/log/suricata/fast.log
labels:
  type: suricata-fastlogs
---

Step 2

Now that CrowdSec is aware and 'listening' if you will, we will want to create, and rotate those fast.log logs, let's setup the rotation of '/var/log/suricata/fast.log' as a custom config

/usr/local/etc/newsyslog.conf.d/suricatafast.conf:

Code Select Expand

# logfilename [owner:group] mode count size when flags [/pid_file] [sig_num]
/var/log/suricata/fast.log root:wheel 640 3 * $D0 BZ /var/run/suricata.pid 1

Step 3

To note: It appears the 'custom.yaml' file you will likely edit, needs the entire 'output:' stanza of the original (/usr/local/etc/suricata/suricata.yaml) Suricata config and then edit as desired – the example below is the working 'custom.yaml' with the only edit from original 'output:' being to change 'fast' to be enabled – 'enabled: yes'.

Worst case currently, an admin will have to be aware of updates to the original and diff the two wisely, as I develop that I will share here. It appears like you replace at 'stanza' level, so the other features (threading/etc.) of Suricata appear to be performing as expected, but, my experience on this feels suddenly fresher than it used to. It would possibly be better to have this config at the surface of the OPNSense available to the same spaces as the 'EVE' logs for Suricata. Might try to develop/contribute in the future – barely have time for this post lol. ^_^

/usr/local/opnsense/service/templates/OPNsense/IDS/custom.yaml:

Code Select Expand

%YAML 1.1
---
# empty stub for custom modifications, add custom persistent config below
# Configure the type of alert (and other) logging you would like.
outputs:

  # a line based alerts log similar to Snort's fast.log
  - fast:
      enabled: yes
      filename: fast.log
      append: yes
      #filetype: regular # 'regular', 'unix_stream' or 'unix_dgram'

  # Extensible Event Format (nicknamed EVE) event log in JSON format
  - eve-log:
      enabled: yes
...

^ IMPORTANT - I'm not including the whole stanza of "output:" here, please refer to your own file on your OPNSense

Firewall rules you make redirecting 5353 to local DNS Crypt and otherwise would get in the way

So, making rules that allow Broadcast/Multicast to pass ensure the forwarding don't get in the way ^_^