Blog suricata-vs-snort - Snort 3.0?

musicwizard

I was reading
https://www.netgate.com/blog/suricata-vs-snort

They talking about snort 3.0 but we still have the snort-2.9.20 in pfsense.

When will this become 3.0?

michmoor

@musicwizard yeah I was confused by that also. Especially the multi threading section.
I’m thinking they were comparing the latest versions of each not what’s supported on pf…for some reason

bmeeks

Snort 3.0 is quite a different beast. It changed many things including totally revamping the way the configuration is specified. I tried twice to create a Snort 3.0 package for pfSense, but grew disillusioned both times because of the degree of difficulty. It seems to be nearly an impossible task to effectively migrate an existing pfSense Snort installation over to the 3.0 format. Too many things are just too radically different in the way they are specified in the new Lua configuration. I could never get a "clean" migration to happen, even using the provided migration utility.

You can create a Snort 3.0 package for pfSense, but migrating an existing configuration as would be normally expected via a typical upgrade is a tall order. As I said, I struck out two times and finally gave up.

Snort 3.0 also would require totally rewriting the current custom blocking module used in pfSense. The way plugins work in the new Snort 3.0 binary is completely different from the way Snort 2.9.x works. And the netmap inline IPS support in Snort 3.0 is older and does not currently support multiple host rings as does Suricata.

My current view is the only thing Snort has going for it over Suricata is the OpenAppID limited Layer 7 stuff. If Suricata ever implements a similar feature, then Suricata would be the better IDS/IPS in my opinion. Not because it "detects better" or "is more secure", but simply because it offers more logging options and has an easier interface for integrating custom plugins.

michmoor

@bmeeks Thanks for the added color. The question came about because of the recent Netgate blog post comparing both IDPS systems. It's implied that Snort 3 is available for PFsense which is not the case.
It's likely the author did not know that there are different package versions for the firewall.

musicwizard

@michmoor said in Blog suricata-vs-snort - Snort 3.0?:

@bmeeks Thanks for the added color. The question came about because of the recent Netgate blog post comparing both IDPS systems. It's implied that Snort 3 is available for PFsense which is not the case.
It's likely the author did not know that there are different package versions for the firewall.

Yes that. that is why i was wondering. First i thought oh he is compairing a old version because snort is on 4.x but that is just the package version number.

musicwizard

@bmeeks said in Blog suricata-vs-snort - Snort 3.0?:

Snort 3.0 is quite a different beast. It changed many things including totally revamping the way the configuration is specified. I tried twice to create a Snort 3.0 package for pfSense, but grew disillusioned both times because of the degree of difficulty. It seems to be nearly an impossible task to effectively migrate an existing pfSense Snort installation over to the 3.0 format. Too many things are just too radically different in the way they are specified in the new Lua configuration. I could never get a "clean" migration to happen, even using the provided migration utility.

You can create a Snort 3.0 package for pfSense, but migrating an existing configuration as would be normally expected via a typical upgrade is a tall order. As I said, I struck out two times and finally gave up.

Snort 3.0 also would require totally rewriting the current custom blocking module used in pfSense. The way plugins work in the new Snort 3.0 binary is completely different from the way Snort 2.9.x works. And the netmap inline IPS support in Snort 3.0 is older and does not currently support multiple host rings as does Suricata.

My current view is the only thing Snort has going for it over Suricata is the OpenAppID limited Layer 7 stuff. If Suricata ever implements a similar feature, then Suricata would be the better IDS/IPS in my opinion. Not because it "detects better" or "is more secure", but simply because it offers more logging options and has an easier interface for integrating custom plugins.

Snort currently works fine for me. And i was wondering multiple times why im not switching over. So not sure what i will do.

Also for the Future will this snort packaged be update with new/better/faster things? or should we switch over?

bmeeks

@musicwizard said in Blog suricata-vs-snort - Snort 3.0?:

@michmoor said in Blog suricata-vs-snort - Snort 3.0?:

