Learning FreeBSD

Why not, I might build a FreeBSD based OS used for security engineers. Sorry, if this was too much :).
I'd instead suggest spinning up a FreeBSD VM, and install some tools. No need to reinvent the wheel.
My frustration with Linux is actually exactly that - there's an uncontrollable proliferation of Ubuntu-based distros that pop up, and then are abandoned after a few years when people discover how much work it is to maintain a whole infrastructure to support what frankly amounts to a few non-default options in the base system.
 
can be used in security space.
You've heard of OpenBSD, have you? They famously claim 'Only two remote holes in the default install, in a heck of a long time!' right on openbsd.org in red font. I tried playing with OpenBSD at the tail end of my college career, but never made a go of it.

OpenBSD people, IMHO, do loudly claim to be very security-focused, and doing a better job of it than everybody else, here is how - but code audits (both automated and by humans) are time-consuming, and only go so far. Equivalent functionality is relatively easy to implement on FreeBSD, but real security means learning how to load a copy of the Stuxnet binary into devel/gdb, figuring out what the 900-KB binary is even trying to do, and connecting a few dots...
 
astyle. i have heard of this aspect of OpenBSD. However, I have not used this as a mainstream OS, because as part of my work, I use Windows and Linux as well. So, my OS'es runs in vm. I used VirtualBox earlier, then switched to KVM (Debian). Now i am fully into FreeBSD using bhyve.

I think OpenBSD has limited support in bhyve.
 
OpenBSD people, IMHO, do loudly claim to be very security-focused, and doing a better job of it than everybody else, here is how - but code audits (both automated and by humans) are time-consuming, and only go so far. Equivalent functionality is relatively easy to implement on FreeBSD, but real security means learning how to load a copy of the Stuxnet binary into devel/gdb, figuring out what the 900-KB binary is even trying to do, and connecting a few dots...
Well the OpenBSD people are quite fanatic when it comes to security. Security is their main priority, so don't expect OpenBSD to take the performance crown anywhere. For most tasks it is performing ok, but will be most likely always be outperformed by FreeBSD or Linux.

Security means for them, amongst other things, this:

* the default system comes with everything turned off. Want to have SSH access? You have to enable it... and so on and on.
* quite often rebuilding the wheel from scratch with various success because the standard implementation of a well established protocol didn't fit into their philosophy, either license wise or for other reasons. Examples of that are: OpenNTPD, OpenSMTPD, OpenSSH, OpenBGPD, Pf, CARP. Also the LibreSSL fork. OpenSSH is clearly the most popular of these, though.
* if something threatens security they will do cut corners without compromise. When it for example became obvious that hyperthreading is a hardware security issue their response was to turn if off by default. Or dropping loadable kernel module support entirely back in 2014.
* when informed about exploits they've got some of the best in industry response times ever in terms of fixing it, communication to the world and pushing it out.
* as a result their kernel code base is also much, much smallers compared to other OS. OpenBSD kernel is around 3 milliones LOC, FreeBSD more around 10.

So due to that when you're new to OpenBSD you've got to rethink some of your practices.
 
So due to that when you're new to OpenBSD you've got to rethink some of your practices.
This is probably why I never made a go of it. OpenBSD made things too inconvenient in the name of security. Having to remember to enable this and that is hard enough in FreeBSD, and OpenBSD was, IMHO, much worse in that regard. Encryption/security plugins from the OpenBSD camp is top-notch stuff, I'll grant them that, and I'm grateful that they do share the expertise - but for my OS, I'm gonna stick with FreeBSD, thank you very much.
 
I personally find that on suitable hardware, OpenBSD is easier than FreeBSD. A clean (minimized) Xorg is already in base. KMS/DRM drivers are also part of this for AMD and Intel. It asks if you want SSH from the main installer too. Firmware files are all on firmware.openbsd.org and it installs the correct ones with fw_update.

FreeBSD does win in the functionality department but I certainly can say that OpenBSD feels really clean and elegant. Unless you specifically need FreeBSD functionality (Jails, VirtualBox, Old Nvidia are my main ones), then it is still a really good choice, it gets a lot of things very right.
 
