Snort performance and order of operations of security

[michmoor]

Hello,
Two things I have been wondering regarding how pfsense handles threat prevention, specifically how does it determine which threat prevention rule (ACL,DNSBL,IP Block,Snort) should it use when traffic is going through the software.
Additionally, I am having very poor performance with Snort using default settings and with "Balanced" IPS policy enabled.

So for the first topic. If a packet enters the pfsense, does snort evaluate first or does the firewall rules check. After that's done and lets say pfblockerNG is enabled, do secondary checks happen there (DNS filtering allowed/denied). At what point during the process does pfsense make the decision to forward/drop the packet and why?

Regardin performance, i can iperf from LAN to LAN segments (vlan) normally at 1Gbps. With Snort enabled i can do 100Mbps. Default configuration are in play. As a test, Suricata is better able to achieve and sustain the high throughput but i much prefer Snort for the OpenAppID implementation as i am crafting policy around that. Any way i can improve performance? I have tried playing with the pattern matter but i see no gains when doing so.

[SteveITS]

@michmoor BMeeks has posted diagrams in other threads, but in general Snort and Suricata are "outside the firewall" so get processed first. So if you run it on WAN it will check all packets, even packets the firewall will drop microseconds later.

What is your CPU usage during your iperf test? Also don't run iperf on pfSense itself as that uses CPU cycles.

Snort performance also depends on how many rules are enabled.

If it is running on both LANs then note packets will be scanned twice (unless the LANs are in a pass list).

[michmoor]

@steveits
Are those diagrmas pinned somewhere? Would love to review.

As for snort performance, all iPerf test take place outside of the fireall and between the two hosts
The first speedtest is LAN to WAN. Snort enabled on LAN I get reduced performance. My line is 500/500 and I can get around 70/70.
The second speed test isx LAN to LAN and performance is generally the same.

CPU idle does dip to the mid 40% during the test which I believe is somewhat expected as iperf pins itself to a core.

[SteveITS]

@michmoor said in Snort performance and order of operations of security:

CPU idle does dip to the mid 40% during the test which I believe is somewhat expected as iperf pins itself to a core.

Not sure I follow this part...I was asking for the CPU usage on the pfSense, where iperf isn't running.

Are you using Inline or Legacy? If Inline, I suspect a NIC driver issue...try Legacy.

re: diagrams, I don't know, but if you look back through the IDS subforum it comes up every few months. Basically, just think of Snort "outside of" pf so something like: Snort WAN - pf - WAN - LAN - pf - Snort LAN.

[michmoor]

@steveits CPU on the pfsense while iPerf tests go through the device hovers around 30%.

I'll search the forums. The high level concept you described makes sense. So IDPS is your first line of defense before all the other filtering and blocking takes place.

[SteveITS]

@michmoor If it's not CPU bound it's something else which is why I asked about the mode. Read up on Inline mode but basically there are a bunch of caveats.

I've not experienced any sort of consistent/dramatic speed throttling with Snort or Suricata yet on any connection, aside from CPU usage on old/slow router CPUs, which I've seen get up to wire speed of 350 Mbps or so at around 90+% CPU. So 70 is a pretty dramatic decrease.

[bmeeks]

@michmoor said in Snort performance and order of operations of security:

@steveits
Are those diagrmas pinned somewhere? Would love to review.

As for snort performance, all iPerf test take place outside of the fireall and between the two hosts
The first speedtest is LAN to WAN. Snort enabled on LAN I get reduced performance. My line is 500/500 and I can get around 70/70.
The second speed test isx LAN to LAN and performance is generally the same.

CPU idle does dip to the mid 40% during the test which I believe is somewhat expected as iperf pins itself to a core.

The diagrams are not pinned, but here they are again.

[bmeeks]

@steveits said in Snort performance and order of operations of security:

If it is running on both LANs then note packets will be scanned twice (unless the LANs are in a pass list).

Small correction here. A Pass List only determines if a given IP address will be blocked or not. It does NOT stop packets traversing a Snort instance from being inspected against all the enabled rules. Pass Lists are only evaluated once an alert has been triggered and Snort is deciding whether or not to block the IP that triggered the alert.

[bmeeks]

@michmoor said in Snort performance and order of operations of security:

