Suricata - Divert (IPS)

[jeffrey0]

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.

Thank you very much for this information!

[RamSense]

Oh? thanks for sharing. My assumption was that is was something like this: the divert rule -> suricata allows -> on to the next firewall rule in wan in line, but not allow all.
That makes this divert rather different than a "blocklist" block and on to the next rule concept...

[Monviech (Cedrik)]

Divert means that after the firewall match, the decision is totally "diverted" to what listens on the divert socket. No packet is passed back to the firewall to match another rule on the same interface afterwards.

[RamSense]

I understand now. So you have to change every allow rule you want to have inspected with suricata to divert.

Maybe it is an option to add a feature of "divert and return", so after a suricata allow -> opnsense goes furter with the next firewall rule in line?

[muchacha_grande]

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?

[xpendable]

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.

[xpendable]

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.

[xpendable]

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 :(

[xpendable]

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.

[xpendable]

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.

[Arien]

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.

[xpendable]

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.