This is probably why I never made a go of it. OpenBSD made things too inconvenient in the name of security. Having to remember to enable this and that is hard enough in FreeBSD, and OpenBSD was, IMHO, much worse in that regard. Encryption/security plugins from the OpenBSD camp is top-notch stuff, I'll grant them that, and I'm grateful that they do share the expertise - but for my OS, I'm gonna stick with FreeBSD, thank you very much.

I think it's purely because of how cybersecurity space works. the way the threat actors have evolved over the last three decades, they have made this cybersecurity as an industry!.

initially, there was only anti-virus, and people thought it's cybersecurity. then came the firewall. initially people allowed many ports and blocked whatever they don't want. then that changed, deny_all first and allow only when it is required. now the industry is going by the idea of zero trust. don't just trust anything.

the spear volume of traffic, the devices and use cases are too much that, monitoring and defending is becoming really difficult.

now with that, I would certainly agree the style of OpenBSD. that is very much in line with security mindset.

however, if you see the security controls are really becoming a headache and not helping the people who want to release and do things very fast and quick. in fact, the containers (dockers) solve this problem greatly.

overall, it has become like a cat and mouse game and this has never changed!
 
* the default system comes with everything turned off. Want to have SSH access? You have to enable it... and so on and on.
OpenBSD installation enables the sshd(8) by default. If it's disabled, you've done that during the installation, or during the upgrade and in the sysmerge(8) phase.

Why that procudure, i.e. the "Start sshd(8) by default" is important?

1. There's a default pf(4) config in the rc(8) script.
2. The default blocks everything, with the exception of SSH and ICMP.
3. In the boot time, pf(4) replaces default PF configs -- in the rc(8), with your customised pf.conf(5) rules.
4. If you screw up the pf.conf(5), then pf(4) keeps the default.
5. STEP #2 & STEP #4 implies that you can ssh(1) to the machine, even with a corrupted pf.conf(5).
6. STEP #6 is crucial, esp. when the machine is a remote one.
 
* as a result their kernel code base is also much, much smallers compared to other OS. OpenBSD kernel is around 3 milliones LOC, FreeBSD more around 10.
FreeBSD kernel was small. Then they've added ZFS to the kernel. I think about 250,000+ LOC. But it's not the whole story. Refer to the McKusick's. There's some data about LOC on his book.
 
FreeBSD kernel was small. Then they've added ZFS to the kernel. I think about 250,000+ LOC. But it's not the whole story. Refer to the McKusick's. There's some data about LOC on his book.
Doing # kldstat shows zfs.ko as a separate, loaded kernel module, at least on my machine. Yeah, that happens if you select ZFS instead of UFS at install. My point is, I don't think ZFS is really part of the kernel - it's a separate loadable kernel module that has merely been included in base.txz. My educated guess is that UFS is part of the kernel, but I'm too lazy to spin up a VM just to verify that won't be getting a ufs.ko listing from doing a # kldstat.
 
Doing # kldstat shows zfs.ko as a separate, loaded kernel module, at least on my machine. Yeah, that happens if you select ZFS instead of UFS at install. My point is, I don't think ZFS is really part of the kernel - it's a separate loadable kernel module that has merely been included in base.txz. My educated guess is that UFS is part of the kernel, but I'm too lazy to spin up a VM just to verify that won't be getting a ufs.ko listing from doing a # kldstat.
For the lazy typists: you don't get a ufs module. It's built in for the GENERIC kernel.
 
I've had OpenBSD boxen but am more comfortable with FreeBSD in knowing I've got all 3rd party app. vulnerabilities patched.

They use syspatch as an update mechanism. Ravenports was an option for updating programs, but when you start running here to get this and there to get that I start thinking of another OS/Service. No shade at OpenBSD by it.

FreeBSD feels more polished as a Desktop OS, but that may be a reflection of my experience in comfort using the two.

If no BSD's were in the mix I'd be using a Debian based system like Kali. and have a Kali box on metal now. apt-get works for me.
 
  • Thanks
Reactions: a6h
I run these three commands at least once a day.

portsnap fetch update
pkg audit -F
freebsd-update fetch


The first command updates my ports tree and gets me the latest /usr/ports/security/vuxml file for any new program vulnerabilities found.
The second command checks that file for vulnerabilities in my programs.
The third checks for updates to the base system:

If the freebsd-update fetch command doesn't download any updates there are none.
If it downloads updates you need to install them.
Then issue the shutdown command that it may be well with thee

freebsd-update install
shutdown -r now
 
Back
Top