💾 Archived View for gemini.circumlunar.space › users › kraileth › neunix › 2021 › bsd_router_take_2_… captured on 2022-04-28 at 19:10:17. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-05)
-=-=-=-=-=-=-
Friday, 30. April 2021
[This article has been bi-posted to Gemini and the Web]
After I completed the previous article, Franco Fichtner announced that OPNsense and HardenedBSD will be parting ways:
I'm happy to see that they are parting ways in good terms. So there at least were no ugly things going on behind the curtain. The explanations given in the announcement are interesting and I'd say that they make sense. This is a pretty massive change, though. And since (thanks to the friendly Web UI) OPNsense is used by a lot of people who do not have a FreeBSD background, I'd like to explain in a bit more detail what the actual situation is like.
In the first series of posts, the second one was an excursion on using the _serial console_. This time we're going to take a look at the broad topic of _security_.
Serial console excursion (2017)
FreeBSD has had incredibly talented security officers like Colin Percival, founder of the _Tarsnap_ backup company. His company's motto is "Online backups for the truly paranoid" - and it lives up to that. Thanks to him and many great people in the security team, FreeBSD has built up a fairly good reputation regarding security with a lot of people.
There are other voices, too. For example one former FreeBSD user who switched to OpenBSD is industriously working on making FreeBSD look bad. Here's the homepage where he keeps track of all the things _he thinks_ FreeBSD does wrong:
FreeBSD - a lesson in poor defaults
So which claim is true then? Is FreeBSD doing pretty well or is it downright horrible?
Both of them. And neither. Oh well... It's a bit too complicated to give a plain and simple answer. So let's think about what "security" actually means for a moment before returning to judge FreeBSD's performance in that area.
There are multiple aspects to security. To take the whole situation into consideration means to admit that we're in one giant mess right now!
We absolutely depend on today's technology. Think about replacing "the Internet" for example. Even if you have this exceptionally great idea and can provide a concept that is totally sound - how do you think we could get there? Millions of enterprises require the Internet as we know it to continue working as it does. The chances of succeeding with establishing something better that would run in parallel? Basically nonexistent. Nobody could pay for such a huge project! And even if it were to magically appear and be available tomorrow (somehow production-ready by day one), how do you think getting a critical mass of businesses to adapt it?
Incrementally improving what we have is hard enough. If you disagree just think about disabling anything but TLS 1.3 on your employer's webservers. _You_, dear reader, are probably ready for such a change, I wouldn't doubt that. But are all your customers? And that's only one example of... many.
While being condemned to never being able to "re-invent the wheel" in large scale is unfortunate, it's not catastrophic. What _is_ catastrophic however is that the very foundations of the technology we're using today were very much overcredulous from today's point of view. It's perfectly reasonable not designing network protocols for security when you don't think of potential offenders because your network is either limited to one institution or basically to a couple of universities! We've outgrown those innocent times for a long time now however. The Internet is a war zone.
If you feel brave, join us and participate in our Gemini experiment. If you're reading this article via a proxy, get a native Gemini client. Ideally get your own gemlog started and share original content with the world. While we're not even dreaming of replacing the Internet with something better - even the very act of challenging the Web alone by providing an alternative for like-minded people who loathe superfluous complexity, is an Herculean effort in and of itself.
But back on topic. Retrofitting security into existing technology that's already in production use is incredibly hard. Especially if you are supposed to *NOT* break the former! And if it wasn't hard enough, this scenario also comes with the curse of _optional security_ which is another pretty sad story by itself... Your DNS server probably supports DNSSEC by now. But does it use DANE (mine doesn't, yet...)? And how many of the more popular nameservers on the Internet do? I mean, it's been almost a decade since it was introduced. We need regular "DNS flag days" to force people adapting _somewhat_ acceptable DNS standards. How much can we expect _optional_ security features to come to wide-spread use?
And if all of that wasn't bad enough, in 2018 we learned that the one most important CPU architecture (x86) has a flawed design that dates two decades back... If you want to refresh your knowledge of what Meltdown and Spectre are, here's an excellent read (explained so that each and every layman can understand it) by the aforementioned Colin Percival:
Some thoughts on spectre and meltdown
Another point is that while almost everybody tends to agree that security is "important", few want to actually spend money or effort to improve it. Reading last year's FOSS Contributor Survey of the Linux Foundation gives you an idea of _how bad_ the state of affairs really is:
It's _2.3 percent_ (on average!) of a developer's time that is spent on work to fix security-related issues in their projects. If you assume a paid developer working 9-to-5, that's about _11 minutes_ per workday, adding up to not even an hour a week... It's a clear trend to rather work on exciting new features than fixing bugs in existing code. Working on security-related bugs is even less popular. How many people with such a mindset would you expect to _proactively audit_ their code for flaws regarding security?
We set sail and started exploring silent waters around the coast with a pretty much experimental boat. It has been a very _exciting_ ride - because at some point we realized that we were no longer near the coast but somewhere in the middle of the ocean. So what was really a nice toy before has turned into a necessity for us to survive. Quite a while ago we noticed that we were in stormy water and that we had to constantly fix our humble boat when the force of another tide tried to smash it! We're constantly fixing new leaks and fighting off dangers that nobody really anticipated. And to make it even worse, while a lot of people were interested in tuning our boat for performance, they didn't want to see that the water around us started boiling. Today we're surrounded by lava. There is no lifeboat. If you shipwreck, you're dead.
That picture should have either reminded you of what you already knew - or have been eye-opening regarding our situation. There is no need to panic (that wouldn't be helpful), but don't fall into the trap of simply dismissing the shadowy dangers. They are very much real! So whatever helps your employer survive in this situation could be thought of as a _security feature_.
There is no single panacea but combining a lot of security features can drastically lower the threats. Here are some important bits:
When it comes to patching base system vulnerabilities, FreeBSD is generally doing well (there's no point in denying that things do not _always_ work like they should so that blakkheim can point a finger at it). If you've never read a security advisory as published by the FreeBSD project, I suggest you do so at least once to get an idea. The latest one is this one:
As you can see, the security team does not only silently fix bugs but even goes an extra mile, doing a write-up for the interested reader. For years I've been very happy with those; I'm not a developer with sharp C skills and deep knowledge of *exactly* how programs work, but I can always understand what's going on there. I'm not spiteful enough to ask you to compare them with OpenBSD's errata which are... very bare-bones.
If you take a closer look at the example provided here, you can see that among the versions that received a fix is _13.0-RC5-p1_. That's right: This means that they even cared enough to fix it for a _Release Candidate_ that has a lifecycle of two weeks! And not only that, they even provided binary updates for that even though people on RC5 could just be expected to update to 13.0-RELEASE only a couple of days later. I'd say that this is nothing short of very commendable acting.
Regarding packages that are not vulnerable, the situation with FreeBSD is a mixed bag. There are quite a few unmaintained ports stuck at older, insecure versions. Common software is usually pretty recent. To give you an idea (and so that you don't simply have to take my word for it), let's compare FreeBSD and Ubuntu 21.04. FreeBSD currently has a port count of slightly above 31,000 whereas Ubuntu offers just short of 33,000 packages. A little over 6,000 are outdated on FreeBSD, for Ubuntu it's over 8,500. For ports beginning with the letter "A", FreeBSD has 9 ports with versions that contain a known vulnerability (with a CVE) that could be fixed by updating to a newer version whereas Ubuntu has only 3. Same thing for ports that begin with "Z": 1 vulnerable port that could be fixed by updating to a newer version on FreeBSD, 2 such packages on Ubuntu.
Just so nobody claims I'd selectively present data to support either story with it, here's a table for package CVEs of all starting letters (FreeBSD first, Ubuntu 21.04 second):
A: 9 / 3
B: 3 / 3
C: 4 / 7
D: 2 / 4
E: 3 / 0
F: 4 / 1
G: 9 / 5
H: 2 / 2
I: 3 / 4
J: 8 / 3
K: 0 / 1
L: 12 / 13
M: 8 / 3
N: 2 / 18
O: 4 / 6
P: 18 / 17
Q: 0 / 0
R: 8 / 13
S: 8 / 10
T: 5 / 7
U: 2 / 2
V: 2 / 2
W: 3 / 2
X: 3 / 5
Y: 1 / 0
Z: 1 / 2
Total: 125 / 133
I think it's safe to say: FreeBSD does pretty good in this field, too! Especially if you take into consideration that most of FreeBSD's ports are done entirely by volunteers and that while software usually "just works" on Linux there's often some more work required to _make it work_ on other operating systems! (Of course I'm aware that I'm just scratching the surface here and a deeper analysis would be nice - but that would definitely take its own article.)
Let's talk about means of hardening the system. There's a lot you can do to harden a system that was installed using the default options. For a while now (I think starting with 11.0) FreeBSD offers a hardening dialog in the installer, allowing for really simple improvement of the defaults. This is one thing that blakkheim prefers to ignore: Yes, /tmp is not cleared by default, but FreeBSD can do that _if you want it to_ and it's not hard to make it do that.
Yes, hardening a FreeBSD system is not something you can expect the junior admin to master in a couple of hours. But that doesn't mean that it's impossible to do. With _securelevels_ and _file flags_, FreeBSD gives you a powerful tool for increased security. _Capsicum_ and _casper_ are two more things you can take a look at and start making use of. Taking advantage of jailing applications is another great way to make your infrastructure more secure by confining possible intruders and further limiting the damage they can do. FreeBSD expects _you_ to do all that and more, depending on what your security requirements are.
Definitely have a look at security(7). To quote from it:
A little paranoia never hurts. As a rule, a sysadmin can add any number
of security features as long as they do not affect convenience, and can
add security features that do affect convenience with some added thought.
Even more importantly, a security administrator should mix it up a bit —
if you use recommendations such as those given by this manual page
verbatim, you give away your methodologies to the prospective attacker
who also has access to this manual page.
Does that really sound like it's written by people who do not care for security at all as our friend blakkheim wants you to believe?
So far for the good part. The ugly side of FreeBSD will be covered next time as this article is already way too long. Thanks for reading!
The next post will briefly discuss FreeBSD's security weaknesses and how HardenedBSD fits into the picture. I'll also address the "rebase it on OpenBSD!" suggestion some people have made.