# Exoscale Documentation — Security Group > Security Groups: modular firewall rules enforced at the hypervisor level to control incoming and outgoing traffic of Compute instances. --- url: https://community.exoscale.com/product/networking/security-group/ --- # Security Group - [Quick Start - Security Group](https://community.exoscale.com/product/networking/security-group/quick-start/index.md) - Get started quickly with a guided setup to achieve your first successful use of the service, including the required steps and configuration. - [Overview - Security Group](https://community.exoscale.com/product/networking/security-group/overview/index.md) - Terminology and key features at a glance, learn the core concepts, capabilities, and options of this service before you dive deeper. - [How-To - Security Group](https://community.exoscale.com/product/networking/security-group/how-to/index.md) - Step-by-step guides to configure the service and use specific features, with clear instructions for common tasks and problem solving. - [Service Boundaries - Security Group](https://community.exoscale.com/product/networking/security-group/service-boundaries/index.md) - Service boundaries: quotas, limits, and the guaranteed service levels (SLA) for this product, including key constraints to plan and operate reliably. - [Reference - Security Group](https://community.exoscale.com/product/networking/security-group/reference/index.md) - Reference documentation for API, CLI, and tools, browse comprehensive details, parameters, commands, and integration notes. --- url: https://community.exoscale.com/product/networking/security-group/quick-start/ --- # Quick Start - Security Group 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](https://www.exoscale.com/syslog/new-sg-protos/). 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. ![](sg-add-group.png "The interface easily allows you to create your rules") ## Example: Access 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. ![](sg-templates.png "You can add some common rules in one click on") --- url: https://community.exoscale.com/product/networking/security-group/overview/ --- # Overview - Security Group 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. ![](sg-example-01.svg "An example of what you may easily achieve with Security Groups") ## Terminology Security Groups : A modular set of firewall rules managed at the hypervisor level to control incoming and outgoing network traffic. Firewall Rules : Rules defined within security groups that take precedence over default network traffic rules. Member Instances : Instances that are part of a security group, allowing the group to be used as traffic sources or destinations in rules. Layer 2 Filtering : Network layer filtering providing protection against spoofing and man-in-the-middle attacks. Ensures Ethernet isolation and prevents unauthorized ARP, DHCP, and traffic visibility. Layer 3 and Layer 4 Filtering : Network layer filtering that allows ingress and egress IP traffic to be managed by protocol, destination, and port settings. Egress & Ingress Filtering : Egress filtering relates to outgoing traffic that is fully allowed until a rule is applied, while ingress filtering by default denies all incoming traffic until rules are specified. Broadcast, Unknown-unicast and Multicast (BUM) Traffic : A type of network traffic that is generally dropped by egress rules to prevent traffic leakage and security breaches. ## Features Security Groups encapsulate two primary types of information: Traffic Rules : A comprehensive list of rules dedicated to managing and directing network traffic efficiently. Member Instances : This list includes member instances within the security group, enabling the utilization of groups as traffic sources or destinations in governing 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__ > [!NOTE] > By default, once you define an outbound rule, outbound traffic is restricted to only > what is allowed by those specified rules. For further details, consult the guide on > [restricting outbound traffic](https://community.exoscale.com/product/networking/security-group/how-to/restrict-outbound-traffic/index.md). 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](https://community.exoscale.com/product/networking/security-group/overview/index.md#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. 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 through 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](https://en.wikipedia.org/wiki/Broadcast,_unknown-unicast_and_multicast_traffic) 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. --- url: https://community.exoscale.com/product/networking/security-group/how-to/ --- # How-To - Security Group Step-by-step guides to configure the service and use specific features, with clear instructions for common tasks and problem solving. - [Allow SSH Access](https://community.exoscale.com/product/networking/security-group/how-to/allow-ssh/index.md) - Allow SSH access to Exoscale instances by adding a security group rule on port 22 and restricting the source CIDR to trusted IP ranges. - [Organize Security Groups](https://community.exoscale.com/product/networking/security-group/how-to/organizing-security-groups/index.md) - Organize security groups by role, combine reusable rules, and use public groups or static CIDRs to manage access across your infrastructure. - [Allow ICMP Ping](https://community.exoscale.com/product/networking/security-group/how-to/allow-ping/index.md) - Allow ICMP ping to your Exoscale instances by adding ingress security group rules for Echo requests to support monitoring and connectivity checks. - [Allow HTTP and HTTPS](https://community.exoscale.com/product/networking/security-group/how-to/allow-http-https/index.md) - Allow HTTP and HTTPS traffic with security group ingress rules on ports 80 and 443 so your instance can serve web applications publicly. - [Allow Web Traffic](https://community.exoscale.com/product/networking/security-group/how-to/allow-outbound-reply/index.md) - Allow outbound ICMP Echo Reply traffic in Exoscale Security Groups to support ping responses when your instance restricts outbound traffic. - [Restrict Outbound Traffic](https://community.exoscale.com/product/networking/security-group/how-to/restrict-outbound-traffic/index.md) - Restrict outbound traffic with security group egress rules while preserving required access for first-boot passwords and SSH key deployment. --- url: https://community.exoscale.com/product/networking/security-group/how-to/allow-ssh/ --- # Allow SSH Access After an instance is deployed, if you want to manage it via `SSH`, you should [allow incoming traffic](https://community.exoscale.com/product/networking/security-group/overview/index.md#A_simple_example) on __port 22__. However, we recommend that you create a Security Group dedicated to the management of your machines. If you add some granularity in your security groups, will make work easier when you have more complex setups. * Create a new security group called **management**. * Add a new rule: `INGRESS`, TCP, port 22. * Change the CIDR for this rule to your IP range. You **don't want to allow every IP** to be able to connect to your machine via SSH. ![](sg-management.png "Management Security Group") Add this security group to the instances you want to manage via SSH. --- url: https://community.exoscale.com/product/networking/security-group/how-to/organizing-security-groups/ --- # Organize 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. --- url: https://community.exoscale.com/product/networking/security-group/how-to/allow-ping/ --- # Allow ICMP Ping The Internet Protocol (`IP`) supports more than just `TCP` and `UDP` traffic; it can also carry `ICMP` messages. By default, all `ICMP` requests are closed on your instances. However, adding an `ECHO REPLY ICMP` traffic rule to your security group allows you to ping your instance. Enabling `PING` makes it easier to integrate with your preferred monitoring tool or service. To enable ingress ping connectivity to your instance, follow these steps: 1. **Choose the Security Group** Navigate to the instance list in the Portal and select the security group associated with your instance to which you want to add ping traffic. Note that enabling ping will also apply to all instances attached to this security group. 2. **Add a Rule** Within the selected security group, create an `INGRESS` rule. Be sure to restrict the source IP or network range, and select the `ICMP` protocol. 3. **Configure Echo** Set the type to `ECHO (type 8)` and the code to `NO CODE`. 4. **Save** Click **ADD** to save your rule. Please allow some time for the rule to propagate. ![](allow-ping-2.png "Adding Echo ICMP Rule") The resulting rules appear like this: ![](allow-ping-1.png "Echo ICMP Rule") ![](allow-ping-3.png "Adding Echo Reply ICMP Rule") --- url: https://community.exoscale.com/product/networking/security-group/how-to/allow-http-https/ --- # Allow HTTP and HTTPS When you deploy an application on your server, you might want it accessible via a browser, either via `HTTP` or `HTTPS`. To do that, you need **ingress** rules in a security group to allow communication on __port 80__ (`HTTP`) and __port 443__ (`HTTPS`). * Create a new security group called **frontend** * Add a first rule: `INGRESS, TCP, CIDR 0.0.0.0/0, port 80-80` * Add another rule: `INGRESS, TCP, CIDR 0.0.0.0/0, port 443-443` Now the instances using this security group will allow traffic from any IP (CIDR 0.0.0.0/0) on port 80 and 443. ![](sg-frontend.png "Frontend Security Group") Add this Security Group to the instance that will be accessed via `HTTP` and `HTTPS`. > [!NOTE] > If your instance only has this Security Group, you will not be able to access it via `SSH`. --- url: https://community.exoscale.com/product/networking/security-group/how-to/allow-outbound-reply/ --- # Allow Web Traffic If your outbound traffic is restricted and you need to allow outbound `ICMP ECHO REPLY` traffic, you can achieve this by adding a specific outbound rule to your Exoscale Security Group. This guide will help you configure the rule to permit `ICMP Type ECHO REPLY (type 0)` with no code, ensuring proper ping functionality. ## Steps to Allow Outbound Reply 1. **Access the Exoscale Portal** - Log in to your Exoscale account. - Navigate to the **Compute** section and access your instance. 2. **Select Security Group** - From your instance details, locate the **Security Group** settings. - Choose the relevant security group to which your instance is attached. This is the group where you'll add the outbound rule. 3. **Configure Outbound Rule** - Within the selected Security Group, go to the **Outbound Rules** section. - Click on the **Add Rule** button to begin creating a new outbound rule. 4. **Specify ICMP Protocol** - In the protocol selection, choose `ICMP`. - Set the Type to `ECHO REPLY (type 0)`. - Leave the code field as `NO CODE` since no specific code is required for this ICMP type. 5. **Restrict Destination (Optional)** - If desired, specify a destination IP address or network range to restrict which IPs can receive outbound ECHO REPLY messages. By default, this will be open to all. 6. **Save the Rule** - After configuring the rule parameters, click on **ADD** to save the changes. - Allow some time for the changes to take effect and propagate through your instance setup. 7. **Verification** - Test your configuration by performing a ping operation from an internal service or monitoring tool. The outbound ICMP ECHO REPLY responses should now be successful. --- url: https://community.exoscale.com/product/networking/security-group/how-to/restrict-outbound-traffic/ --- # Restrict Outbound Traffic By default and without any rule specified, all outbound traffic is authorized. However, as soon as you add your first outbound rule, only the traffic explicitly declared in outbound rules is allowed. If you need to restrict outbound traffic, please note that the following TCP rules must be added: * Destination subnet `185.19.28.0/22`, start port: 80, end port: 80. * Destination subnet `185.19.28.0/22`, start port: 8080, end port: 8080. * Destination subnet `159.100.240.0/20`, start port: 80, end port: 80. * Destination subnet `159.100.240.0/20`, start port: 8080, end port: 8080. The screenshot below shows a security group with the correct configuration: ![](outbound-security-rules.png "Outbound Rules") These two rules are required for: * Setting the root (Linux) or administrator (Windows) account password on first boot. * Deploying your SSH key (Linux). --- url: https://community.exoscale.com/product/networking/security-group/service-boundaries/ --- # Service Boundaries - Security Group - [Limits and Quotas - Security Group](https://community.exoscale.com/product/networking/security-group/service-boundaries/limits-and-quotas/index.md) - Security Group Limitations and Quotas - [SLA - Security Group](https://community.exoscale.com/product/networking/security-group/service-boundaries/sla/index.md) - Security Group Service Level Agreement --- url: https://community.exoscale.com/product/networking/security-group/service-boundaries/limits-and-quotas/ --- # Limits and Quotas - Security Group ## Limits No Limits. ## Quotas | Usage | Quota | | -------------------------------------------------------- | ------------------------ | | Security Group count | 60 | ## Availability Security Group is available in all zones. --- url: https://community.exoscale.com/product/networking/security-group/service-boundaries/sla/ --- # SLA - Security Group ### Claim Service Credit To request a service credit, refer to the Service Unavailability Credit section of the [Exoscale Terms and Conditions](https://www.exoscale.com/terms/) or the [EUSA](https://www.exoscale.com/eusa/), whichever applies. --- url: https://community.exoscale.com/product/networking/security-group/reference/ --- # Reference - Security Group - [API Security Group](https://community.exoscale.com/reference/api/compute/security-group/index.md) - All operations on Security Group. (external) - [CLI Security Group](https://community.exoscale.com/reference/cli/exo/compute/security-group/index.md) - All commands on Security Group. (external)