Say my Blog’s name!

Given that the title of this site is “functionally paranoid”, I noticed it had been a while since I had written anything focused on information security.  I thought about what would be a good topic and it hit me – how about my uber paranoid home networking setup?  So, put on your tinfoil hats my friends and buckle up – it’s going to be a wacky ride!

Physical Security

What’s the one thing that everyone forgets when thinking about information security?  Well, one is that there is always some guy named Bob who will mess things up (i.e. humans are the weak link because we can be socially engineered, etc.)  The other thing is that if you have physical access to anything, you can eventually brute force it.  However, there are things you can do to make things more difficult.  Here are some of the pros and cons:

  1.  BIOS passwords – Not something I’m typically impressed with.  Most can be avoided by opening up the machine, closing a jumper and powering it up to reset the NVRAM to factory defaults.  I don’t even bother with them.
  2. Full disk encryption – This one really rings my bell in a positive way.  If you can kill power to the box (either because the bad actor has to physically steal it and they aren’t carrying around a pile of car batteries and an inverter or because you can interrupt power to it some other way), then the disk will be encrypted.  The other beauty of this is that if a drive fails (and they all do eventually) you don’t have to have any privacy concerns about chucking it into an electronics recycler (or if you are a bad, bad person, into a landfill) because that data is effectively gibberish without the key (or without a long time to brute force it).
  3. Two factor auth for logins – I like this one as well.  I’m not a fan of biometrics because if your fingerprint is compromised (yes, it can happen – read about the department of defense background checks that were extracted by a bad agent – they included fingerprint images) you can’t exactly send off for a new finger.  Things like the YubiKey are pretty slick.  They require that you have the physical hardware key as well as the password so unless the bad actor lifted your physical key, they would have a much harder time with physical access to your hardware.

I use full disk encryption and two factor auth via a YubiKey on every piece of gear in my secure home network.

Network Segmentation

This is an area where I could get way more creative, because keeping network traffic isolated to particular subnets or VLANs is a great mechanism to prevent “island hopping”  (thank you Alan Jude and Chris Fisher for TechSnap!) when a bad actor gains access to one of your network resources; however, I’m keeping it simple for now.  The first thing I did was change the default password for administrative access to my ISP-supplied router.  There are some pretty interesting attacks that don’t compromise your machine, but instead use it to run Javascript to log into your non WAN exposed ISP router using the default userid and password and then do things like DNS hijacks, etc. to be able to maliciously impact every device on your network.

Just change the darned password to something else already!  Also, validate that your administrative interface for the thing isn’t exposed to the WAN side of the link.  Believe it or not, some of them ship that way.  I leave the ISP-supplied WiFi access point to provide a network I make available to my guests because it sits entirely outside of my secure network.

The next thing I do is connect the LAN side of the ISP-supplied router to the WAN side of my own router.  I use an APU2 box that I built for around $150 running OpenBSD as my router for my secure network.  I use the wonderful pf firewall that is supplied with OpenBSD to filter packets and map ports as I want to.  It has a very understandable syntax and has great performance.  The LAN side of this router goes to my managed switch (which I hope to replace with switchd running on an OpenBSD box at some point) which serves as the core backbone of my secure network.  Plugged also into this switch is my WiFi access point running in bridge mode for my network so that I can have WiFi access (with a very secure WPA2 password) to my secure network.

I know that any true security expert will scoff that I go to all of this trouble and then hook a WiFi access point up, but this is an area where I tilt the scales away from security towards convenience.  A good long WPA2 password isn’t ideal, but it isn’t crackable in a short period of time without a determined attacker who has lots of horsepower.  For example, a 16-character randomly generated password that uses uppercase, lowercase, numbers and special characters would have so many permutations, that it would take a freakishly long time to brute force.


