OPNsense Forum

Archive => 16.1 Legacy Series => Topic started by: dotike on January 31, 2016, 04:39:58 am

Title: Suricata and PF Interaction Clarification
Post by: dotike on January 31, 2016, 04:39:58 am
The current "IDS" package in OPNsense, (Suricata IDS) is fresh enough that I don't understand where the packets get filtered.

I'm curious about the interaction between the Suricata IDS, and PF, when using the package in "IPS" mode?

The idea of filtering packets based on various packet content matches is obviously quite a powerful tool, and I'd love to know where the edges are here in OPNsense!
Title: Re: Suricata and PF Interaction Clarification
Post by: franco on January 31, 2016, 12:12:16 pm
Hi Isaac,

I think you are talking about intrusion prevention here. This is based on netmap(4), which works as follows (shameless plug):


Page 17 of that presentation describes how netmap(4) plugs into the network driver itself and grabs packets there. For incoming packets that is BEFORE the kernel (pf) sees the packets and forwards them to userland our out again (first block on the upper left). There sits Suricata 3.0 in userland already and can drop packets if needed. They will never really reach the kernel or anything else. So in a way Suricata even sandboxes the OS from malicious packets  (if it has the descriptions of such packets in order to be able to block).

Packets going out are different as they flow through the full OS stack and are at last pushed to the driver for transmissions. Packets are grabbed there via netmap(4) again to push them to Suricata for inspection. Packets there can still be dropped so they never leave the box.

In short, Suricata attached to the network card itself. This is really cool, because in that single point you don't have to worry about NAT translations or routing, because you're essentially bridging the network and the kernel there.

Your questions:

(1) Does PF filter the packet first, or does the IPS?

IPS for incoming traffic on the listening device. PF for outgoing packets on the listening device.

(2) Can the Suricata rules be picked up by PF rules, (particularly rules which redirect the packet in some way- not block or deny?)

No. This can be solved, but not unless netmap transition becomes more natural in the kernel itself (netmap should be part of an mbuf, but right now it's not).

(3) Is Suricata really best to stand alone, (perhaps as an inline transparent bridge?)