Messages

The ability to use the RACK TCP Stack would be nice and might be beneficial to some.

https://github.com/opnsense/core/issues/9452
https://klarasystems.com/articles/using-the-freebsd-rack-tcp-stack/

So, if this mode may be associated with a specific PF rule, how can I inspect normal browsing traffic (HTTP/DNS/FTP)?
I mean, in IPS/IDS mode I can just test Suricata with "curl http://testmynids.org/uid/index.html" and I see the alert, but this won't happen in Divert mode.

So what I've done now is a more targeted approach I would say and have only added the Divert-to Intrusion Detection on my existing rules. I added it to my VPN rule for the WAN interface that exposes that port and I enabled it on the LAN default allow to any rule. Putting it on the default LAN out rule doesn't hurt, but the benefit may vary I suppose depending on your use case.

I would imagine if you added/enabled Divert-to Intrusion Detection on the "Default allow LAN to any rule", that would probably catch those tests. If you want to catch that traffic coming in on the WAN (as in initiated from the internet) and you have existing rules for those open ports, then you would add/enable Divert-to Intrusion Detection on those rules. However if you don't have existing rules for open ports, I would suggest to NOT create rules for that purpose.

I hope I didn't cause to much confusion from my earlier lack of understanding on how this new mode really worked.

I was initially on the same assumption as @RamSense, however that is not how it works.

So on hindsight and after more testing, I would suggest to only use Divert-to on WAN rules for existing services that are exposed to the internet. Like a VPN for example. Otherwise you end up with just suricata to block on an IPS match, which could probably lead to issues depending on what ports you have open. I only have 1 for my VPN, so I think I was lucky in this case.

No packet is passed back to the firewall to match another rule on the same interface afterwards.

Does it mean that it doesn't matter the selection of pass, reject or block on the "divert-to" rule?

The firewall rule has to be a pass action, if you have divert-to selected and try to set it to anything else you will see an error in red text saying it must be a pass rule.

For me my rule is simple, a new rule in Rules [New] on the WAN interface coming in to pass all traffic and Divert-to set to Intrusion Detection. This basically replicates my previous setup by capturing all packets for inspection, I don't want it to be more granular, maybe in an enterprise environment but not my homelab. The order is up to you, place the rule accordingly based on your other rules for the WAN interface.

NOTE: Divert-to is hidden and is only available in the "Advanced Mode", so be sure to enable that in the top left corner of the new rule dialog.

I use the WAN interface and add my ISP routers IP address to Home Networks in the suricata config, as far as I am aware this is the best method when using an IPS. As when on the LAN interface you may get more false positives and a lack of detection's since that interface is on your internal network. Intrusion attempts come from the external network in most cases, especially for homelab environments.

https://docs.opnsense.org/manual/ips.html#general-setup
https://docs.opnsense.org/manual/ips.html#advanced-options

Be careful: a broad WAN "pass any + divert-to" rule will effectively allow all inbound traffic on WAN. That can expose services running on OPNsense itself (e.g. SSH, DNS, GUI) to the internet.

It likely makes more sense to apply divert-to only on the specific WAN allow rules / opened ports you actually intend to expose.

Does not appear so, as @Monviech mentioned, the packet is diverted to suricata for the decision and nothing else. Just for peace of mind since I have a Q-Feeds subscription, I used their vulnerability scanner and found nothing. No open ports, no vulnerabilities, nothing.

EDIT: Actually I think you're right on this, my bad. When you pass any with divert-to, basically all "default deny / state violation" blocks no longer trigger. So probably is best to only set divert-to only on exposed ports. Feels like a noob mistake :(

I have a (maybe dumb) question:

When using "divert-to" the matched packet is sent to Suricata to be inspected. After that, Suricata is responsible for the evaluation of the packet and not pf anymore.

Who is in charged of rejecting, blocking or passing the packet?

I can imagine that Suricata responds to pf with a verdict and is pf who blocks or pass the packet.

Suricata is in charge of rejecting the packet, so you need to configure your suricata policies accordingly to drop the packet.

For me my rule is simple, a new rule in Rules [New] on the WAN interface coming in to pass all traffic and Divert-to set to Intrusion Detection.

Will you need to set the rule direction to both? To capture outgoing traffic like malware calling home?

As when on the LAN interface you may get more false positives and a lack of detection's since that interface is on your internal network. Intrusion attempts come from the external network in most cases, especially for homelab environments.

And wouldn't you still detect external attacks if you only monitored within the LAN? At least all the traffic leaving the OPNsense router towards the LAN (traffic that gets through the firewall), which is presumably the majority of the data traffic?

You wouldn't detect an external incoming attack on the LAN, unless that traffic was somehow passed through the WAN interface to the LAN interface. You would probably need ports open on the WAN, or maybe using UPNP.

For me my rule is simple, a new rule in Rules [New] on the WAN interface coming in to pass all traffic and Divert-to set to Intrusion Detection. This basically replicates my previous setup by capturing all packets for inspection, I don't want it to be more granular, maybe in an enterprise environment but not my homelab. The order is up to you, place the rule accordingly based on your other rules for the WAN interface.

