Security groups enable the instrumentation of security features in cloud environments such as Exoscale. They are your baseline for security before any application or user come into play. Security groups are one of the features which separate VPS offerings from cloud platforms as we detailed in a previous article. In this article we will look at what exactly security groups are and how they work behind the scenes.
Is it more than just iptables?
In essence, security groups are a more abstract way of handling firewall rules. They represent a distributed firewall that protects every virtual machine assigned to that security group. This firewall protects traffic before it reaches virtual machine instances and thus provides less attack surface than a local firewall would on instances. Manually, on a Linux server cluster, that would mean adding lines to iptables on one machine and copying those rules to all other machines that should have the same firewall rules.
Any topology change, i.e. any change to a specific group of machine sharing the same set of rules, implies a change to the rules on all these machines. This is a burdensome process which leaves a lot of room for human error. Some very good explanations about iptables and Linux firewalling in general can be found in the Arch Linux wiki and the Gentoo Wiki. To offset this, good cloud platforms offer security groups which allow automated and programmable security rule implementation and updates, including topology changes.
There are two types of network traffic: inbound and outbound. Both should be secured. As a default rule for most cloud providers, outbound (egress) traffic is allowed whereas inbound (ingress) traffic is blocked. For maximum security scenarios, both ways can be secured to contain only those ports that are needed for outgoing traffic. If your system gets compromised in any way, e.g. by a glitch in your system, cross-site-scripting, or various dependencies you are using, allowing all outbound traffic means that once malicious code enters your system, it can be used to send your data and information elsewhere or attack other systems from your infrastructure.
Inbound traffic describes all packets that want to access your machine(s). This also includes your access to your own instance. For a typical one machine deployment running a web server and providing SSH access, you would need TCP ports 22 and port 80 enabled for incoming traffic. At Exoscale, security rule creation is straightforward; you choose whether you want to create an ingress or egress rule, then specify the protocol, port range, and your new rule is ready.
If you create an inbound rule, the packets that are created as a response will come through as well, you do not need to create an additional outbound rule. This is possible because stateful firewalls, used by Exoscale’s security group feature, keep track of TCP sessions and the state of each packet. For information on outbound rules, please read our documentation on outbound security group rules. As mentioned, all outbound traffic is authorised initially. When the first egress rule is created, all ports except those mentioned in the egress rules are rejected.
The points where security groups excel in comparison to home-grown editions of firewall rules are speed, reliability, and maintenance. It is faster and less error-prone to leverage security groups than to run your own server cluster and have to take care of the baseline security yourself, while providing better isolation. You can assign several instances to one security group and have different security groups for different types of instances. To learn more on how to achieve VLAN-like isolation on top of security groups, you can refer to our article on Network Isolation using security groups.
As always, comprehensive details on security groups can be found in our documentation.