# Overview 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]({{< ref "/product/networking/security-group/how-to/restrict-outbound-traffic/" >}}). 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]({{< ref "/product/networking/security-group/overview#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.