So security is good, but privacy is good as well.  You might not get hacked, but if you aren’t careful about privacy, you will be leaving breadcrumbs all over the internet – which is not good.  To that end, think about who probably knows the most about your online traffic – that’s right, your ISP.  Even if you do everything over HTTPS and use a VPN, you are probably still using them (or heaven forbid Google!) for your DNS resolution.  Enter DNSCrypt Proxy!  This little jewel takes all of your DNS traffic and egresses it to the Internet outside of your ISPs network.  I actually use a public resolver in Europe for mine.

I use Unbound as my DNS resolver on my local network (with all UDP port 53 traffic redirected to it by pf so I don’t have to configure anything on the clients) and then forward the traffic to DNSCrypt Proxy, caching the results in Unbound.  I notice ZERO performance penalty for this and it greatly enhances privacy.  This combination of Unbound and DNSCrypt Proxy works very well together.  You can even have redundancy by having multiple upstream resolvers running on different ports (basically run the DNSCrypt Proxy daemon multiple times pointing to different public resolvers).

I also use Firefox exclusively for my web browsing.  By leveraging the tips on this page, you can lock it down to do a great job of privacy protection.  The fact that your laptop’s battery drain rate can be used to fingerprint your browser completely trips me out but hey – that’s the world we live in.

For times I am not connected to my secure network, I use a non US-based VPN provider (I like and choose an endpoint that isn’t in a Fourteen Eyes country for egress.  I  have given thought at various times to doing that using pf on my home network but the performance hit is still a bit too much for me.  Likely that will improve over time.  The nice thing about AirVPN is that it uses the OpenVPN client meaning I can run it on my mobile devices as well.

You can get even more secure with things like the TOR browser bundle, but be careful how you configure it.  You can actually make yourself less secure than you think if you aren’t educated on how everything works.

The Cloud

This is where it starts to get weird for most folks.  They have pretty good security hygiene and maybe are fairly good about privacy, but they end up storing everything in a cloud service.  Remember, another way of saying “the cloud” is “some other guy’s computer”.  If you really to care about your privacy, then you should avoid cloud services like the plague.  However, that starts to get really hard and you have the good old balancing act between security and convenience.

I recently decided I would try to live a cloud-free life and I’ll give you a bit of a synopsis on it.  I discovered a wonderful OpenSource project called FreeNAS.  What this little gem does is allow you to install a FreeBSD/zfs file server appliance on amd64 hardware and have a slick administrative web interface for managing it.  I picked up a nice SuperMicro motherboard and chassis that has 4 hot swap drive bays (and two internal bays that I used to mirror the boot volume on) and am rocking the zfs lifestyle!  (Thanks Alan Jude!)

One of the nicest features of the FreeNAS is that it provides the ability to leverage the FreeBSD jail functionality in an easy to use way.  It also has plugins but the security on those is a bit sketchy (old versions of libraries, etc.) so I decided to roll my own.  I created two jails – one to run OwnCloud (yeah, I know about NextCloud and might switch at some point) and the other to run a full SMTP/IMAP email server stack.  I used Lets Encrypt to generate the SSL certificates and made sure I hit an A on SSLLabs before I did anything else.

OwnCloud includes the ability to install plugins and there are some dandy ones out there.  I installed a notes one that had iOS and Android clients (buh-bye Evernote with your attempted changed privacy policy which you rolled back but I see how you really are now).  I also installed a Calendar plugin that had CalDAV support (see ya’ Google Calendar!) and a CardDAV contacts plugin (later Google Contacts).  I got all of them up and running (along with the mail server Jail – use mxtoolbox to check your work here) and can now stop using the main cloud services I had previously been running.

How did I get around my ISP blocking common IMAP/SMTP ports you ask?  I set up a relay server on a VPS server that I rent for $8 per month.  I started out on one based in the US but my better thinking prevailed and I found a provider in a non fourteen eyes country.  Everything seems to be working OK once I got all of the right security / anti-spam bits in place but only time will tell.

This path isn’t for everyone because you are now fully in charge of the security and reliability of your mail / calendar / contact / note infrastructure.  Also, you just increased your attack surface so be extra careful there!


This is another fun one.  You go to all of this trouble and then you store your offsite data backup (you DO back up your data offsite, right?!??!?!!) in some cloud service like Carbonite or CrashPlan.  As convenient and cost-friendly as that is, you have no idea how many copies of your data they make in their datacenter operations and even if you leave them, they are probably still floating around in their cloud infrastructure somewhere.

Enter TarSnap – a company that advertises itself as “Online Backups for the Truly Paranoid”.  It brings a tear to my eye – a kindred spirit!  ūüôā  Thanks again to Alan Jude and Kris Moore from the BSD Now podcast for turning me onto this company.  It has a very easy command syntax (yes, it isn’t a GUI tool – suck it up buttercup, you wanted to learn the shell didn’t you?) and even allows you to compile the thing from source if you want to.

The way it works is that it encrypts the data on your machine before ever sending out to the network.  As long as you keep your private key on the encrypted drive on the machine you are backing up, it’s pretty darned safe although you might want to keep a copy of it somewhere that is physically secure and preferably offsite (perhaps a GPG encrypted file on your mail relay VPS).  The cost is based on the amount of data you store and the network traffic to get it to/from their service.  However, for the type of data I’m storing up there, it isn’t crazy expensive and it de-dupes the heck out of it to further reduce your costs.

Internet of Things

This is an easy one – avoid any “internet of things” device that connects to anything outside of your network!  That way you avoid these poorly implemented security nightmare devices becoming a public menace and joining a DDOS botnet.

OK, if you absolutely can’t live without your internet connected ice cube tray, the best way to secure these devices is to put them completely outside of your secure network.  Hook them up to the WiFi made available by your ISP supplied router (where I put my guest traffic).  It’s still (theoretically) sitting behind a “secure” router but it sure as heck isn’t on your secure network.

You could do other things like having a VLAN dedicated to them and locking them down by MAC address.  The problem is there is always some clever 8th grader in Germany who will still find a way to exploit them and island hop to your other machines.  Best keep them at arm’s length on the outside of your real router (you do run an OpenBSD router, right!?!??!?!)


There are other things that I’ll want to do eventually (perhaps putting my WiFi traffic on its own network segment with host isolation mode, switching to certificates for my WiFi access, or installing an IDS tool like snort), but for now, this is where I stand.  I’d appreciate any feedback or suggestions from folks out there with ideas on how to lock things down more.

Where the rubber meets the road (part two)

So in my last post, I detailed what it took to get Arch Linux running on my brand spanking new Thinkpad X1 Carbon (4th Generation) and was getting ready to install OpenBSD on the same disk.  In the intervening time, I banged my head against the wall over and over again trying to figure out what my problem was on OpenBSD with not seeing the partition structure correctly on the disk and have finally given up.  Time to NUKE AND PAVE baby!

I backed up my data from Arch to an external drive, downloaded the latest snapshot installer for OpenBSD, burned it to a thumb drive and booted the laptop from it. ¬†My goal is to reverse the approach I took last time and install OpenBSD first. ¬†I’m going to GPT partition the disk and then, once I have it working correctly, reboot into the Arch installer and install Arch second.

After booting the OpenBSD installer, I bailed out to the (s)hell at the prompt and rewrote the partition on my 1TB NVMe drive with:

# fdisk -gi -b 4096000 sd0

This repartitions the drive with GPT and creates a boot EFI volume that is 2G in size.  I then used:

# fdisk -e sd0

to edit the drive and resized the OpenBSD partition to 490 GB in size.  Next, I used disk label to create my encrypted partitions for swap and data:

# disklabel -E sd0

I created an “a” partition (don’t forget to make it RAID type) ¬†hat took the rest of the OpenBSD area for my encrypted data drive. ¬†I then used bioctl to create the encrypted volume:

# bioctl -c C -l /dev/sd0a softraid0

The crypto volume was now available as /dev/sd2 so I used “exit” to get back to the installer and installed OpenBSD on that volume as I normally do. ¬†To be safe, I mounted the EFI partition (/dev/sd0i in my case) and copied the /efi/boot files into /efi/openbsd. ¬†I vaguely recall a Linux installer overwriting the OpenBSD files at some point in my checkered past so it never hurts to be safe.

I then reformatted my thumb drive as FAT32 and grabbed the missing firmware tarballs I needed to, rebooted the new OpenBSD install, and untarred them into /etc/firmware.  After rebooting and verifying that everything was working fine, I downloaded the latest Arch installer, burned it to the thumb drive and booted from that.

I installed Arch as I detailed in my last post; however, when I fired up gdisk I got a weird error message:

“Warning! Disk size is smaller than the main header indicates! Loading secondary header from the last sector of the disk! You should use ‘v’ to verify disk integrity, and perhaps options on the expert’s menu to repair the disk.”

Immediately after this, I saw a second warning:

“Caution: Invalid backup GPT header, but valid main header; regenerating backup header from main header.”

And, not to be outdone, there was a third:

“Warning! Main and backup partition tables differ! Use the ‘c’ and ‘e’ options on the recovery & transformation menu to examine the two tables.”

Finally (not kidding), there was a fourth:

“Warning! One or more CRCs don’t match. You should repair the disk!”

Given all of that, I thought to myself, “This is probably why I couldn’t see the disk properly when I partitioned it under Linux on the OpenBSD side. ¬†I’ll let it repair things and I should be good to go.” ¬†I then followed the recommendation and repaired things, using the primary GPT table to recreate the backup one. ¬†I then installed Arch and figured I was good to go.

Now¬†I was¬†ready to put on rEFInd as my boot manager for switching between the two. ¬†I installed the “refind-efi” package using pacman:

$ sudo pacman -S refind-efi

I then ran refind-install and had what I needed working. ¬†I rebooted to OpenBSD and was greeted with a kernel panic because it couldn’t find my root volume. ¬†Uh oh.

I repeated this process a couple of additional times (starting from scratch, partitioning under OpenBSD, installing Arch, repairing the disk, etc.) and not surprisingly got exactly the same results.

OK.  What to do now.  I decided to rock this old school and dump the whole crazy GPT thing and do this MBR.  After all, I only need three partitions anyhow (the EFI one, the luks encrypted partition for Linux and the softraid encrypted partition for OpenBSD).

I booted up off of the OpenBSD installer thumb drive, jumped out to the (s)hell and did:

# fdisk -i -b 4096000 /dev/sd0

I then resized down the default OpenBSD partition (#3 by the way) to half its size using fdisk, and used disklabel to create a single “a” slice that took up the entire area (make it RAID for the type). ¬†Then, bioctl and I created the encrypted softraid container and I rejoined the installer and installed normally on the new virtual device (sd2 in my case).

Installing Arch was slightly tricker this time because apparently very few people use EFI and MBR together, let alone with luks and lvm. ¬†ūüôā

The trick was realizing that I couldn’t use systemd-boot as my boot manager because it doesn’t work with MBR nor do they apparently have plans to make it work (I get it, this is the true definition of a corner case). ¬†I dropped back to GRUB for my boot manager with the only trick being that I changed the GRUB_CMDLINE_LINUX variable in /etc/default/grub to be:


I then ran the configuration file generator:

# grub-mkconfig -o /boot/grub/grub.cfg

At this point, I crossed my fingers and booted back and forth (using the F12 boot menu on the Thinkpad and choosing the nvme drive booted OpenBSD and I could choose “grub” from the boot list to boot Linux) between OpenBSD and Arch multiple times to ensure there wasn’t any funny business going on.


Now that I have everything working, I’ll restore my config and data to Arch, configure OpenBSD the way I like it and get moving. ¬†I’ll take some time and drop a note on the tech@ mailing list for OpenBSD to see if they can figure out what the GPT problem was I was running into. ¬†Hopefully it will make that part of the code stronger to get an edge-case bug report like this.