Networking and Security

Firewalls, Protocols, and Subnets oh my!

Network security is of paramount importance as you design your infrastructure. To control data flow in your networks, you will want to apply a firewall to... well... everything!

Introduction

Tuono allows you to express your network security as restrictions on the inbound and outbound data flows for certain resources. You can configure these restrictions by defining a firewall and then applying it to a subnet or a nic.

Network data flow inspected by a firewall is always classified as either inbound or outbound. On an inbound data flow, from is the sender and to is the recipient. On an outbound data flow, the roles are reversed. Both the sender and recipient may be in the same subnet, and their data must be inspected as it enters and leaves the subnet.

The default settings (and best practices) for network security provides you with least-privilege access to network resources. This means all inbound traffic is denied unless you configure it to be allowed.

Tuono Concepts

Tuono uses a multi-tiered approach to keep your network safe. The Scope is an "immutable" set of rules that determine basic connectivity to other networks and subnets. Next, the firewall rules are defined by the user and modify the access -- firewall rules cannot extend network connectivity beyond what is allowed by scope. Then, the default policy determines what happens to packets that do not match firewall rules.

Default Policy

Each network can be configured with a default policy for inbound and outbound traffic. The default policy is the final catch-all rule applied to network traffic in a virtual network. The default settings for the default policy on a network are shown below:

Traffic Flow	Default Setting
inbound	deny
outbound	allow

Venue-Specific Implementation Details

The networking implementations in the different venues are a bit different. Each venue has a different means of restricting access, and different requirements to allow access. Tuono implements the networking in the different environments to achieve very similar behaviors.

AWS

Subnets

When a firewall is applied to a subnet, the subnet's Network Access Control List (NACL) is modified to match the rules. Even if no firewall is applied, a NACL is created for the subnet with a default set of rules based on the network default policy, and the scope.

A private-with-internet subnet allows outbound traffic to the Internet, so a Network Address Translation (NAT) Gateway is created to allow that traffic. The NAT Gateway requires access to a public subnet that must be part of the blueprint, or already exist in the VPC. In some cases (e.g. load balancer), Internet access is provided by an application that moves traffic from a subnet to the Internet -- in these cases the Internet traffic can be blocked (to avoid the need for a public subnet).

If your subnet allows inbound/outbound TCP communications with other subnets, the subnet's NACL will have a rule to allow the TCP replies (TCP ports 1024-65535) in the opposite direction. We do this because NACLs are a stateless packet filter, and the NACL would drop the TCP replies if this rule were not in place. While this may sound insecure, it is still more secure than AWS' own default policies which provide no inbound filtering on subnets.

NICs

When a firewall is applied to a NIC, the firewall rules are applied to the NIC's Security Group. Security groups are stateful, therefore the rules applied to the security group will be exactly what the firewall specifies.

Azure

All firewalls are converted to Network Security Groups, which are stateful. The rules applied to the NSG are exactly what the firewall specifies, plus some rules that Tuono adds to enforce the different network/subnet configurations.

The image below is an example of a NSG for an isolated subnet with a firewall that allows SSH (tcp/22). The specific rules are explained in detail in the following paragraph.

Azure Isolated Subnet NSG

Here's a breakdown of why the various rules are applied:

• 100 (inbound & outbound) - Blocks Internet access. Added by Tuono to insure subnet is not able to reach the Internet. It is the first rule evaluated, so it cannot be overridden by any firewall rules.

• 101 (inbound) - Allows SSH (tcp/22) within the subnet. Added due to firewall configuration.

• 4050 (inbound) - Allows all inbound traffic from load balancer. Added by Tuono.

• 4060 (inbound & outbound) - Allows all traffic within the subnet. Added by Tuono.

• 4061 (inbound & outbound) - Blocks all traffic for addresses outside this isolated subnet. Added by Tuono. See Note 1.

• 4095 (inbound & outbound) - Implements the network's default policy in the specified direction. Added by Tuono. See Note 2.

• 4096 (inbound & outbound) - Blocks all traffic for any address in both directions. Added by Tuono as a final backstop. See Note 2.

• 65,500+ (inbound & outbound) - Azure default rules. Added by Azure.

NOTES:

1. In an isolated subnet, no traffic goes beyond the 4061 rules. This means the 4095 and 4096 rules will never cause packets to get allowed or denied.

2. Tuono adds the last couple rules to implement the network default policy (4095), and as a final backstop (4096). These rules are implemented regardless of firewall policy, and insure that default Azure policy (rules 65,500+) do not impact Tuono networks.

The table below shows which rules are used in the various subnet types. The 4095 rule depends on the network default inbound/outbound policy, but the other rules remain constant in their allow/deny designation.

Priority	Description	Public	Private-with-internet	Private-no-internet	Isolated
100	Block Internet	None	In	In/Out	In/Out
101	User FW rules	In	In	In	In
4050	Balancer	In	In	In	In
4060	Allow Subnet traffic	In/Out	In/Out	In/Out	In/Out
4061	Isolate subnet	None	None	None	In/Out
4095	Default network policy	In/Out	In/Out	In/Out	In/Out
4096	Backstop	In/Out	In/Out	In/Out	In/Out