Suricata inline versus legacy IPS mode
-
With Legacy mode, only after scanning the packets and match it with the rules will the host be blocked.
With Inline Mode, the packets are scanned and blocked if matched before passing to network.My understand is that regardless whether there will be packet leakage on legacy mode, eventually the host will be blocked if there is a matching block rule on it, am I understanding it correctly ?
If I understood that correctly, if I have no proper NIC to support inline mode, legacy mode will still work for me since it will also block.
My other question also is, if legacy mode will suffice, what is the real benefit out of inline mode ?
-
With Legacy mode, only after scanning the packets and match it with the rules will the host be blocked.
With Inline Mode, the packets are scanned and blocked if matched before passing to network.My understand is that regardless whether there will be packet leakage on legacy mode, eventually the host will be blocked if there is a matching block rule on it, am I understanding it correctly ?
If I understood that correctly, if I have no proper NIC to support inline mode, legacy mode will still work for me since it will also block.
My other question also is, if legacy mode will suffice, what is the real benefit out of inline mode ?
With Legacy there is a chance that the packet could make it past your IDS because of the time it takes to scan the packet.
With inline the chance of leakage is much lower because the packets are scanned and blocked before ever being passed on the the NIC.
The only downside to inline that I have seen on my install is it breaks traffic shaping at the moment.
Also from what if I have seen if you have an Intel NIC you should be just fine running inline.
Hope this helps…
-
@cplmayo has this essentially correct. I will just add a little more detail to the explanation to highlight the differences between inline IPS mode and the legacy IDS/IPS hybrid mode.
In legacy mode, the pcap library is used to make a copy (clone if you will) of every packet as it comes in from the NIC on its way to the pf firewall engine. The original packet continues on to the pf firewall engine and is either passed or blocked depending on the current rules in the firewall. Meanwhile, the cloned packet is sent over to Suricata (or Snort if using that package) for inspection against the IDS/IPS rules. Should the cloned packet (or packets, since sometimes Suricata needs to see a group of packets before a decision can be made) be judged as "bad" by the Suricata engine, then a system call is made to insert the offending IP address from the packet into a special table in the pf firewall engine called snort2c. IP addresses in this special table are blocked. However, note that this decision making and subsequent insertion of the IP address into the snort2c table has happened well after the original packet (or packets if a group of packets was required to make a decision) has traversed the pf engine. So that original packet will have already gotten past the IPS mechanism. Packets that subsequently come through from the same IP address will now get blocked, though. Hence I use the term "hybrid IDS/IPS" because a true IPS would never leak a packet. A true IPS would hold up the original packet while it was being inspected, and then either pass it or drop it. Legacy mode does not hold up the original packet. It is allowed to continue on to the firewall while the cloned copy is used to make the decision for blocking future packets from the IP address.
With the new inline IPS mode, Suricata activates and uses the relatively new Netmap mechanism that was added to FreeBSD. Netmap is a way for applications to create a highspeed pipe between the NIC driver layer and the rest of the system. So packets coming and going on a given network interface must pass through the Netmap pipe. Suricata inline-mode controls the "door" in this pipe. Each packet stream coming from the NIC (or going to the NIC) is inspected by Suricata and a "pass" or "drop" decision is made. If a packet is dropped, it is never forwarded on to the pfSense kernel and thus never makes it to the pf engine. Since every single packet must traverse this Netmap pipe, there is no leakage. No copies of the packets are made for examination. Everything occurs with the original packet.
The downside of the new inline mode is that for now only some NIC drivers support working with the Netmap API mechanism. So while legacy mode is pretty much NIC card and driver agnostic (meaning it works with any hardware), the inline mode is highly dependent on your firewall having a NIC driver that supports Netmap. Another problem that currently exists is the Netmap pipe seems to break traffic shaping on the interface. I suspect this is a fixable problem, but no solution is in place yet.
So consider these two issues before choosing to use the inline IPS mode: (1) do I have a supported NIC and driver; and (2) can I do without traffic shaping on interfaces where I run Suricata?
Bill
-
This isn't totally on topic to the OP. My pf box has 6 igb int. I have an esx server downstream running security onion. I don't want to use Suricata for IPS but I do want to use netmap as a tap for all interfaces then send the whole stream to security onion on an unused int. Can Suricata be put in inline mode with IPS not blocking anything and use suricata.yml to configure the tap interfaces?
-
This isn't totally on topic to the OP. My pf box has 6 igb int. I have an esx server downstream running security onion. I don't want to use Suricata for IPS but I do want to use netmap as a tap for all interfaces then send the whole stream to security onion on an unused int. Can Suricata be put in inline mode with IPS not blocking anything and use suricata.yml to configure the tap interfaces?
Wouldn't this be easier to accomplish at the switch versus within the firewall?
