When we first started experimenting with Suricata we had pfSense running on a very old PC...XP era probably, and I'd guess 10-15 years old. When running, Suricata did seem OK and not too CPU or RAM intensive but Suricata did simply stop working now and again. That hasn't happened since using newer hardware with a faster CPU, though we've also upgraded pfSense since then. We haven't had any such issue elsewhere.
I would expect that higher traffic would definitely benefit from multithreading, hence our choice of Suricata over Snort. The one issue we had with Suricata is on a CARP setup, where the sync would fail and crash the web service and/or PHP on the second router. I had tried to disable a lot of rules (some of the rulesets have hundreds) that didn't apply, and that took forever since it tried to sync each time. Later I found all those rules were enabled again, and we haven't had the problem lately. My guess is the more individual rules that one disables, the longer it takes to sync, and the larger sync info is. Then at some point something crashed and reset the rules to not have any disabled, after which the sync is smaller. -- Steve Yates ITS, Inc. -----Original Message----- From: List [mailto:list-boun...@lists.pfsense.org] On Behalf Of Karl Fife Sent: Monday, June 13, 2016 2:12 PM To: pfSense Support and Discussion Mailing List <list@lists.pfsense.org> Subject: Re: [pfSense] Snort or Suricata With as many rules as an IDS/IPS would evaluate for each packet, it seems that a multi-threaded option would be an obvious choice, especially on modern multi-core quasi-embedded systems (e.g. Rangely/Atom) with lower absolute clock speeds. Otherwise it seems you might become effectively CPU bound given modern uplinks and applications (e.g. captive portal, multi-lan etc), thus introducing jitter and reduced throughput. Is this consistent with anyone's real-world observation/testing? On 6/13/2016 9:28 AM, Steve Yates wrote: > See if disabling the stream-events.rules ruleset helps. The web forum had > some references about that being incompatible with the pfSense > implementation. If memory serves, it's because Snort/Suricata see copies of > packets not the actual stream so they are often processed out of order. > > When I looked a while back it seemed like Snort and Suricata were similar but > Snort was single thread and Suricata could multi-thread. > > https://github.com/Snorby/snorby/wiki/Snort-vs-Suricata-vs-Sagan > http://wiki.aanval.com/wiki/Snort_vs_Suricata > > -- > > Steve Yates > ITS, Inc. > > -----Original Message----- > From: List [mailto:list-boun...@lists.pfsense.org] On Behalf Of Daniel > Eschner > Sent: Sunday, June 12, 2016 1:57 PM > To: pfSense Support and Discussion Mailing List > <list@lists.pfsense.org> > Subject: [pfSense] Snort or Suricata > > Hi there, > > i installed Snort and let it run with snort Community Rules and ET Rules. > I get ton als Fals positiv alters. > > Maybe is suricata better? What are the difference? > > It Seems that only the ET rules has no or veryl less fals positivs. > > Cheers > > Daniel > _______________________________________________ > pfSense mailing list > https://lists.pfsense.org/mailman/listinfo/list > Support the project with Gold! https://pfsense.org/gold > _______________________________________________ > pfSense mailing list > https://lists.pfsense.org/mailman/listinfo/list > Support the project with Gold! https://pfsense.org/gold _______________________________________________ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold _______________________________________________ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
