Snort/Suricata Setup doubts for this case

MuNLoK

Hi!

We are using snort/suricata for first time and after reading many comments relating on which interface is better to configure it, I have some doubts for this pfSense / network configuration case:

Interface WAN (/30): 192.168.0.1 (ISP) / 192.168.0.2 (pfSense)
Interface LAN: 192.168.1.0/24
Interface OPT1: x.x.x.x/24 (Public IP Block /24, with the .1 ip assigned to the interface/pfSense itself).

ISP give direct IP Transit with one public block /24 routed directly to the pfSense WAN IP 192.168.0.2:

The OPT1 interface is for public servers (most of them cPanel / PlesK with a lot of public services) binding public IP directly on their interfaces, so NAT is disabled for this /24.

NAT is only used for the LAN interface, using the .1 ip (opt1 public IP) for outbound traffic.

These are my questions:

Regarding this configuration, on which interface (s) would you recommend activating Suricata?
Our top priority is stability and 100% uptime. Based on this, would it be more reliable to use Snort or Suricata?
I see the option "Promiscuous Mode" activated by default in Suricata, what impact would it have if we deactivate it?
This pfSense is virtualized on ESXi and uses vmx interfaces, would you recommend using legacy mode or inline mode in this case?

We also appreciate any security tip or additional recommendations for this setup.

Thanks!!

Kind Regards.

bmeeks

@MuNLoK said in Snort/Suricata Setup doubts for this case:

These are my questions:

Regarding this configuration, on which interface (s) would you recommend activating Suricata?

Your network configuration sounds like one of the rare cases where I would recommend two IDS setups: one on that public-facing OPT1 interface and another on your LAN interface. Those two IDS instances would likely need different rules because it is probable that different exposures and attack surfaces exist in the two networks.

If you simply are going to use the exact same rules on each interface and don't want to waste CPU and RAM resources, then I would suggest putting a single IDS instance on the WAN interface as the best compromise.

I would also be remiss if I did not mention that the vast majority of network traffic today is encrypted. That puts a big kink in the ability of an IDS to look into the packet payload and find threats. The only way for the IDS to have a full picture of the traffic flow is for you to do some kind of MITM (man-in-the-middle) interception of encrypted traffic (SSL and TLS, usually) on the firewall.

Our top priority is stability and 100% uptime. Based on this, would it be more reliable to use Snort or Suricata?

No real difference here in reliability. Suricata can, theoretically, offer slightly better performance in high-traffic situations due to its multi-threaded nature. But that advantage is very, very slight because single-thread bottlenecks still exist in some areas.

In terms of security, they are also about the same. Differences may arise based on the rules packages you choose. Sounds like you have a commercial setup in mind with those public-facing servers. So you would need commercial licenses for the Snort Subscriber Rules. Right off the top of my head, I think those are around $300 USD or so per year for commercial use. The personal use subscription is $30 USD per year.

The other supported rules package comes from Emerging Threats (aka, Proofpoint). They have a free ET-Open package, but that ruleset is limited and the rules in there are older (late-breaking current threats aren't included). They also offer an ET-Pro subscriber rules set that is quite good and includes detection of the latest threats, but it is close to $1000 USD per year if I recall correctly.

Finally, if stuff like social networking detection and other Layer 7 things matter to you, then Snort's OpenAppID feature might be more appropriate. Suricata currently has no such feature, and I see nothing similar planned in the upstream roadmap.

I see the option "Promiscuous Mode" activated by default in Suricata, what impact would it have if we deactivate it?

In a switched environment, unless you enable port-mirroring (or SPAN in Cisco-speak), then "Promiscuous Mode" has no impact and you won't see any difference with it on or off. That's because all it does is cause the NIC to accept all traffic it sees on the wire (when "on"), or reject traffic on the wire that is not addressed to the MAC address of the NIC (when "off"). In the switched networks we all use today, that usually amounts to a distinction without a difference ... . The upstream switch is only going to send traffic to the pfSense NIC that is destined for the NIC's MAC address anyway. The one exception when you would want "Promiscuous Mode" enabled is when you are using a switch with port-mirroring enabled because you want the IDS to see traffic to/from other hosts on the segment.

So the short version is "it generally does not matter". The only time you want it enabled is when using port-mirroring.

This pfSense is virtualized on ESXi and uses vmx interfaces, would you recommend using legacy mode or inline mode in this case?

Because you prioritized stability and 100% uptime, I strongly recommend Legacy Mode blocking if you want to use blocking. Inline IPS Mode uses the netmap kernel device, and support of that device is very highly NIC dependent. Some support it well, others not at all, and still others "sort of". The virtual NICs in hypervisors like ESXi are supported, but only in what's called emulated netmap mode. There is a severe performance penalty when using emulated netmap. So that's a big reason to use Legacy Mode.

Many folks, though, do use Inline IPS Mode quite successfully with say the em NIC driver in ESXi. So you would use the e1000 NIC hardware choice in your virtual machines. But that choice is not going to offer the same basic network performance as the vmxnet3 virtual hardware. Also be aware that with lots of enabled rules on a high-traffic interface you will see a performance penalty no matter which NIC option you choose. How much of a penalty is determined by the CPU horsepower you have and the number and type of enabled rules (and whether the NIC you choose runs in emulated netmap mode).

Of course with Legacy Mode blocking you lose some of the finer traffic control granularity that comes with an inline mode that drops individual packets instead of blocking an IP address. When you block on IP address, you block all future traffic for that host regardless of protocol or port. With inline mode, you are dropping individual packets and thus have very fine control of what's allowed and what's not allowed to and from a given host.

MuNLoK

Thanks @bmeeks ! You have definitely resolved all my doubts and I'm very grateful for your detailed answers.

We will continue working on this setup and comment if we find any problems.

Thank you!!