Getting Started

First Time Users

To get started with Nubeva TLS Visibility Solution, start by creating an account and log in on the Nubeva Manager (console):

1. Navigate to www.nubeva.com and select ‘Login’ from the main menu.

2. First-time users will be prompted to create an account. Go ahead and use one of the OAuth partners to log in.

Note

Nubeva only supports OAUTH logins through Google, Microsoft, and Amazon. We do not ask you for a password, and do not store your passwords or keys.

3. When you log in to Nubeva Manager for the first time, you will see a helper block which provides useful links to on-line guides and videos. You can revisit this information on the Help page. You are automatically subscribed to a free trial for 30 days. You may upgrade your subscription at any time before the end of the trial by clicking the upgrade button in the main menu bar, or by selecting the Subscription option from the account menu as shown in the figure below:

When you log in a ‘Default Project’ is created automatically for you. As part of creating a project, Nubeva Manager also creates a DynamoDB table to store session keys which the Nubeva Sensors extract.

Tip

You should replaced the default DynamoDB table with one in your own account when going to production. Instructions are provided later in this section.

TLS Key Extraction

Extracting keys and decrypting workloads requires five steps:

1. Installing Nubeva Sensors
2. Creating Source Groups
3. Installing Decryptor Engines
4. Configuring Cloud Tools
5. Mirroing traffic

The visual tiggers for each step are marked in the figure below:

Installing Nubeva Sensors

As shown in figure 1 in the previous section Nubeva Sensors mirror traffic as well as extract session keys from encrypted traffic. Nubeva Sensors are available for Linux and MS Windows.

1. Linux sensors are available as Docker containers as well as a standalone installation. You can skip this step if your instance is already running the required version of Docker. If you need to install docker please refer to Docker Installation for instructions.

Note

Nubeva sensors can be run as daemonsets in Kubernetes clusters. Nubeva sensors require Kubernetes versions 1.11 or greater.

2. Click on the top icon in the left corner of the Source Group box.
3. This will pop up a box similar to the figure below. Select ‘Container Sensor’ from the drop-down menu. Click the button on the right to copy the installation command.

4. Paste this command into a command shell on the cloud instance. The sensor container will automatically download and install.
5. About 10-20 seconds after installation, the Active sensors counter in the Source Groups box will increase by 1 indicating that the sensor is active.

7. To launch a native Linux installer select the options shown in the figure below:

7. To launch a Windows sensor, select “Windows Sensor” from the drop-down.

8. Paste this command into a command shell on the cloud instance. The sensor installer will automatically download and install from Docker Hub.

Note

The last command is:

& "$DownloadDir\installer.exe" NUTOKEN_USERINPUT=$NubevaTok  API_URL_ARG=${InstallerArg} /q;

To enable detailed logging replace the last command with:

& "$DownloadDir\installer.exe" NUTOKEN_USERINPUT=$NubevaTok  API_URL_ARG=${InstallerArg} /q /L*V "$DownloadDir\installer.log";
"Debugging logs are in: '$DownloadDir\installer.log'

Tip

If you would like to extract keys from nodes running in a Kubernetes cluster please do the following:

1. Download https://nubevalabs.s3.amazonaws.com/nuAgentDaemonSet.yaml
2. Edit the file and replace the value of the nutoken placeholder with the value that is used in your project. This is the value of the nutoken parameter in the sensor-launch dialogs depicted above.
3. Run

kubectl apply -f nuAgentDaemonSet.yaml

The next step is to configure source groups.

Creating Source Groups

Source groups are policies for grouping Cloud Agents based on their metadata and custom tags. The following links provide additional information: AWS Metadata, AWS Custom Tags, Azure Metadata, Azure Custom Tags.

Note

Source group policies also determine whether the sensors should extract and store session keys in a private DynamoDB table in your account. For additional security and scaling, Nubeva supports Amazon DynamoDB as a Private KeyDB. Other cloud DBs such as Azure Cosmos DB or Google Cloud Data-store are on the road-map. Please contact us if you are interested in those platforms.

Security in Amazon DynamoDB: All communication of keys and associated meta-data is encrypted both in transit and at rest. The session keys for the sensor to KeyDB communication is NEVER saved. All user data stored in Amazon DynamoDB is fully encrypted at rest. DynamoDB encryption at rest provides enhanced security by encrypting all data at rest using encryption keys stored in AWS Key Management Service (AWS KMS). Nubeva has no access to this Private KeyDB running on Amazon DynamoDB.

Using Amazon VPC endpoints to access DynamoDB: For additional security Nubeva suggests that you use VPC endpoints for all connectivity to a Private KeyDB running on Amazon DynamoDB.. When you create a VPC endpoint for DynamoDB, any requests to a DynamoDB endpoint within the Region (for example, dynamodb.us-west-2.amazonaws.com) are routed to a private DynamoDB endpoint within the Amazon network. You don’t need to modify your applications running on EC2 instances in your VPC. The endpoint name remains the same, but the route to DynamoDB stays entirely within the Amazon network, and does not access the public Internet.

These are the steps to create a source group:

