Is there any security benefit to moving a WireGuard bastion from fully patched Ubuntu to FreeBSD?
Is there any security benefit to moving a WireGuard bastion from fully patched Ubuntu to FreeBSD?
$ openssl version
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)
Until the 1st?I plan on using FreeBSD bastions.
Its fine to like BSD, I just wish people were willing to be honest any say it's based on their personal and philosophical preferences, rather than based on any objective metric.
> Only two remote holes in the default install, in a heck of a long time!
I remember a time when it was zero, not two.
I love BSD based OSes, but I've always found this claim to be a little irritating, because it's far less impressive IMO than it sounds to the uninitiated. It's impressive from the perspective of Windows or Solaris which enable huge numbers of network daemons by default and have both suffered numerous high profile remote vulnerabilities on default installs, but OpenBSD isn't really much different from most Linux distros on this. I'm sure most distros have had more remote vulnerabilities, but not that many. Your average Joe out-of-the-box install of Fedora or Ubuntu doesn't really have any open services IIRC, so an exploit would need to directly target the Linux IP stack, or one of the network autoconfig services if that's in scope.
I don't see that in any mainstream Linux distribution. There are alternatives, but then you're more or less on your own, necessitating work which could be avoided if some BSD satisfies your needs regarding hardware driver support.
At the end of the day it amounts to https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar
I'm a grumpy old fart and (usually) don't like chaos.
No idea why it's not more popular tbh (I setup most systems this way both for security and efficiency reasons). The default installation profiles for most distributions are incredibly bloated in comparison (especially Ubuntu and such).
Nevertheless any Debian or derivative feels bizarre to me. Yes, I know apt-pinning, custom repos and whatnot.
I'm writing this on a derivative booted into 'ramdisk' and running from there for 139 days now. (Oh my Gawd! How dare I?!) Because the good folks from AntiX and MX-Linux made it possible, and did the work for me. Making intelligent use of the facilities Linux can offer.
apt-shred dist chainsaw!
I've gone deep down this rabbit hole, but now in my mid 20s, it seems like it's all sentimental - the amount of time I interact with any base system is pretty low, Linux's device model seems better suited to modern systems than BSD's more static kernel configs inherited from PDP-11/VAX/VMEbus-esque systems, and probably more than anything else, it's almost always easier to get your software to run on Linux. And after thinking about it, isn't that really the purpose of an OS? To facilitate running and developing software?
I still love running NetBSD on my 90s SPARC laptop, with device drivers descendant from the original 4.4BSD from UCB. I've gone so far as to patch my local install to get the crappy mu-law audio output working so I could playback youtube videos on it for kicks and giggles (recent releases overhauled the audio driver backend and the AMD7930's driver doesn't release some mutexes, failing asserts and hard faults the kernel)
Sometimes the Cathedral isn't so nice though. I never really figured out where I could send the ~5 line patch for this, only where I could submit a bug report, and possibly start a dialogue on the mailing list where I could maybe suggest the fix, and then a NetBSD developer could go fix it themselves? Didn't think it was worth the effort, so I never patched it.
Meanwhile, on Linux, I got a one line patch into the kernel, fixing a presumption that all 32-bit processes are big endian on PowerPC, thereby allowing the development of a 32-bit LE userland. Almost certainly useless to anyone, but it was a bug fix, and the patch process was fairly painless.
I think the end result is that Linux is fast and messy and a little ugly, but most of my hardware and software is also ugly and messy. I could run BSD on my laptop nowadays, but the only day-to-day change to my display server running firefox and $TERM windows would be a hotter keyboard and a few cents added to my energy bill, since those kernels don't really vibe with Intel p-states or whatever it's called now. My userland environment and day to day life is basically identical, just a few added problems when some piece of software assumes I'm on Linux and breaks.
Well, that and OOM handling. I don't ever remember the BSDs locking up quite like Linux does when it runs out of memory (or thrashes swap).
This turned out more rambly than I intended, but oh well. While I'm ranting, why is OpenBSD's fdisk the only implementation of fdisk with a command mode where quitting automatically saves changes*, as opposed to util-linux's fdisk, and NetBSD/FreeBSD's fdisk which always prompt? :-)
I remember SuSE 6 from me youth. It run of the box (having selected a Desktop-Setup) SSH, Telnet, Apache, FTP, Finger, Samba, CUPS and probably other daemons I forgot! You dail-in to the internet and bam: everthing/most was accessible via a public IP. I used to "pwn" boxes with exploits from packetstorm myself.
(Ironically OpenBSD was late to the "easy update"-party. You used to need to patch and compile updates yourself.)
I've used FreeBSD a fair bit in the past and Ubuntu and Debian more continuously. Unless something radically changed recently. My experience is about 6-8 years old now but FreeBSD requires a lot more configuration when setting up common services, whereas Ubuntu and even Debian have good defaults that you can usually bring up without having to first consume the entire manual for that service.
There's probably a reasonable sounding argument buried behind this like "you cannot run a service securely if you do not fully understand the configuration first." but in practice this just results in poor initial configurations because it takes time to fully understand all of the knobs of configuration on a service.
FreeBSD can be a solid system, but it's less practical in many ways for reasons like this.
I was using FreeBSD as my desktop for almost 15 years, since the 4.1 times, and the amount of work it took to make some sane vpn client out of an ubuntu is nowhere near what I had as my griefs with FreeBSD back then. Not even mentioning pf vs iptables and how 20(?) years passed before linux had something comparable like nftables.
Nowadays it's mostly fine, but..
Case in point : I had to write and contribute wireguard support to the netplan to make it marginally sane.
My limited experience with FreeBSD was as a desktop and server for a few years around 2009ish to 2012, but also as a basic user of basic services. From memory a lot more hoops had to be jumped to get equivalent things working on FreeBSD, and I was always left with a nagging feeling after initial setup on FreeBSD that I didn't yet know enough to feel confident in the configurations I had produced, compared to Debian and et al at the time, where configuration felt like they left the bare minimum for you to customise, and working defaults for the rest that you could gradually learn to tweak without the pressure of getting every variable correct from the get go.
However as a user who already thoroughly understands the service or it's domain I expect this kind of detail may be lost... instead you can compare based more on the flaws of the configurations and their implementations (which I suspect applies to your experience). But for the rest of us it results in flaky custom initial configuration. It's the same for me if I pick out a piece of software now that I have become very familiar with and already know how to configure inside out - i wouldn't experience the same kind of problem that someone unfamiliar would.
To clarify, I guess I'm talking about sane defaults from the perspective of new users, poor defaults combined with new users can end up with insecure or problematic results - even if the default configuration alone is technically fine.
I expect Linux and FreeBSD and other BSDs have likely improved a lot over the last decade from either perspective anyway.
Or define the runtime options from the base-ssh-server in rc.conf (that's what i normally do):
sshd_enable="YES"
sshd_dsa_enable="NO"
sshd_ecdsa_enable="NO"
sshd_ed25519_enable="YES"
sshd_rsa_enable="NO"
If you want RSA=YES then you probably/maybe want to delete all moduli less then 4096.