How secure are the packages
-
@bmeeks said in How secure are the packages:
I think many users lose sight of the fact pfSense CE is totally free as are the add-on packages. Thus neither generates any revenue for Netgate.
Couldnt agree with you anymore here. To be fair to users I think most don't understand the package support structure so they assume that if it's part of the ecosystem then its supported. To believe otherwise hasn't been made clear in any way. So to most, if there's a problem in a community package "Oh netgate will help let me submit a redmine" but that's not how it works.
I do want to say that a strong delineation of the CE and Plus versions would help. The sister project, TrueNAS does something similar (Core vs Scale) but its fair to say they make it a point to tell you whats community supported and whats meant for enterprises. -
@michmoor lurking on by, there’s a list at https://www.netgate.com/supported-pfsense-plus-packages
-
@SteveITS
Yep. +1 on this.
I try to make it a point to stick with the 'Maintained by Netgate' packages as best i can.Firewall: NetGate,Palo Alto-VM,Juniper SRX
Routing: Juniper, Arista, Cisco
Switching: Juniper, Arista, Cisco
Wireless: Unifi, Aruba IAP
JNCIP,CCNP Enterprise -
@michmoor said in How secure are the packages:
The support of community packages has always worried me with pfsense. I generally don't install a package unless I'm willing to maintain it long-term and I'm not a coder
@michmoor said in How secure are the packages:
it probably makes sense to run the reverse proxy on a separate system then
My interpretation is a bit different.
If pfsense with current packages is a good solution to a businesses requirement then use the current offering provided if support for a potentially non core package is lost then an alternative solution is available which maybe- get someone else to step up and maintain the package, or
- add an external device or VM to provide that function.
So in summary, it there is an external solution to a pfsense package, then potential loss of future support for a package may not be a real barrier. In addition if the only sensible solution to a functional requirement is firewall functionality / or a package then support for the package becomes more critical.
-
It’s all open source software nothing to hide here… so yeah they are secure, plus if you find a bug
everyone helps fix it too. Super secure -
@JonathanLee said in How secure are the packages:
It’s all open source software nothing to hide here… so yeah they are secure, plus if you find a bug
everyone helps fix it too. Super secureSounds like you might need to read up on the
xz-utilsbackdoor
. That one got into some BETA/RC pipelines and was just about to get pushed out everywhere when it was discovered almost by accident.Thinking open-source software is secure "because everyone is looking at the source code" is not a valid supposition. As I mentioned earlier, the code is now so complex, and the development environments and associated tools are so varied, that hardly anybody is actually looking at the code and really understanding what it does. Do you know what is in the Snort package code you are using? Have you analyzed it to see if there are any backdoors in the binary piece or the PHP piece? I'm guessing not. You are depending on others to do that for you. But those "others" may themselves be assuming that "others" are looking so they don't have to, and on it goes with the final result being pretty much nobody is really looking. A ton of the open source stuff is really dependent on just one or two core maintainers on GitHub.
Don't misunderstand my comments to mean I am against open source software. On the contrary, I think it is a great thing. But to think open source is inherently more "secure" than closed source is not really valid these days.
-
@bmeeks that XZ bug was bad, glad the community caught it.
-
@JonathanLee A Microsoft developer caught it
-
@michmoor did you fix the RE update issue yet? That update required a full repartition of the RE with a format to expand it. That was a nightmare I think that a big bug was hiding in the RE (recovery partition) the one I always go on a tangent for the invasive containers, the cache stopped seeing random stuff after I wiped out the RE and rebuilt it. I wouldn’t worry about it unless you can’t install the updates. Windows 10 stuff. They wanted me to just reinstall to get rid of it I refused because I wanted it fixed permanently on all systems. Now it’s working perfect, Microsoft fixed it !!!
-
@JonathanLee
Huh? -
@michmoor said in How secure are the packages:
I try to make it a point to stick with the 'Maintained by Netgate' packages as best i can.
I think 'Maintained by Netgate' is a bit of a misnomer.
Most of the packages have two categories of components. The first category is the pfSense package itself, named pfSense-pkg-XXXXX. This package generally contains php, xml, and html code. There are a few of these that Netgate directly maintains, but most are maintained by volunteers.
The second category is usually the underlying XXXXX package and its dependencies. These are generally external projects, and not maintained by Netgate. Netgate may make contributions to these projects, but they do not own them. They have their own maintainers.
The point is that all the packages, even the simple ones, have substantial supply chains behind them that is outside of Netgate's control. That Netgate maintains the php, xml, and html code really doesn't make them any safer.
-
@dennypage
Thanks for the background Denny. Pfsense package has always remained an interesting area for me as it pertains to the overall platform security.
You and Bill gave really good info on this.So where does that leave us overall at least to my original question? Do we continue to use packages on the firewall in my case HA Proxy and just be mindful that it’s still an external thing with its own set of challenges or are there at least ways that pfsense can silo these packages so if there are issues the blast radius isn’t the entire system? That’s the part I’m not clear on.
-
@michmoor said in How secure are the packages:
So where does that leave us overall at least to my original question?
If you install the pure pfSense either 23/24.xx or 2.7.xx version and you
may not install any package, you perhaps tend to setup squid and
other software external and if this is also OpenSource software you
may standing then also again in front of the same "door" trust or not.So it is more or less the question to trust opensource software or not and
when you do, wich software exactly.Do we continue to use packages on the firewall in my case HA Proxy
and just be mindful that it’s still an external thing with its own set of
challengesTrusting Squid & SquidGuard & ClamAV internal or external where should
be the difference, I mean if you trust it, you can install it on the pfSense
or external like you want, must or need it, but the "thing" with the trust
you must answer even internal or external used.or are there at least ways that pfsense can silo these packages so if there are issues the blast radius isn’t the entire system? That’s the part I’m not clear on.
The given ability to set up pfSense as a pure firewall or "pimp it up" to
a fully UTM device make it in my eyes in real interesting! And it is only
based on the taken hardware that you will be able to serve for home
only till bigger companies. -
I am gonna say they are secure, I like that it is open source so nothing is hidden, you can look at anything.
Make sure to upvote
-
@Dobby_ makes an excellent point. You either trust the open-source world and the packages on pfSense -- or you don't. Whether it is installed on the firewall or run on separate hardware is not hugely significant in the grand scheme of things if the flexibility of UTM is what you seek.
True that anything "extra" installed on the firewall constitutes an additional attack surface, and a weakness exploited from that could lead to a bad actor having some level of control over the firewall itself. If the "extra" software is installed on a separate machine, then only that host machine is likely to be compromised by an exploit.
So, there will always be trade offs. Is flexibility and maximizing the use of a single hardware platform more important to you, or is absolute security what you strive for? The answer to those questions determines your course.
In my mind, the biggest consideration when using a third-party package on pfSense is how severe is the impact to your security posture if the chosen package were to suddenly disappear (or otherwise become unsupported). @dennypage did a good job explaining that most packages on pfSense actually consist of two pieces: a GUI part written in PHP and sometimes with XML and JavaScript woven in, and then a binary portion that comes from a totally separate source. I'll use Suricata as a example of how this shakes out.
When you install the Suricata package on pfSense, what you actually specify is the package
pfSense-pkg-suricata-x.xx_x. But this is only the GUI component that you interact with in the pfSense GUI. It is written entirely in PHP with a little sprinking in of JavaScript for client-side functionality. It has absolutely nothing to do with analyzing traffic or creating the alert logs. That part is handled by thesuricatabinary that comes from the FreeBSD ports tree. Thepkgutility reads the manifest associated with the GUI portion of the package and determines what additional packages it needs to download and install to make the chosen package functional. One of those is thesuricatabinary package.The FreeBSD ports tree has its own maintainer for the Suricata binary port (actually it happens to be the guy who programs for OPNsense). He imports and then modifies as necessary the
suricatabinary package from OISF (the folks who created and maintain the Suricata binary). Then there is another wrinkle in pfSense. Because I implemented a custom blocking mode for the binary (Legacy Mode Blocking), I wrote my own output plugin that is compiled into the Suricata binary only for use on pfSense. There is a custom patch that is applied to only the pfSense version of Suricata that tacks on the custom blocking plugin for Legacy Mode blocking. See how complicated this has gotten? Lots of folks involved to make this all work. And Snort works pretty much the same way just with a different upstream FreeBSD ports maintainer.This complexity means any one of three things could result in Suricata disappearing. First, OISF could drop the product. That would mean no binary and thus no functionality. Second, the FreeBSD port maintainer could disappear and that could result in Suricata becoming orphaned in the ports tree with nobody maintaining it. That's more or less what happened to Squid (and also to the Barnyard port formerly used in Snort). Because pfSense pulls its package binaries from the FreeBSD ports tree, if a port becomes orphaned there the impact is immediately felt in pfSense. And finally, on the pfSense side, if I were to disappear then Suricata would also likely slowly die as it would cease to be updated. Nearly all the pfSense packages operate in the manner thus described (although probably very few have custom patches like the IDS/IPS packages).
Later Edit:
To finish and wrap this up so it meshes with the overall discussion of package security, consider that with a package like Suricata there are at least three distinct "supply chain" exploit insert points.- First, some malware could get slipped into the OISF source tree. As this is the root upstream source for FreeBSD ports, that would mean anything using the code from FreeBSD ports would be compromised as soon as the tainted Suricata update was merged into FreeBSD ports.
- Second, the FreeBSD ports maintainer could slip in a piece of malware. This would mean users of Suricata on FreeBSD or its derivatives (think pfSense) would potentially be compromised.
- And third, I as the custom plugin maintainer for Suricata on pfSense could slip in some piece of malware and thus compromise any pfSense box using the package.
So, three possible supply chain exploit insertion points for just a single package. Multiply this by the number of dependent libraries most packages use and you can begin to see the enormity of the potential issue. The Suricata binary by itself has maybe a dozen or so shared library dependencies it incorporates into an installed instance.
-
@JonathanLee said in How secure are the packages:
you can look at anything.
But my point here was that if you don't know what you are looking for, does it really matter that you can look?
In the
xz-utilscase, the actual malicious code got inserted during the binary build process by the M4 macro used by the development environment tools. It never did actually exist as cleartext in the C source code. You would need to be quite conversant and experienced in the M4 and autotools compilation and linker process to have discovered this. And the Microsoft guy who discovered it did not find it by just chance looking at the M4 macro. Instead, he noticed some peculiarity in the behavior of SSHD on an already infected system and went looking for what changed. -
@JonathanLee It is unsafe because your can look at anything but it seems few if any do and you need to know what you are looking for. From an old-fart code jockey "None of this is remotely easy".
Ted
-
I think I’m good with all the questions/concerns I had. This thread really evolved into a meaningful discussion on package maintenance. Thank you all who participated in the Ted Talk haha.
Seriously, great conversation and enlightening. -
@bmeeks said in How secure are the packages:
Sounds like you might need to read up on the xz-utils backdoor
@bmeeks said in How secure are the packages:
Thinking open-source software is secure "because everyone is looking at the source code" is not a valid
I agree everyone is not looking at the code, which is the same as closed source software. The difference is everyone can look at the software if unexpected behaviour occurs.
An xz-utils backdoor type exploit could occur with open or closed software. The risk of detection of a prolonged national actor are probably similar.
The difference between open and closed source is probably greater for a private company policy. Such as something which is against user requirements but provides a benefit to the company maintaining the code. The obvious examples are data harvesting by Google, Microsoft and other companies who sell information.
-
We had a talk about this in class once, open source has open source community, closed source is closed source community. Yes it is hard to understand massive amounts of code and to comb it for anything again, when many open source community members work on code it is tracked in GitHub, changes have to be approved, bugs can be reported. Closed source you don’t get that visibility. You can’t look or even attempt to inspect code, I originally was going to get a closed source firewall and I went with Netgate because of the community, this community. A closed source system will never have a community like this with discussions all open to the public. I have started to trust the open source more over closed code because people are generally good. You can be as involved as you want or a as little, one things for sure any questions you have get answered.
