Adventures in Zero Trust

by narghile

Recently, I made the decision to implement a zero trust security model on my home network.

The journey has been full of torment, surprise, joy, and satisfaction along the way.  When I started this adventure, I knew it would be a somewhat major undertaking, but as progress continues, the process has proven to be worth the effort.  These days we all have devices scattered around the home calling out to the greater web at all times of the day doing god knows what.  So just cutting them off from their network friends can create some major ramifications to personal convenience or family cohesion.  I'm not going to get super technical in this article because I want to encourage discovery and learning instead of creating confusion.

There are many network layouts and everyone does things differently, but if you choose to undertake this odyssey, it might be good to start with a review of your equipment, your personal needs, and a plan of attack.  It has been my experience that consumer grade networking gear doesn't really provide a clear way to implement some of these ideas and might not even provide an admin the ability to do so.  I'm not really up to date on the "it just works" kind of devices.  If you have a router that allowed you to flash it with DD-WRT or have pfSense installed on a spare server, you're going to be better off because these systems will likely give you a better tool set to perform diagnostics.

In an effort to lessen the impact of cutting off wide open network access, it might be helpful to work from the bottom up or segment chunks of your network.  Make a note of devices you are going to trust outright, those that are mixed, and the devices that you don't trust at all.  For example, I started out by trusting my phone, my workstation, and even my TV out of the gate.  Many of these devices already had open access to call out to wherever for the longest time and leaving them alone while investigating other devices kept my sanity intact.

Don't frustrate yourself by pulling the trigger on everything at once because you will be overloaded fixing issues with broken devices.  It helps to profile what each device should be doing.  The idea here is to get ahead of issues you'll be encountering when trying to perform that action you've done a thousand times in the past.

To assist in the implementation, it's usually worth creating network segments ahead of time that you can use to move devices into.  For example: a trusted zone and an untrusted zone or a DMZ.  Creating these segments can introduce additional complexity, but aids in applying rules en masse.  Before or after you add your outbound "drop all" rules, use your admin tools to see what is happening and be methodical about it.  See if you can enable logging on the drop all rule and watch the chaos ensue as devices try to call out to hosts you never expected, let alone knew about.  Use online databases to check if the host is legit.  As I was doing this, I found so many unexpected and, frankly, things I didn't approve of going on.  Many devices will be trying to call out to the vendor's websites for updates, etc.  I'd often question why or what they needed to do that for and sometimes discovered functionality I either forgot to disable or never used to begin with.

One thing to consider is that you can inadvertently open more access than you may have actually needed.  For example, you might want to say allow any web traffic to any host over port 80 or 443, when in reality you probably could have gotten by with only allowing traffic to a specific host.  Malware these days is pretty smart and their developers know that it is commonplace to liberally allow common ports.  Create log rules to show what is getting blocked.  This way we know what we may want to whitelist.  For untrusted devices, we create "pinholes" to specific hosts over specific ports.  By watching the traffic and block logs, you will find patterns that become apparent and can then allow that traffic as needed.  If you take your time and lay down the groundwork ahead of time, you will end up with the satisfying feeling of knowing much more about what is going on in your network.

This is by no means an end-to-end tutorial of how to implement zero trust on your own hardware, but I wanted to share some of my own experiences and maybe motivate others to consider the unknown.  With so many Internet-connected devices these days, you can't be too sure what is going on without getting under the hood and taking the time to explore your home turf.  With the work I put into my own network, I found so much joy in freeing up some WAN bandwidth and preventing traffic that I never considered or even knew existed until I took the step of dropping it all.

After implementing a zero trust model, my network is just as functional as before.  Sure, I still have to whitelist a host or port once in a while, but that's something we've always had to do with incoming traffic and it's just as easy when you need to do the same in reverse when the framework is in place and traffic is visible.