How secure are the packages

[Dobby_]

@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
challenges

Trusting 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.

[JonathanLee]

I am gonna say they are secure, I like that it is open source so nothing is hidden, you can look at anything.

[bmeeks]

@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 the suricata binary that comes from the FreeBSD ports tree. The pkg utility 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 the suricata binary 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 suricata binary 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.

1. 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.
2. 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.
3. 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.

[bmeeks]

@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-utils case, 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.

[tedquade]

@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

[michmoor]

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.

[Patch]

@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.

[JonathanLee]

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.

[Dobby_]

@JonathanLee said in How secure are the packages:

I am gonna say they are secure, I like that it is open source so nothing is hidden, you can look at anything.

May be also a good point, but if you are running a business suite or software
they are also taking care to serve patches, bugfixes and write then something
like updating is "highly recommended", because they earn their money with it.

[JonathanLee]

@Dobby_ again I don’t have the free version of pfSense I paid so there are other options I have closed off to the free version. So somewhat closed source

[Dobby_]

@bmeeks
For sure you will be right with it, it is a long line of points where "bad code"
will be able to enter in the entire process and/or product. But in real life, from
the point of an customer or plain user it is more or less how fast they react
and they handle those things as I see it.

The OpenSource is offering the Source Code free to watch over,
the closed Source is from the vendor and more hidden for sure
this alone makes a difference for many peoples, but trust you
must both of them (or not).

If you maintain all by your self, let us say Netgate is hires 20 plugin
maintainer and all comes from their own hand now, at the FreeBSD
site and on top of all at the found site (Snort, Suricata, Squid....)
will be also anymore points were bad code can be running in.

@michmo
But fine that it is able to do (discuss) and got not suppressed, even
cool to see or hear how others will be thinking on those things and
wich points they are bringing in.

@JonathanLee
It is not really long ago, but in 2024 we all can say it is since a
longer period able to build for a SMB company a network fully
based on OpenSource Software. And for sure the code is open
to watch over, but if the code writer gets a family at one day,
or must work elsewhere more it is also more a risk that the
entire project goes down at one day.

With FreeBSD or Linux, LibreOffice, OpenOffice, Univerntion server,
Zaraffa, OpenWRT, ClearOS and pfSense you were not pressed
anymore to run closed software at all and build a network for
your company, but also have a look on mOnOwall or ZeroShell
and others they were at one day gone. And then? You start again
what is serving me and my needs at the best and who I am
trusting now.