Security Groups and Firewalling

Tagged in

Exoscale Security Groups provide a modular way to define and compose firewall rules. The rules are managed at the hypervisor level in order to restrict incoming and outgoing network traffic.

Security Groups give you the power of VLANs while keeping a single public IP.

An example of what you may easily achieve with Security Groups

Security Group Components

Security Groups hold two different types of information:

A list of rules to apply to traffic
A list of member instances in the security group which allows using groups as traffic sources or destinations in rules

Default Firewall Rules

When you create an instance, you can attribute one or more security groups to it. Firewall rules defined in your security groups take precedence over the default rules, which are:

All outgoing traffic is allowed
All incoming traffic is forbidden

A new instance with the default unmodified security group will be completely inaccessible from outside.

If you wish to ping your instance or access it via SSH, you will have to define incoming rules for the instance.

Outgoing Traffic

By default, an unmodified security group without any rule specified allows any kind of outbound traffic.

However, as soon as you define an outbound rule, outbound traffic is only allowed for the defined outbound rules. Any outgoing traffic not allowed by a rule will be then blocked. See managing outbound security rules for more information.

Access to outbound SMTP is restricted by default to prevent common spam abuse. SMTP access can be requested within the security groups section in the Portal.

Security Group Rule Features

When adding a rule to a security group, you can set the following properties:

Traffic type: INGRESS (incoming) or EGRESS (outgoing).
Source type: a CIDR or a security group. Source type allows you to define internal rules between security groups without using IP addresses directly. Traffic between your machines will be routed internally with no exposure to the internet.
Protocol: TCP, UDP or ICMP. The special tunneling protocols AH, ESP and GRE are also available. Learn more on our blog.
Start port and end port: define rules for a specific port (the same port as start and end port) or for a whole range.

Additionally ICMP protocol let you specify type and code.

The interface easily allows you to create your rules

Example: Access an Instance via SSH

Say you want to access your instance via SSH. On a new instance with no custom SSH configuration, you will need to set a rule in an attributed security group to allow TCP ingress on port 22. You can set it as follows:

Type: INGRESS
Protocol: TCP
Source: 0.0.0.0/0
Start Port: 22
End Port: 22

For the most common cases, you can choose between PING, SSH and RDP in the Portal.

You can add some common rules in one click on

Organizing Security Groups

You can add several security groups to an instance during its creation, and add or remove groups later in the instance detail.

It is important to carefully think about your Security Groups when setting up any infrastructure. A common practice is to identify roles in your infrastructure. For example, an application infrastructure could be composed of:

application servers
cache servers
load balancers
database servers
et cetera

In this case you could have:

A security group called “Common” that defines rules that are common to all instances, such as SSH access or internal communication.
One security group per role, defining rules specifically for database servers or load balancers.

When setting up a new database server, you would give it the “Common” and the “Database” security groups.

It is also good practice to apply this technique even with small architectures, where a single instance can play all different roles. This way, your infrastructure is ready for any future growth and allows for later separation of services across different instances.

Public Security Groups

In addition to groups you define yourself, Exoscale maintains a list of public security groups with particular characteristics, useful for referencing in your architecture. These groups represents Exoscale resources that are dynamically managed. At the time of writing the public security groups are:

public-nlb-healthcheck-sources: a group with all IP addresses from Exoscale infrastructure that may reach out to test the availability of a pool of resources.
public-sos-endpoints: a group with the Simple Object Storage endpoint that can be used to limit egress traffic for example for an instance that could only retrieve data from an SOS bucket but not the global Internet.
public-sks-apiservers: a group with the IP addresses used by SKS Nodepools to communicate with the API Server of the Kubernetes control plane.

Extending Security Group Members with Static IP Ranges

If you intend to use security groups as a way to manage both your Exoscale hosted infrastructure and some external resources, external source support allows for registering static CIDRs as security group members.

External sources are added as valid sources for ingress rules or valid destinations for egress rules on target hosts. An alternative use case could be to create a security group dedicated to holding a set of external sources, then reference this security group in other security groups that are actually applying the network filtering rules.

Add a Security Group to your Instance

Usually, you attribute one or more security groups during the instance creation process. Note that an instance must belong to at least one security group.

During the creation process, you will find your primary group already selected. You can change your primary group from the security groups list.

If you need to change an instance’s groups, you can use the instance detail. You can add and remove groups as needed, so long as the instance is stopped.

Layer 2 Filtering

Security groups provide Layer 2 filtering to keep your instance safe from different types of spoofing and man-in-the-middle attacks. This filtering is managed automatically for you.

For example, the following traffic will be dropped:

ARP is allowed only when the source MAC matches the instance’s assigned MAC address, so it is not possible to spoof an instance MAC address.
An instance cannot send ARP responses for an IP address it does not own.
An instance cannot spoof a DHCP server response.
If you run Wireshark/tcpdump within your instance, you will not see your neighbor’s traffic, even though your NIC is set to promiscuous mode.

With security groups on Exoscale, Layer 2 Ethernet isolation is enforced. This is commonly achieved using VLANs on a standard architecture.

Layer 3 and Layer 4 Filtering

Security groups provide Layer 3 filtering, which can be managed trough the Portal or API:

Ingress and egress IP traffic can filtered by Protocol / destination / destination port.
By default, all ingress is denied and egress is fully allowed until you create a first rule. As soon as you create an egress rule, only the matching traffic will be allowed.
Egress filtering is preventing any broadcast / multicast traffic to leave your instance.

Layer 3 and 4 filtering typically take an IP address or security group for source parameters:

The IP address should be in the form of a single IP or network. For example, 8.8.8.8/32 or 0.0.0.0/0 are valid entries.
The security group can be a self declaration for allowing traffic from instances belonging to the same group or another security group.

BUM Traffic

BUM is dropped by egress rule. This is an expected behavior, as we don’t want anyone to receive this type of traffic, which could also leak sensitive information. Therefore, any application relying on Broadcast, Unknown unicast and Multicast traffic type will not work.