@bmeeks Thanks for the added color. The question came about because of the recent Netgate blog post comparing both IDPS systems. It's implied that Snort 3 is available for PFsense which is not the case.
It's likely the author did not know that there are different package versions for the firewall.

Yes that. that is why i was wondering. First i thought oh he is compairing a old version because snort is on 4.x but that is just the package version number.

The Snort GUI package version and the underlying binary versions got out of sync quite a while back (several years ago). The GUI package is PHP code that provides the admin interface, stores the configuration parameters in the pfSense config.xml file, and then writes the configuration to a text-based snort.conf file that is created individually for each configured Snort interface. All of the traffic inspection and rules engine lives in the Snort binary piece which runs as a service on FreeBSD (or pfSense).

The current Snort binary on pfSense is 2.9.20.

bmeeks

@musicwizard said in Blog suricata-vs-snort - Snort 3.0?:

Snort currently works fine for me. And i was wondering multiple times why im not switching over. So not sure what i will do.
Also for the Future will this snort packaged be update with new/better/faster things? or should we switch over?

That is a difficult question to answer. New features are not likely because the upstream Snort team will eventually abandon the 2.9.x binary code branch. They have not yet, but to my knowledge they are only providing bug fixes for that branch now and all new features are in Snort3 (the 3.x binary code branch). As I mentioned in a previous post, there is currently no Snort3 package available for pfSense, and so far as I am aware nothing is in the works in terms of Snort3.

If Snort is currently meeting your needs, then stay with it. But just be on notice that at some point in the future, the upstream Snort team is likely to abandon the 2.9.x code branch. At that point it would become totally unsupported.

michmoor

@bmeeks said in Blog suricata-vs-snort - Snort 3.0?:

If Snort is currently meeting your needs, then stay with it. But just be on notice that at some point in the future, the upstream Snort team is likely to abandon the 2.9.x code branch. At that point it would become totally unsupported.

And then by extension, the package would be dropped from the pfsense repo i assume i would hope. (more of a statement then a question).

bmeeks

@michmoor said in Blog suricata-vs-snort - Snort 3.0?:

@bmeeks said in Blog suricata-vs-snort - Snort 3.0?:

If Snort is currently meeting your needs, then stay with it. But just be on notice that at some point in the future, the upstream Snort team is likely to abandon the 2.9.x code branch. At that point it would become totally unsupported.

And then by extension, the package would be dropped from the pfsense repo i assume i would hope. (more of a statement then a question).

Likely so, but perhaps not until some type of security vulnerability surfaced. Such vulnerabilities do not have to be in the actual Snort binary, though. It might be that later on some vulnerability is discovered in one of the shared libraries Snort uses.

This is what happened with the Barnyard2 utility in Snort. The Barnyard2 code maintainer ceased updating Barnyard2. Barnyard2 itself was fine, but it relied on the MySQL database connector shared library. The version of that library Barnyard2 used was older and identified as having several unpatched security vulnerabilities. But because nobody was maintaining the Barnyard2 package anymore, it was not updated to use newer patched versions of the MySQL library. Using the new library would have required changes in the C source code of Barnyard2. It was not as simple as just recompiling against the newer library. Consequently, I eventually dropped Barnyard2 support from Snort. The upstream Suricata team had already announced the removal of the logging option for unfied2 (U2) binary data, so Barnyard2 was also removed from Suricata.

michmoor

@bmeeks Curious but if you were not around (on leave lets say) and there was a critical vulnerability in either Suricata or Snort binaries, who would be responsible to update that? I noticed there seems to be only one maintainer for either Snort/Suricata which is you or PFblocker. Just worried what happens if either of you is not around. Who moves forward with supporting the package on pfsense?

bmeeks

@michmoor said in Blog suricata-vs-snort - Snort 3.0?:

@bmeeks Curious but if you were not around (on leave lets say) and there was a critical vulnerability in either Suricata or Snort binaries, who would be responsible to update that? I noticed there seems to be only one maintainer for either Snort/Suricata which is you or PFblocker. Just worried what happens if either of you is not around. Who moves forward with supporting the package on pfsense?

