Blog suricata-vs-snort - Snort 3.0?
-
@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-basedsnort.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.
-
@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.
-
@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).
-
@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.
-
@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?
-
@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
-
@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 pythonThat 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.
-
@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 ???
-
@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.
-
@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. -
@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.
-
@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 becausepkg
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. Thepkg
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 . -
@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. -
@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.
-
@steveits said in Blog suricata-vs-snort - Snort 3.0?:
@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.
Netgate is probably not eager to step in and take over a package mainly because they already have plenty of work on their plates maintaining TNSR, CE and now Plus core pfSense software.
They have stepped up and made quick fixes to popular packages when some pretty significant show-stopper issue surfaces -- as in the package won't install or run at all, or has some other major defect. I think this has mostly happened when the normal package maintainer is not immediately available.
And there are some packages that were actually created by Netgate staff. Service Watchdog is one that I recall, and I think Acme is another. Those packages were created to fill specific niches. OpenVPN Client Export is another such package.
-
@steveits said in Blog suricata-vs-snort - Snort 3.0?:
One might think a popular package without a maintainer would be to Netgate's advantage to keep running.
Agreed. Better to have it written on 'paper' for it to be official.
-
@bmeeks said in Blog suricata-vs-snort - Snort 3.0?:
Netgate is probably not eager to step in and take over a package mainly because they already have plenty of work on their plates maintaining TNSR, CE and now Plus core pfSense software.
This is one of those areas where I understand a bit. I agree with what you are saying completely. With limited time and resources its all about where to throw the bodies to fix or improve core features.
Users want more apps on top of what's available and i get it. At the end of the day, the devs and maintainers are doing the best they can. -
@michmoor said in Blog suricata-vs-snort - Snort 3.0?:
@bmeeks said in Blog suricata-vs-snort - Snort 3.0?:
Netgate is probably not eager to step in and take over a package mainly because they already have plenty of work on their plates maintaining TNSR, CE and now Plus core pfSense software.
This is one of those areas where I understand a bit. I agree with what you are saying completely. With limited time and resources its all about where to throw the bodies to fix or improve core features.
Users want more apps on top of what's available and i get it. At the end of the day, the devs and maintainers are doing the best they can.And certain features can actually work better not as add-on packages but as core constituents of the system. That's how Suricata is handled on OPNsense. It is always there as a core component, and the user has the option of enabling it or not. But the code is a part of the base system install. It's similar to how the DNS Resolver and DNS Forwarder are handled today in pfSense.
So I would expect that if the features of a particular package were very popular and almost all users installed that package, and it became associated with "pfSense" itself, the functionality of the package would be absorbed into the base system.
-
@bmeeks said in Blog suricata-vs-snort - Snort 3.0?:
So I would expect that if the features of a particular package were very popular and almost all users installed that package, and it became associated with "pfSense" itself, the functionality of the package would be absorbed into the base system.
How difficult is it getting a package intergrated? Id imagine Suricata and pfblocker are the most important and popular package to date.
-
@michmoor said in Blog suricata-vs-snort - Snort 3.0?:
@bmeeks said in Blog suricata-vs-snort - Snort 3.0?:
So I would expect that if the features of a particular package were very popular and almost all users installed that package, and it became associated with "pfSense" itself, the functionality of the package would be absorbed into the base system.
How difficult is it getting a package intergrated? Id imagine Suricata and pfblocker are the most important and popular package to date.
It's not a terribly difficult task to actually integrate, but testing everything to be sure hidden bugs did not break something huge would be time consuming.
While Suricata and Snort both seem popular now, to be honest I really don't understand why that is so on pfSense. The vast majority of network traffic today is encrypted. That means without MITM the IDS/IPS is almost blind. It can see source and destination IP addresses and ports, and it can see a little bit of what's going on via the SNI header when that is present, but that's about all it can see for encrypted traffic. There is currently no built-in pathway for the IDS/IPS to see unencrypted data even when MITM is in place. Creating such a pathway would require some major reworking of the internal network plumbing of FreeBSD. If I were Netgate, I would not really consider the effort involved in bringing an IDS/IPS into the core system worth it over the long term. To make it really functional, you would also need to rework the network stack AND offer a ready-to-go MITM setup.
The features of pfBlockerNG-devel would be a more natural fit.
I personally believe that most protections are going to have to move more to the endpoints and be used less (and eventually almost not all) on the network perimeter.