1. Click on the lower icon at the top right of the “Source Group” box. This will load the Source Group editing window.

2. Name the new source group.
3. Click on the Filter Type (leftmost) drop down to select either ‘Metadata’ or ‘Custom Tags’.

Note

On AWS permission has to be given to describe all instances because the scope of DescribeInstances cannot be limited to a single instance. Creating an AWS IAM role for custom tag support

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeInstances"
            ],
            "Resource": "*"
        }
    ]
}

4. Click on the Metadata Category in the “Source Inclusion Policy” and choose something. Select the condition and select the values. Then click the ‘+’ button.
5. You can add multiple conditions.
6. Select save. This will return you to the dashboard.

Tip

By default key extraction is turned on. The check box in the upper right corner allows you to turn key discovery on/off for the sensors included in the source group.

As new sensors with matching meta-data and/or custom tags appear, they are automatically added to the source group. This is a powerful adaptation to the elastic nature of cloud environments. For instance, if you routinely spin up/down instances with web scaling events, selecting filters such as AMI type, VPC, subnet, or custom tag values, will ensure that any new sensors that appear will be immediately added to the source groups and start extracting keys and/or mirroring traffic to tools based on the existing connections or mirrors defined.

Launching Decryptors

1. Docker is a prerequisite to running containers. You can skip this step If your instance is already running the required version of Docker. If you need to install Docker please refer to Docker Installation for instructions.

2. Click on the “Lock” (top) icon on the top left of the Destination Group box.
3. This will display the popup depicted in figure below. Click the button on the right to copy the installation command.

4. Paste this command into a command shell on the decryptor cloud instance. The decryptor container will automatically download and install.
5. About 10-20 seconds after installation, the decryptor counter in the Destination Groups box will increase by 1 indicating that the decryptor is active.
6. If you would like to launch a cloud security tool to process the decrypted packets, please refer to the Tool Launcher section.

Note

Refer to Deploying Security Tools for comprehensive instructions for launching security tools based on the AWS Well-Architected Architecture.

The final step is to mirror traffic to your decryptor. This can be done by using AWS VPC Traffic Mirrors or by defining destinations and connections between source groups and destinations.

Packet Mirroring

Note

You can set up traffic mirroring without running Nubeva Decryptors. The traffic reaching the target security tool will be encrypted. If you are using AWS VPC Traffic Mirrors you can skip to Decrypting AWS VPC Traffic Mirroring.

Creating Destinations

Destinations are define the IP addresses of instances running Cloud Tools. There are many packet inspection and processing tools in the open source community as well as many vendor offerings. Before we create a destination in the UI, we need to have an actual tool.

These are the steps to create a destination that points to a tool:

1. Click on the “Marker” (bottom) icon on the “Destinations” box.
2. The next screen allows you to define the properties of this new destination group.

3. Name the destination.
4. Choose between a single tool or a set of tools that you want to load share against. For a load share environment, insert multiple comma-separated IP addresses into the field and the traffic will be load-shared among the defined tools.

Note

If you need more advanced load-balancing, you can use the front-end IP address of a cloud load balancer as the IP and configure this LB via the cloud portals.  To enable VXLAN traffic to your destination inbound traffic should be enabled on UDP port 4789.

One of the simplest tools you can use is tcpdump. This is a simple Unix command that takes all data received on an interface and displays it on the screen. You also use it to write this traffic to a file.

Create a Unix instance in your cloud provider. Connect to it and issue the command:

tcpdump -na -i eth0 port 4789

This will start a tcpdump session which will display all mirrored traffic on your default interface but it will not show your SSH session traffic.

5. Click ‘save’ when finished.

Creating Connections

At this point, you can have one or more source groups and one or more tool destinations.

1. To connect a source group to a destination/tool, simply click on the source and drag the connection line to the required destination and drop it. This will popup the following connection profile window, with the ‘Source Group’ and ‘Destination Group’ values preset.

2. You can also click on the the icon in top left corner of on the Connections box and it will take you to the same screen, but you will have to choose the Source Group and Destination Group from their drop-down.

3. You can use VXLAN tunnel encapsulation to send traffic to the destination. The VNI ID should be a unique number for the source group.
4. Berkeley Packet Filter (BPF) is where you enter the data filters you want to apply to this connection.
5. Click save to return to the dashboard. You will see mirroring indications in the diagram as well as the ‘throughput’ value in the connections box:

If you generate encrypted traffic on your source instance:

# run some https traffic on the client
curl https://example.com

You can see the decrypted traffic on your destination by issuing the command on the decryptor instance:

tcpdump -Ani nurx0 port 80

Decrypting AWS VPC Traffic Mirroring

To decrypt Amazon VPC traffic mirroring follow the first three steps described above:

1. Installing Nubeva Sensors
2. Creating Source Groups
3. Launching Decryptors

Since the AWS VPC traffic mirrors are generating the packet flow, there is no need to create connections. Instead, setup an AWS VPC traffic mirroring session between your source where the nubeva sensor is running, and the destination where you installed the decryptor engine.

To set up a traffic mirroring session please review Working With AWS Traffic Mirroring. Additional information is available on the AWS News Blog.