Security Groups and Firewalling
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.
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.
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.
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:
- 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.
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.
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, 126.96.36.199/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 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.
More on Security Groups
We just scratched the surface about security groups. You can find more tutorials and resources about them:
How to modify Security Groups attributed to an instance (from our blog).
Another example on how to set up PING, and understanding the ICMP protocol.
A detailed explanation about outbound traffic rules.
A great example on how to use Security Groups for a more complex setup, combining them to obtain network isolation (also from our blog).