@steveits CPU on the pfsense while iPerf tests go through the device hovers around 30%.

I'll search the forums. The high level concept you described makes sense. So IDPS is your first line of defense before all the other filtering and blocking takes place.

But it is generally pointless to put the IDS/IPS on the WAN unless you have enough holes and port-forwards enabled that you have turned your firewall into Swiss cheese .

The default setup for pfSense is for the WAN to allow NO inbound, unsolicited traffic. Therefore, scanning all the inbound traffic from the WAN is really pointless with the default setup. And even if you have a few port forwards enabled (or serve public services behind the firewall on public IPs), it still is better strategy to put the IDS/IPS on the inside, local-facing firewall interface and then carefully choose applicable rules to enable.

Also, as mentioned by others, don't run the iperf3 tests directly on the firewall. You burn CPU cycles running the iperf3 code, so those cycles are then not available to route packets back and forth. Put your iperf3 client and server pieces on boxes outside the firewall, on different interfaces, and measure the firewall's performance while doing nothing but forwarding packets.

However, prepare for something quite a bit less than full line-rate when using IDS/IPS. The more rules you have enabled, and the more complex they are in terms of pattern matching operations, the bigger throughput hit you are going to take. The IPS Balanced Policy is going to automatically enable a lot of rules. You will need a powerful CPU to keep up with the interface line rate with that policy in place. Another thing that bites the performance of Snort is the fact it is single-threaded. So what really matters is how fast the CPU clock speed instead of how many cores it has. Snort is only ever going to use a single CPU core, so for performance you want the fastest clock speed you can get.

[A Former User]

Hello,

Regardin performance, i can iperf from LAN to LAN
segments (vlan) normally at 1Gbps.

It also depends what kind of network topology your are running! Let us say the Switch is doing the routing and ACLs are in the game to manage the VLANs and its members, so you free some power on your pfSense.

With Snort enabled i can do 100Mbps.

Jep, this is also known at some other Firewall / UTM
vendors boxes, something around 10 % of the
raw routing power will "survive" after firewall filters
and DPI is turned on. So first not only pointed to
pfSense and/or the hardware. To be clear I am not talking
about vendors with soldered FPGAs for gaining the WAN
and/or LAN throuput or speeding up the entire DPI process.

Default configuration are in play. As a test, Suricata
is better able to achieve and sustain the high throughput
but i much prefer Snort for the OpenAppID
implementation as i am crafting policy around that.
It often depends on the code writers and how they implement their code. Let us thing you will be using pfSense and their programmers will use Intel QAT to
compress "things" there and then you use AES-NI
for the entire rest of encryption stuff such VPN and so on.
This will be speeding up much more then. So you see it is not only a config or hardware given "problem" or challenge.

Any way i can improve performance? I have tried playing > with the pattern matter but i see no gains when doing
so.
If you use Intel Xeon E3- v6 with 32/64 GB RAM and you
turn it on once more you will be archiving totally other
numbers I will really guess and with a real Intel Xeon E7
you will be able to gain this once more again, but Paid
with electric power!

With a Xeon D-21xxNT 4C/8T or 8C/16T and a big L3
cache it will be perhaps in the future also nice to see a gaining throughput or plain other numbers. The entire WAN traffic can be sorted over many more queues and transfer more packets, since 2.5 and/or 2.6 this should be
not problem any more.

If you have a DMZ and servers there inside, you normally
may sort the DPI process into two ways, IDS for the WAN
to LAN and WAN to DMZ area and then IPS in front of the servers directly. If you own now a pfSense device it is really
tempting to activate all there on one device, but until you are reaching a point (throughput, devices, traffic) you should think about to spread the processes over more devices to archive a smooth and liquid network flow.

Where IDS/IPS has to be done and/or installed or set,
is once more to point to your entire Network topology.

Snort for the DMZ with eMail and SMS alarm, suricata
inside of the LAN and OSSec on the entire PC and Server LAN infrastructure, activated MacSec on stacked switches
and IDS sensors at the monitor (mirrored) ports Squid with AV inspection on own servers or VMs is not so seldom
as you will think about. But in such a network pfSense is doing routing WAN - DMZ and WAN - LAN with firewall rules, it is fast as the hardware is serving, but should matching to the rest of the entire network.

[michmoor]

@bmeeks and bookmarked