NOTE: Divert-to is hidden and is only available in the "Advanced Mode", so be sure to enable that in the top left corner of the new rule dialog.

I use the WAN interface and add my ISP routers IP address to Home Networks in the suricata config, as far as I am aware this is the best method when using an IPS. As when on the LAN interface you may get more false positives and a lack of detection's since that interface is on your internal network. Intrusion attempts come from the external network in most cases, especially for homelab environments.

https://docs.opnsense.org/manual/ips.html#general-setup
https://docs.opnsense.org/manual/ips.html#advanced-options

That's true, my OPNsense runs as a VM on XCP-ng, however I use SR-IOV with Intel X710 NICs. So never had an issue with using Netmap, but using the Divert method is way more efficient on memory usage. I have 16GB of memory allocated and before the memory would typically sit at 40-50% usage. I just checked and it's now down to about 10%. Will probably reduce the memory allocation in the near future as the system obviously doesn't need it anymore.

Issue has been created as requested.

Another upside to using Divert (IPS) mode, the memory consumption has been cut in half since Netmap is no longer being used :)

So I just upgraded to 26.1 and migrated the firewall rules over as well (don't have many) and everything went over smoothly with no issues.

However I was wondering about the new Divert (IPS) capture mode as the documents state that a firewall rule is needed in the new rules section. If you select this capture mode, will a new firewall rule by auto generated for it?

Also as a side question, if you diverted all WAN traffic for inspection anyway... would there be any benefit from Netmap (IPS) mode?

EDIT:
Well I just went ahead and enabled it, and basically answered my own questions :)

No rule is created automatically, so after setting suricata to Divert (IPS) mode with 8 listeners (8 CPUs) I created a new rule on the WAN interface just below the Q-Feeds rule to pass all incoming traffic to Intrusion Protection. Works as expected, and I suppose it's probably more efficient since it's using PF and coming after the Q-Feeds rule. No sense in inspecting blocked traffic.

However I noticed that after doing so the "Interface" in the Intrusion Protection Alerts page is blank, makes sense... but is there a way in the future to pull this information from the firewall rule?

EDIT 2:
Please read the whole thread for more context, however after further understanding in how divert-to works...
ONLY enable the divert-to setting in PF on existing rules on the WAN interface that exposes ports to the internet if you want to have them inspected by IPS, no additional PF rule will be applied for matching traffic after that point.

I also had higher memory consumption with an increasing swap file size as well. Noticed that hostwatch was enable on all interfaces, as such it was logging IPs on the WAN interface as well. From my understanding this is targeted at keeping track of IPs on your local network, so shouldn't the WAN interface be excluded by default?

Odd thing is I disabled the service, selected all interfaces except WAN and re-enabled the service. However now the service refuses to start and nothing in the hostwatch logs says why. The system log reports:

Code Select Expand

[meta sequenceId="2"] <6>[132593] pid 22972 (hostwatch), jid 0, uid 0: exited on signal 6 (no core dump - bad address)
So for now I just left it disabled since it seems to provide relatively little value.

So I installed the plugin and set it up over the weekend and I am quite happy with it. Probably the best solution so far due to the native firewall integration by using pf and unbound for the filtering.

Not sure on what all of the suggested improvements has been so far, I know there has been many, like the automatic rule generation... which would be nice but I would also suggest making it optional. So that the more advanced users can simply create their own. I say this because for example I only use IPv4, so I did not create an IPv6 rule as it is not required. Relatively minor, but it's nice to not have things defined if they are not needed.

Not sure if this has been suggested or not, but the Q-Feeds Events page should also include unbound events as well to provide a holistic view of all traffic filtered by Q-Feeds and the fact that the unbound details page has a limited log size and gets overwritten very quickly. Also I know there was suggestions to include the IoC lookup there as well, which would be great. If that can not be done for some reason, maybe at least a whois lookup link?

Also it is difficult to verify unbound integration as the only thing you are really relying on is to either look at the unbound blocklist size before enabling Q-Feeds, or rely on something being filtered in the unbound logs since there is no blocklist to select within the unbound blocklist drop down menu. The current configuration basically implies that it is enabled without any real verification. Maybe provide a test URL to verify unbound integration?

I look forward to the continued improvements to the plugin and ip/dns lists.

Thanks

Hello,

I haven't tried this product out yet but I am considering to in the near future. However for licensing I was wondering what is meant by "Beneficial users (FTE)", is this in reference to users as in people, or users as in connected devices as in IP addresses? I would assume the later, but figured I would ask for clarity.

Thanks

From my own testing those regex entries will most likely not work, you should notice that URLs to those domains are now being blocked.
As an example for my regex entries, I went from 2 entries to 12 entries in the whitelist.

This line matched 2 URLs
^\*\.androidtv[a-z]{8}-pa\.googleapis\.com$

This line matched 10 URLs
^\*\.[a-z0-9-]*\.delivery\.roku\.com$

However whitelisting through the unbound reporting page now works correctly, before it was broken. So I believe this is the reason the change was made, but it's unfortunate the fix breaks regex whitelisting functionality.