How secure are the packages
-
@bmeeks
Please educate me bill. Running as root is bad right? -
@michmoor said in How secure are the packages:
@bmeeks
Please educate me bill. Running as root is bad right?Well, everything is somewhat "relative". Certain things must run as root to even work properly, so I don't guess you could legitimately call that "bad". It's just the way it works.
If you want a completely locked down firewall, then run absolutely nothing on it except the
pffirewall engine (in the case of pfSense) and the bare minimum of other stuff (something likedpingerandradvdif you need it for IPv6). But DHCP and DNS would both be off on completely separate boxes, Ditto for any bandwidth monitoring stuff. If you want that, configure it on a separate "inline" box arrangement. Same goes for IDS/IPS: put it on a separate inline server.But for the typical pfSense use case this starts to get terribly expensive in terms of hardware and quite difficult to maintain due to complexity. Thus, most admins will cheat some amount and run stuff on the firewall itself.
To be honest, an open-source firewall is not what most large corporations and business users gravitate towards. They want big name vendors with well established track records and paid cradle-to-grave support contracts. Of course you pay big money for this level of "stuff", but for Fortune 500 corps and large enough businesses it is judged as worth what it costs.
To be sure the recent kerfuffle over the
xz-utilsbackdoor has cast a large cloud over the former blissful ignorance of the open-source software industry. While in theory open-source means the code is published and anyone can view it and see what's in it, the reality is that today's software is so complex, and there are so many different programming languages and development ecosystems, that pretty much nobody has a clue what's in the open-source software they are blindly using. So, if the recent problems brought to light in thexz-utilsfiasco worries you enough, then you should likely abandon open-source software and throw your lot in with a major closed-source vendor and hope for the best
. Because no software- whether open-source or closed-source - is immume from potential compromise.If I'm just protecting my home network, or some small non-profit or mom-and-pop business, then an open-source tool such as pfSense is fine and I make the compromises necessary to keep it easy to maintain (that means don't change much, if any, of the default settings). But if I were back in my old job before I retired, then it would be Checkpoint, Palo Alto, or someone similar that I would be dealing with. In fact, my former employer had a policy prohibiting the use of open-source software in any critical company function. The closest thing we had was some Linux stuff, but it was mandated that only Redhat Enterprise Linux (RHEL) could be used and we had to have a paid support contract in place. The suits in the executive suite want another large company with its own "suits" that they can sue if the poo-pah ever hits the fan and goes everywhere
. You don't have that scapegoat when you use open-source software. -
@bmeeks
Lots of things to digest here. Dont want to get into the weeds of where an OSS product would be used or could be used.
I do agree that when dealing with an org with a budget the reality is that pfsense is not sitting in-line anywhere. Exceptions to the rule and there is probably a case to be made where it makes sense to migrate from a Fortigate or Checkpoint to a pfsense. Networks are like snowflakes. Each is different with different motives.To digress for a moment, I'm working in a business where they want to virtualize all the things..NFV for anything that passes a packet. Lots of technical debt for a bunch of engineers who don't have experience in operating and securing a virtualized world yet here I am deploying vmware and vsphere and virtualizing a firewall. Throwing my lot in with big established vendors doesn't always guarantee a successful outcome. Just because something is done doesn't mean it always makes sense to do so. PFsense has its place at certain businesses but sometimes money dictates design.
Overall, to bring it back to the packages it sounds like they are as secure as they can be, and depending on the amount of technical debt I want to ingest would determine if I want to split up all the functions that pfsense provides out of the box?
edit: I worked at a fintech company that for the most part was pretty enterprise-y. Ran the Ciscos and Palos. But when it came to the OS running their business applications it was Centos all day. Apparently, RedHat was deemed to expensive and there was a considerable amount of staff that were experienced enough in Linux.
Side note. 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....haha..
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:
Side note. The support of community packages has always worried me with pfsense.
This is the most important potential issue that should be thoroughly analyzed before committing to use packages as part of a business installation with pfSense. The packages are maintained by volunteers who are not affiliated with Netgate. It's pretty much all free effort and labor from these maintainers. And a maintainer can disappear at any instant. That leaves packages to wither and die. The Squid package family is the most recent example of such an event. There have been a few others in the past as well. For example, if I left the ecosystem tonight, then both Snort and Suricata would likely wither and die quite quickly. There is nobody waiting in the wings to pick up support and maintenance of either of these packages. Ditto for a package such as pfBlockerNG.
-
@bmeeks
Im glad we are on the same page there.
I always thought that popular packages such as pfBlcoker or Suricata are operated under a consultant type of relationship due to the inherent value-add and popularity these packages offer. So you have billable hours towards the package and get paid in return. In my mind that makes sense and ensures some level of support. Im not a businessman so perhaps it cant work like this.
That said, pfsense should probably operate under default conditions then to ensure a base level of security without technical debt. In other words, don't install packages. Bringing it back to my initial post, it probably makes sense to run the reverse proxy on a separate system then.Bill, you should know we appreciate you and we know you do this for the love as you stated numerous times. So thank you for always taking the time out to answer questions and provide insight.
-
@michmoor said in How secure are the packages:
you have billable hours towards the package and get paid in return.
Not how it works -- at least not for any package maintainer I'm aware of. I've never been paid a dime for my work on Snort or Suricata. I did get gifted an SG-3100 once in the past to debug a problem with Snort on 32-bit ARM hardware. Later I was also given an SG-5100 as a gift. That's as close to being "compensated" as I've gotten for my work on the IDS/IPS packages.
But to be fair, I've never asked to be compensated and really do not desire it. If I were compensated, then I would feel a strong obligation to continue the work. As it is, I've been doing the work for free because I enjoy it and don't mind contributing my efforts to the greater pfSense community. But I am also free to move on to something else if I desire without having the strings of compensation and its expectations attached.
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. I believe that's why the move to pfSense Plus happened, and I expect that to pick up speed. It is totally unrealisitc to expect Netgate to support all of the third-party add-on packages available for pfSense for free. That would keep a small army of programmers busy full time with absolutely no incoming revenue from their efforts. Netgate is focused on the core pfSense product (and primarily on pfSense Plus). Any work they do on packages is usually limited to just the packages they use as part of the core functionality (think OpenVPN and Wireguard, for example).
-
@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
