suricata versus the latest version of snort
-
Now that the latest version of snort competes against suricata. Has anyone performed any real head-to-head comparisons over their performance against one another?
-
@jc1976 said in suricata versus the latest version of snort:
Now that the latest version of snort competes against suricata.
@jc1976 "real head-to-head comparisons over their performance"
Hi,
Do you think it's worth it?
Someone prefer the Suricata someone prefer the Snort, for example I got used to the Suricata, as it was the only one with multi thread operation...
(I note that at 10 - 40 - 100 Gig only here the difference which is relevant - but I still started working with this, Suricata)Suricata mishandles some Snort rules (ie: snort flowbits), for example, the maintainer of packages also uses Snort (Bill), so that might tell you something.
So I think this is the question of taste and slap, for IPS/IDS (theoretical operation) is in principle no different on Snort and/or Suricata, but the discussion can be long here, I look forward to it too.
However, I plan to test the Snort (newer) on a VM...............................(?!)
-
@daddygo
do i think it's worth it?Sure, why not? If i had the resources and know-how, i'd do it.. but i don't know how.
I used snort, then switched to suricata because it took advantage of multiple cores, and at the time, snort did not.
also, suricata has it's own rules and used snorts as well, so i figured i was getting the best of both worlds.However, now that snort is fully modern, i was just wondering if there had been any tests. did one out-perform the other.
-
@jc1976 said in suricata versus the latest version of snort:
Sure, why not?
hmmmm
The problem is that how it creates a test environment that generates enough incidents that you get a visible difference in the test.
I couldn't do this even with a Kali VM at 10Gig speed, so the test is using more resources than you want.
PS:
And playing with it in a production environment is madness
(although I don't think you can draw any serious conclusions from the test there either)Cats bury it so they can't see it!
(You know what I mean if you have a cat) -
I have not tested Snort3 yet, and I'm not an expert on its internal code structure. But it does appear to function differently in the multithreading universe from Suricata -- at least from what I can tell with very preliminary investigation.
Suricata offers two threading modes for normal operation: (1) auto flow-pinned [autofp]; and (2) workers.
Workers mode can be the most efficient on high core count processsors. Using runmode workers, a single thread handles all aspects of processing a given packet stream. It reads the packet off the wire; decodes it; runs it through the rule signatures; logs any alerts; and then in IPS mode, either writes the packet out to the destination interface or drops it. A given worker thread runs on the same CPU core. So parallel processing is possible, but the caveat is that packets constituting the same flow must be handled on the same core. So you still may not fully utilize a multi-core CPU if your traffic pattern consists of basically a single flow (one session, for example). In a home firewall this may well be the case. But in an enterprise setup with lots of traffic for lots of different users, you will have lots of different flows. Thus that type of environment is where Suricata's multithreaded nature would be more useful.
Runmode autofp is different. In this mode, the threads that read packets off the wire (RX threads) are not used to process the packet through the signature analysis and logging engines. Instead, a separate Packet thread pool is maintained for those tasks that uses worker, or W# threads. Multiple RX threads (receive threads) may be started to pull packets off the wire. The number of RX threads started is determined by several factors, and can be controlled via advanced parameters in the
suricata.yamlfile. When a RX thread reads a packet off the wire, it puts it into a Packet Queue structure in Suricata. The Packet Queue is a circular list of packets awaiting processing through the signatures. Worker threads are then launched to process the packets of a given flow through the rule signatures and then on to logging and alerting. The same caveat applies to this mode as did to workers mode earlier with regards to mutiple different flows enjoying greater performance boosts with multi-core CPUs.Snort3 appears to use just a workers mode threading environment. So it appears to have only a single runmode. It does not appear to offer an analog to autofp runmode in Suricata. I'm also not clear on how Snort3 directs flows nor how it decides how to route them across multiple cores.
So the hidden "gotcha" in both IDS/IPS packages, when using multi-core CPUs, is that traffic for a given flow is kept on the same CPU core. So if you have a situation where the traffic stream is all from a single flow (say downloading a large file in one TCP session), then a multithreaded IDS/IPS app is not going to really help all that much when compared to a single-threaded version (for example, Snort2). A large single flow is also called an Elephant Flow. And Elephant Flows do not scale with multiple CPUs or cores.
Some users think multithreaded automatically means high performance, and the more CPU cores the higher the performance. That's only true if the IDS/IPS is able to see many, many different flows such that it can distribute them across all the cores and threads. If the traffic is just a single flow, or maybe even just two flows, you are not going to see huge performance improvements using a typical speed test site or with
iperf3just because you are using a multithreaded IDS/IPS. -
@daddygo If you want a good test environment with lots of attempted attacks, connect your test machine to a consumer Xfinity (Comcast) internet connection and enable all rule categories (with the usual false-positive rule suppressions, of course). I think my Suricata logs get so full that they roll over every day. It makes me wonder about the attacks that pfSense is missing.
Seriously, though, I get what you're saying. We don't want to wait forever for useful results. A lot of attacks need to be launched quickly from lots of different connections. I'm curious about how others would set up a good test not just for Suricata but for the entire pfSense system.
-
@eveningstarnm said in suricata versus the latest version of snort:
connect your test machine to a consumer Xfinity (Comcast) internet connection
Yup
Yes you are right it is America over there, although nowadays the invasive presence is increasing everywhere.
The idea is good :) - (Xfinity + Comcast ISP)
What I'd rather push is that it's not enough to just increase the number of unwanted events, you also need to increase the traffic (PPS) to see how the processing processor behaves on say a 40 - 100 Gig - f.e.: Netflix network
BTW:
although if I am correct - Netflix also uses a lot of FreeBSD stuff, because of the high traffic and of course the "pf" benefits