I don't know. Packages are not considered "core parts" of pfSense. Creation and maintenance of them has historically been done by volunteers who are not employed by Netgate. It is true that under some circumstances the Netgate developer team has made some changes required for a few of the more popular packages. But by and large packages are left to the volunteer maintainers. I can understand this stance because with all the pfSense users out there and the many different "favorite" or "critical" packages those different users would identify, you could keep a decent-sized developer staff busy just doing packages. So Netgate focuses on the pfSense core software, and then more or less leaves packages as optional add-ons maintained by others.

The more complex packages would be difficult for someone to assume the development duties. How easy of a task that would be is a function of how well the former package creator/maintainer documented things in the code via inline comments. I try to over do it with regards to commenting my code, but there is still a lot of the overall logic that is not documented. Programmers never like to create documentation because coding is much more fun .

Volunteer package maintainers are always welcome! While I created the Suricata package from scratch, I picked up Snort first by slowly taking over from the original creator/maintainer. He was in the process of moving on, and I had some features I wanted to see in the package (mainly the automatic use and resolution of flowbits), so I added them and submitted a Pull Request. It was accepted, so I submitted a few others over time. And eventually I just sort of fell into the maintainer role for Snort. Snort was my first package. Later, some users asked about Suricata, so I investigated that binary and decided to create a package for it as well on pfSense. So for Suricata I am the creator and currently the maintainer. But other folks have contributed to both packages in the past via Pull Requests submitted to the FreeBSD-ports repo for pfSense located here: https://github.com/pfsense/FreeBSD-ports.

The GUI package ports are located here --

Snort: https://github.com/pfsense/FreeBSD-ports/tree/devel/security/pfSense-pkg-snort

Suricata: https://github.com/pfsense/FreeBSD-ports/tree/devel/security/pfSense-pkg-suricata

The binary portion of each package is located here --

Snort: https://github.com/pfsense/FreeBSD-ports/tree/devel/security/snort

Suricata: https://github.com/pfsense/FreeBSD-ports/tree/devel/security/suricata

michmoor

@bmeeks said in Blog suricata-vs-snort - Snort 3.0?:

But by and large packages are left to the volunteer maintainers.

I hope that there will always be maintainers.
My strength has always been the 'not coding' part of tech although i can write a mean 'Hello World' in python

That said, the strength is always in the community of course. Although the warm and fuzzy part of me would always want a paid dev (cough cough bmeeks) on staff to always be around.

bmeeks

@michmoor said in Blog suricata-vs-snort - Snort 3.0?:

That said, the strength is always in the community of course. Although the warm and fuzzy part of me would always want a paid dev (cough cough bmeeks) on staff to always be around.

I'm happy not being a paid dev, already put in my 36 years at the corporate grindstone . Just doing the package maintainer duties now to keep my mind engaged. Been officially fully retired since 2014.

So at some point down the road it will be time for a new "whipper-snapper" to take over the IDS/IPS package duties. Perhaps that could start by someone developing the Snort3 package ???

SteveITS

@michmoor FYI Netgate has a package list here and maintains several.

@bmeeks Being a programmer I definitely appreciate your time involved. Probably, most non-coders do not.

Just for discussion purposes is Snort 3 a situation where it needs its own package?

Hmm, can packages be renamed? Having "pfblockerNG-devel" as the current recommended package probably means they can't? Using a package name like "snort3" could be confusing when it is using Snort version 6 down the road. "snort-gen2"? "snort-ng"?

Not even sure how to get people to switch. One last package update that adds a banner saying to use the new package, and it doesn't migrate?

I emailed our Partner contact. Maybe they can have someone update the blog.

michmoor

@bmeeks I have like...20 more years of the grind. Writing this with a heavy sigh.
That said, Would love to use the Snort3 package in an official way. One day it will come. Im sure of it.

musicwizard

@steveits said in Blog suricata-vs-snort - Snort 3.0?:

@bmeeks Being a programmer I definitely appreciate your time involved. Probably, most non-coders do not.

