I first became aware of Nebula a few days ago, thanks to two excellent write-ups at Ars Technica. (here and here) It’s an open source product freely given to the world by the folks at Slack. (Best known for making billions putting a fresh skin on IRC.). While those two write-ups at Ars Technica do a decent job at introducing Nebula, I feel like a use case for Nebula that hasn’t been fully explained.
Nebula isn’t like the VPNs for which you are constantly bombarded with ads. It isn’t designed for you to hide your torrent traffic, or to mask your IP address. It is designed to secure communications between systems you control, and makes for an excellent building block in a Zero Trust implementation.
First off, what’s “Zero Trust”? It’s the idea that you can’t trust any of your infrastructure, any more than you could trust the Internet. It’s logical evolution of the old adage “never trust the client”. If you can’t trust the client, you can’t trust the network they are connected to either. Assume at all times:
- There’s a compromised device on your network sniffing traffic.
- All of those ‘Smart Appliances’ you got for Christmas are remotely hackable, if they weren’t flat out designed to attack your network from the inside.
- Any machine can have zero-day malware that isn’t detectable yet.
- The NSA has a tap on your AWS VPC (Virtual Private Cloud).
- Any of the Five Eyes countries have taps on the switches/routers at your ISP.
- The ‘free WiFi’ at the cafe is sniffing traffic to insert ads, or worse.
- Your ISP is sniffing traffic for * reason.
- Your SuperMicro server has the Magick Chip that sends data to China.
- Your network gear has Huawei components.
- One of your sysadmins didn’t get enough of a raise and has sold access to your network for fun and profit.
- There are a thousand other risk factors not on this list.
The old paradigm was built around a division of realms: the trusted home/office/datacenter network and the wild west of the Internet, with firewalls in between. That paradigm is shifting with the acceptance of the reality that devices inside your trusted network are going to be compromised. By accepting that, and making design decisions with that in mind, the impact of your future compromise(s) just might be reduced.
Now that you are starting to embrace the appropriate level of paranoia, how does Nebula VPN help? Nebula lets you create a mesh VPN between the hosts in your network, whether or not they are on the same subnet or in the same VPC. It allows you to secure traffic that was otherwise difficult to secure, or that you wouldn’t normally consider securing because it takes place in a ‘trusted’ layer of your network. With Nebula it becomes trivial to encrypt MySQL, MongoDB, Redis, Memcache, etc, traffic; restricting access to hosts with the appropriate certificates installed while also limiting exposure if another instance in your infrastructure becomes compromised.
Unlike traditional hub and spoke VPNs, Nebula functions as something closer to a mesh. In a traditional VPN, two clients who want to talk to each other would have to route their traffic to the server and back. With Nebula, clients negotiate the best way to talk to each other, using the shortest route possible. This is a far more efficient use of bandwidth.
I spent a couple of hours adding a new column on my IP/subnet spreadsheet, creating certificates, and writing a Puppet module to deploy Nebula in my quirky infrastructure. I now have a virtual VPN subnet that spans systems across two continents, where I can now use the Nebula IP for a host to automagically encrypt traffic.
I haven’t used Nebula long enough to run into any gotchas, which means I’m still a novice. Despite that, I do feel secure in saying that it makes for a powerful tool in your Security toolbox.
If you want to give it a try, this write-up at Ars Techica will have you up and running in ten minutes or so.