Getting Started with Nebula

Nebula: https://github.com/slackhq/nebula

GNS3: https://www.gns3.com/

Nebula provides a way of securely connecting devices within a network or across the internet while enforcing security in a way similar to how cloud security groups function. It allows you to add devices to groups and write rules that control access based on the group of the machine requesting access. It is also capable of allowing connection to devices that are behind NATs.

This post is going to be covering the installation of Nebula with a lighthouse, certificate authority, and a couple of nodes. Below is the topology for the GNS3 lab environment I have setup.

Certificate Authority

First, we need to have a system that acts as the certificate authority. On the CA, we need to download the binaries from the Github page.

wget -c https://github.com/slackhq/nebula/releases/download/v1.0.0/nebula-linux-amd64.tar.gz -O nebula.tar.gz

tar -xzf nebula.tar.gz

Now that we have the binaries downloaded and unpacked, the nebula-cert executable is what we will be using.  First, we need to set the name of the organization:

./nebula-cert ca -name "Testorganization"

There should be two files created, ca.key and ca.crt.  ca.key is the file used to sign every cert so make sure to encrypt it and keep it safe.Next, we need to create host keys and certificates for each machine that is going to be in the Nebula Network. First, some notes on these commands: The “-groups” field can added to the end and can contain the names of several groups separated by commas which can be used when defining rules later. The IP address of the systems is the IP inside the Nebula Network, not the IP address the system currently has.

./nebula-cert sign -name "lighthouse1" -ip "192.168.100.1/24"
./nebula-cert sign -name "host1" -ip "192.168.100.10/24"
./nebula-cert sign -name "host2" -ip "192.168.100.11/24"

We need to transfer the {host}.crt and {host}.key to their respective hosts, and the ca.crt is copied to every host. I used SCP to the lighthouse system since all of my machines are able to access the lighthouse. (Note: I do not suggest using the lighthouse as a distribution method for the certs and keys, I am simply doing it as the CA and site machines are harder to reach and this is a lab environment.)

Lighthouse

Now that we have our certs on their machines, we should set up the lighthouse. This machine should be publicly routable and is used for connecting harder to reach systems. It should be created with a cloud provider such as AWS or DigitalOcean, and needs to be accessible on port 4242.

First, we need to download the binaries and an example configuration.

wget -c https://raw.githubusercontent.com/slackhq/nebula/master/examples/config.yml -O config.yml

Inside the config, we need to specify that this system is a lighthouse, as well as a few other changes. Importantly we need to remove all entries from the “hosts” section under “lighthouse.” We also need to specify the path and name of the crt and key files.

Before starting the nebula process, we need to move the lighthouse.key, lighthouse.crt, and copy ca.crt into /etc/nebula/. This is the default directory in the config file, and can be changed at the top of the config file if you prefer. Once the files are in the proper destination, we can run the nebula script and point to the config file.

./nebula -config /path/to/config.yaml

Node Setup

Now that the lighthouse is setup and listening, its time to set up the nodes. The process is the same for all of the nodes so repeat the process with the proper certificate and file names. First we need to copy the certificates and keys over to the host from our lighthouse and download the binaries and configuration as before.Once the files are in place, we need to edit the config to contain the proper names of the files as well as specify the lighthouse we just setup. Make sure to set “am_lighthouse” to false, and to specify the lighthouse in the “static_host_map” as well as “hosts”.

I am going to leave the port as default for the nodes as well. It is recommended to change the port to 0 on nodes so that it will choose a random port to listen on.

Now we just need to run the nebula script on the node.

./nebula -config /path/to/config.yaml

We can see that the handshake was sent and received with the lighthouse. So try to ping the lighthouse’s nebula address.

Now complete the same process on the other nodes.Once all nodes are setup, ensure they can ping each other by their nebula address.

We can see the delay in the ping on the left as the handshakes were being exchanged.And that is all for the basic setup of Nebula, you can repeat this with as many nodes as you would like.

The next post about writing firewall rules for Nebula and how to only allow access to a system if the request is from the Nebula network can be found here. And I will also be making a post about using Nebula as a remote access VPN to your home server.