Choosing OpenBSD

My introduction to OpenBSD as a concept happened years ago, before I really understood more than the general philosophy of writing secure, correct code. I never got around to trying it on my hardware though because I was too busy with other systems, like DragonFly BSD and Gentoo. However, when I got assigned the project of replacing our aging firewall infrastructure at work, I started looking into options like pfSense, OPNSense, and OpenBSD.
I figured that OpenBSD would be too difficult for me to figure out, especially since I'm not particularly great at networking, and decided to compare pfSense and OPNSense. Since I've spoken with lattera from the HardenedBSD project, I decided to go with OPNSense at first due to the extra security functionality built into the HardenendBSD base. However, the lack of ZFS support (these are pretty beefy firewalls, basically just repurposed Dell R710s) was a bit of a turn off, as I'd be missing boot environments. I also had a hard time working with the WebUI, though that's almost certainly a personal thing. I'm not the best with GUIs, I'd rather read a man page and look at example config files. The appliance-like nature of OPNSense was making it more difficult for me to set it up the way it was needed at work, so I wound up installing OpenBSD to work with pf(4) and relayd(8) manually.

Installation

Coming from a mostly Linux background, and the only real BSD experience I'd had before was with FreeBSD, HardenedBSD, TrueOS, and DragonFly BSD, I was unfamiliar with the way in which OpenBSD's image selection process was handled. In my case, I needed the "install61.fs" image, as I was going to burn the image to a flash drive. This is analagous to the *.img files of other BSD systems. It also has all the sets available locally so no network connection is necessary during the installation.
After booting, you're presented with a simple menu that guides you through the installation, taking no more than about 5 minutes in normal situations. Unfortunately, I was waiting on the integrated RAID controller to finish building a RAID 1 at the same time, and it took hours to create and format the partitions, if you can avoid this mistake, I highly recommend it.
So, provided you don't have a RAID controller (which I'd generally recommend against anyway) building an array, causing your drives to take much longer than necessary to write any data, the install takes about 5 minutes. It can be a little confusing when it comes to installing the package sets, but the suggested answers are usually what you want unless you need to customize the install (like not using X11, for example).
Once you're done, you'll be dropped to a shell and asked to reboot the system. In more recent versions (6.2+), this should be done for you. After the system comes back up, you should be ready to log in with whatever credentials you established during the installation and run

man afterboot
This will give you the basics to get familiar with your new OpenBSD system.

Configuration

So, depending on the kind of person you are, you may be fine with the default system, but I'm used to using a few specific tools that need to be installed before I can be productive. Fortunately this is pretty simple on OpenBSD. There's a few files and commands needed to get set up and begin working on whatever problems you're wanting to solve with OpenBSD.

Networking:

		/etc/installurl: 
		https://mirror.esc7.net/pub/OpenBSD

		/etc/hostname.eth0:
		inet 192.168.1.10 0xffffff00

		/etc/mygate:
		192.168.1.254

		/etc/myname:
		puffy.home.loc
		
Of course, you should replace any values used with the values needed by your own deployment, but when you have everything set properly in these configuration files, you would use the command
doas -u root sh /etc/nestart
or otherwise execute the netstart script as root.

Package Management:
With installurl(5) set, you should now be able to install packages! These, like on every other UNIX-like system are handled by the package manager, which will require elevated privileges to run, since sudo(8) isn't installed by default, you'll need to use either doas(1) or su(1) to elevate privileges initially.

		doas -u root pkg_add -vVm vim rc curl nmap bash drill fping sudo 
		OR
		su -c pkg_add -vVm vim rc curl nmap bash drill fping sudo
		
The interesting thing about OpenBSD's package manager is that some packages like vim have several different flavors available, these flavors have some optional additions or optional dependencies for extra functionality (like X11 support), when presented with a menu, simply enter the number/letter representing the flavor you'd like to install.
There are some very useful additional tools like pkg_info(1) to list the installed packages or get information about them.
pkg_delete(1) will uninstall packages, pkg_add(1) can also upgrade packages, and pkg_check(1) will verify the consistency of your installed packages.

Basics of pf(4)
pf(4) is OpenBSD's home grown firewall, or "packet filter". It's by far one of the most attractive features of OpenBSD. This is the "killer feature" that lead to pfSense and subsequently OPNSense. The syntax takes a bit of getting used to, but there's several sites with example configurations, as well as a few examples in

/etc/examples/
as well as the pf(4) manual page. Even the OpenBSD site has several pages of documentation for both pf(4) and relayd(8), and how they work together.
		/etc/pf.conf:
		ext_if="eth0"
		set skip on lo
		set block-policy drop
		block return
		match all scrub (no-df random-id)
		drop all
		anchor "relayd/*"
		pass out on $ext_if
		pass in log on $ext_if inet proto tcp from any to ($ext_if:0) port ssh
		
Of course, applying the configurations set in
/etc/pf.conf(5)
, requires pf(4) to re-read the file. This could be done in the worst, most inefficient way possible, rebooting or restarting pf(4). Or you could simply run the following commands and fix any errors that pop up to get the filtration rules set properly. The example above simply drops all inbound traffic not destined to port 22 over ipv4, and randomizes all the packet IDs to make determining the OS running on the host more difficult. These steps are relatively similar on any platform supporting pf(4), and ideally possible to replicate on any other firewall. The one function listed that would be more difficult on another platform is the line
anchor "relayd/*"
, that allows relayd(8) to interact with pf(4) on OpenBSD, to provide a much more robust transparent proxy and firewall system on a single host ( or even distributed hosts ).
		pfctl -vvvndf /etc/pf.conf
		pfctl -vvvf /etc/pf.conf
		

Upgrades Upgrades to the system between release cycles is done through both syspatch(1) and the usual pkg_add(1). These will pull in updates to the base system and packages, respectively. They can be done from a running system but be warned that there could be some minor breakages and changes, so be sure to read up on the patches being sent out. It's unlikely you'll ever find an upgrade trashing your system, but the OpenBSD team is not afraid to break things in the name of security and code correctness, so it's better to be safe than sorry, especially when upgrading a production system.

		syspatch -c # check for updates 
		pkg_add -u # upgrade packages 
		

To be Continued

This is just some of the basics that I had to pick up over a relatively short period of time, and are described in greater detail on the OpenBSD faq and manual pages. This should be enough to get anyone able to start using OpenBSD and start looking into doing something more fun with the system later. There's some really fascinating work being done with OpenBSD, you just need to have some patience getting used to how things work on OpenBSD compared to your usual system, but it's absolutely worthwhile. Currently, my only complaint is they don't have ZFS, HAMMER, or HAMMER2 support yet.