Kind of strange you say that. Im a IT admin and sometimes i do code just not in PHP etc. But i appreciate every code that is creating and maintaining these.

@bmeeks snort it works yes. but when there is like snort3 which is faster beter etc.

Sadly i dont have enough time to learn alle these things like PHP and how to create a package etc that would bee snort3.

Creating something is 1 thing but also maintaining and fixing bugs and things is a other thing.

bmeeks

@steveits said in Blog suricata-vs-snort - Snort 3.0?:

@michmoor FYI Netgate has a package list here and maintains several.

Just for discussion purposes is Snort 3 a situation where it needs its own package?

My personal opinion is "yes" because it is substantially different technology under the hood. All the configuration is done via Lua files, and it is multithreaded where Snort 2.9.x is not. The mismatch between the current Snort binary version and the GUI package version numbering is my fault from a long time ago. With Suricata I have been striving to keep the major GUI version equal to the underlying binary. Hence 6.0.8_x currently in pfSense development snapshots and 6.0.4_x in release. These major version numbers in the GUI package match the underlying version of the Suricata binary.

With pkg, it's the version number that matters in addition to the name. The higher versions are considered "newer", so once you release a 3.x something package, you can't go back to 2.x something because pkg will always think that is an older version. Remember Snort was my first package maintainer duties, and I did not think far enough in advance when I was making lots of updates and creating new versions. I have tried to not repeat that mistake with Suricata.

Hmm, can packages be renamed? Having "pfblockerNG-devel" as the current recommended package probably means they can't? Using a package name like "snort3" could be confusing when it is using Snort version 6 down the road. "snort-gen2"? "snort-ng"?

I will not judge the use of "devel" in the name of the most current release of pfBlockerNG. It is something I personally would not encourage, though. I think it is very confusing to users conditioned by the way most other software works. You normally don't expect a "devel" version of something to be the one that is really the most current and suggested for production use. I think it would be very bad to create a Snort-NG or Snort-devel package and have it alongside the release package in the same repo. To the best of my knowledge, pkg cannot rename an existing package. You can create totally new ones, but you can't rename existing ones. You can, however, remove packages or mark them as deprecated. That is the proper way to do things in my view.

I don't think a Snort3 package would be confusing. It would actually immediately identify the underlying binary. At the time there was never a consideration of Snort3, and I was a rookie anyway, but in hindsight it might have been useful to name the current Snort package on pfSense "Snort2-xxx" instead of simply "Snort-xxx". Then whenever Snort4 comes along, you do the same.

Not even sure how to get people to switch. One last package update that adds a banner saying to use the new package, and it doesn't migrate?

You mostly get them to switch by removing the old package. That would not make pkg remove it from their firewall, but there would never be another update available for that version. That's the way pfSense handles packages today when a new release of pfSense comes out. The pkg repo for the old pfSense version is frozen and never gets any updates. Similarly, if a completely new version of a package emerged (say Snort3 is out and you wanted to deprecate Snort2) you could just freeze updates for the older package for a time, then remove it from the repo so users could not even install it anymore. Of course you would want to communicate this information. And probably somebody would complain about it, but such is life in the world of software -- time marches on whether it is convenient for you personally or not .

michmoor

@steveits said in Blog suricata-vs-snort - Snort 3.0?:

FYI Netgate has a package list here and maintains several.

Thanks for this. What would it take for packages to be moved to the 'Maintained by Netgate' status?
I noticed some are just supported by install or custom config which isnt the same as maintained.

SteveITS

@musicwizard said in Blog suricata-vs-snort - Snort 3.0?:

Kind of strange you say that. Im a IT admin

I probably phrased what I said poorly. It wasn't meant to be an insult, just that programming often takes a lot of time.

@michmoor said in Blog suricata-vs-snort - Snort 3.0?:

What would it take for packages to be moved to the 'Maintained by Netgate' status

No idea. They do help on pfBlocker occasionally, I think I've seen, not sure about others. One might think a popular package without a maintainer would be to Netgate's advantage to keep running.