About Security Group Rules
A security group contains rules that can be added or removed at any time.
These rules control access to the virtual machines (VMs) with which the security group is associated. They determine which inbound flows are allowed to reach the VMs, and which outbound flows are allowed to leave them.
General Information
Security group rules cannot explicitly deny an access. An access is denied by default unless it is explicitly allowed in a security group rule.
When modifying a security group rule, changes are automatically and immediately applied to all VMs the security group is associated with.
Security groups are stateful, which means that responses to allowed flows are allowed too. Thus, response flows to requests sent from the VM are automatically allowed regardless of its security groups inbound rules. In a Net, response flows to allowed inbound flows are also allowed regardless of its security groups outbound rules.
Since it is recommended to use a VM for one service only, we recommend creating one security group per service, with the appropriate rules, and associating the security group with all VMs dedicated to this service. You can then allow inbound and outbound flows between security groups depending on which services need to communicate with one another in order to apply these rules to all the VMs concerned.
Characteristics
When creating a security group rule, you specify the following four elements:
-
The flows direction.
-
The flows protocol (TCP, UDP, ICMP, or
-1
for all protocols). In a Net, this can also be an IP protocol number. For more information, see the IANA.org website. -
The port or port range, between 1 and 65535 for TCP and UDP protocols, or the ICMP type number. You can also specify all ICMP types using
-1
.Avoid opening flows on all ports (
1-65535
), as it prevents you from effectively controlling them. Only open flows on the ports you need.In Cockpit, you can select predefined services corresponding to specific combinations of flows protocols and ports/ICMP type numbers:
Service Protocol Port SSH
TCP
22
HTTP
TCP
80
HTTPS
TCP
443
DNS
UDP
53
IMAP
TCP
143
Secure IMAP
TCP
993
POP3
TCP
110
Secure POP3
TCP
995
SMTP
TCP
25
SMTPS
TCP
465
LDAP
TCP
389
MySQL
TCP
3306
MS SQL
TCP
1433
ICMP
ICMP
-1
RDP
TCP
3389
-
The target, that is, one of the following options for the inbound flows source or the outbound flows destination:
-
An IP, in CIDR notation. You can specify either a public or a private IP.
As the public IP changes every time you stop and start your VM, security group rules based on a public IP may become irrelevant.
To associate a public IP to your VM through the stop and start process, you can use an OUTSCALE tag that specifies a public IP. For more information, see About Public IPs > Public IP Association.
-
A range of IPs, in CIDR notation (for example
101.365.245.3/16
).Using a
/0
prefix opens the specified port or port range to everyone. We strongly recommend not to use it on your administration port (SSH port 22 for Linux, or RDP port 3389 for Windows), as this can make your resources vulnerable to attacks. -
Another security group, to allow flows from or to all VMs that this security group is associated with:
-
If your security group is for use in the public Cloud, you can reference a security group for the public Cloud that belongs to your account or to another account.
-
If your security group is for use in a Net, you can reference a security group for the same Net.
To allow VMs associated with the same custom security group to communicate with one another, you need to create a rule that explicitly allows inbound flows coming from this security group.
By default, traffic between two security groups is allowed through both public and private IPs. To restrict it to private IPs only, contact our Support team.
-
-
(outbound flows only) A prefix list ID to allow traffic from VMs in a Net to access a service (for example, OUTSCALE Object Storage). For more information, see Getting Information About Prefix Lists.
-
Related Pages