Security group practices of the cloud server ECS (Part 1)

Migrating applications to the cloud is not only a transformation of resource lifecycle management and application delivery, but more importantly, a mindset shift. This document series briefly describes an important concept of cloudization - the security group. Being the first part of this series, this document mainly describes the concept and restrictions of security groups and explains how to configure inbound rules.
Concept and restrictions of security groups
As an important security isolation method, security groups function as virtual firewalls in the cloud and set network access control policies for one or more ECS instances. When creating ECS instances, you must select a security group. You can also add security group rules to control outbound and inbound network access for all ECS instances in the security group.
Security groups are subject to the following restrictions:
• Each account can create up to 50 security groups, each of which can include up to 100 security group rules.
• A single instance can join up to 5 security groups of the same network type.
• By default, resources in the same security group are accessible on the internet while those in different security groups are inaccessible from the internet.
• Given that security groups are essentially whitelist items, grant minimum permissions whenever possible and deny any access by default.
• A single security group supports up to 1,000 instances.
When creating a security group, the default rule for outbound traffic is "accept all" while that for inbound traffic is "deny all". When using inbound and outbound rules of security groups, many users do not actually classify them based on the specifications of their applications. This increases potential risks of attacks to their applications.
In addition to limiting IP addresses and CIDR network segments, inbound and outbound rules of a security group can also directly reference another security group, preventing inflexible CIDR or IP addresses at times and allowing you to authorize resources of another security group. In this way, you can layer applications through security groups.
• Inbound rules of a security group can be set as those of another security group of the same network type ("VPC" or "classic network"). In this case, the property is SourceGroupId.
• Outbound rules of a security group can be set as those of another security group of the same network type ("VPC" or "classic network"). In this case, the property is DestGroupId.
• Inbound and outbound rules can be set with a Priority, which is 1 at the maximum and 100 at the minimum.
• Security groups also support cross-account authorization, which is an advanced function and will be introduced in the future.
During cloudization, many users do not give full consideration to the configuration and long-term planning of inbound and outbound rules of security groups, imposing a negative impact on the scalability of their businesses. Comparatively, rational planning of security groups can help minimize attack risks and help streamline inter-application structures and layers. The following describes the first part of security group best practices.
Best practices
Before creating security groups, follow the suggestions below.
• Security groups should be configured as whitelist items and this is the most important rule.
• Configure and enable inbound and outbound rules with granting minimum permission in mind. For example, you can open a specific port such as port 80.
• Using a single security group to manage all applications is difficult as different layers have different requirements.
• For distributed applications that are common today, different application types should be configured with different security groups. For example, you can use different security groups for the web, service, database and cache layers to apply different inbound/outbound rules and permissions.
• Also, setting a security group for each instance is unnecessary as this imposes high management costs.
• Use VPC networks whenever possible.
• Do not provide internet IP addresses for resources that require no access to the internet.
• As a single instance can be assigned with multiple security groups, each instance can be applied with hundreds of rules at a time. All assigned security rules are aggregated to determine whether inbound or outbound traffic is permitted or not. However, massive security group rules can also increase management complexity. For this reason, you are recommended to minimize the rules of each security group.
Adjusting inbound and outbound rules of active security groups can be risky. Therefore, do not update those rules at will unless you know what you are doing. The Alibaba Cloud console provides the security group cloning feature and allows you to configure security group rules. When modifying security groups and rules, you are recommended to clone those security groups for debugging, preventing impact to active applications.
The following describes some practice suggestions on inbound rules of a security group.
1. Do not use the 0.0.0.0/0 inbound rule
Permitting inbound access without any restrictions is a common mistake. Using 0.0.0.0/0 means that all ports are open to external applications. This is a very bad security practice. The best practice is to deny opening all ports to external applications. Security groups should be exclusively accessible to the whitelist. If you need to expose certain services such as the web service, enable common TCP ports such as 80, 8080 and 443 by default. Meanwhile, disable all other ports.
          { "IpProtocol" : "tcp", "FromPort" : "80", "ToPort" : "80", "SourceCidrIp" : "0.0.0.0/0", "Policy": "accept"} ,
          { "IpProtocol" : "tcp", "FromPort" : "8080", "ToPort" : "8080", "SourceCidrIp" : "0.0.0.0/0", "Policy": "accept"} ,
          { "IpProtocol" : "tcp", "FromPort" : "443", "ToPort" : "443", "SourceCidrIp" : "0.0.0.0/0", "Policy": "accept"} ,
2. Disable unneeded inbound rules
If your current inbound rules include 0.0.0.0/0, review the ports and services that must be exposed for your applications. For ports that you do not want them to directly provide services for external applications, add denial rules for them. If you have installed MySQL database services on the server, port 3306 should not be exposed to the internet by default. You can add a denial rule, as shown below. Set the priority value to 100, which is the lowest priority.
           { "IpProtocol" : "tcp", "FromPort" : "3306", "ToPort" : "3306", "SourceCidrIp" : "0.0.0.0/0", "Policy": "drop", Priority: 100} ,
This setting prevents any other ports from accessing port 3306. However, this can block normal service requests as well. For this reason, you can authorize resources of another security group.
3. Authorize another security group for inbound access
Different security groups apply inbound and outbound rules in accordance with the minimum principle. Different application layers should use different security groups with corresponding inbound and outbound rules.
For example, different security groups are configured for common distributed applications. However, directly authorizing IP addresses or CIDR network segments can be very difficult as different security groups cannot intercommunicate on the internet. In this situation, you can authorize all resources of another security group to be directly accessible. For example, sg-web and sg-databse security groups are created respectively for the web and database layers of our applications. In sg-database, you can add the following rule to authorize all resources in the sg-web security group to access port 3306.
           { "IpProtocol" : "tcp", "FromPort" : "3306", "ToPort" : "3306", "SourceGroupId" : "sg-web", "Policy": "accept", Priority: 2} ,
4. Authorize another security group for inbound access
In classic networks, controlling network segments is difficult and you are recommended to use security group IDs to authorize inbound rules. In VPC networks, you can plan IP addresses on your own and use different VSwitch to set different IP domains.
In VPC environments, you can deny any access by default but authorize access for private network segments, namely directly authorizing trusted CIDR network segments.
          { "IpProtocol" : "icmp", "FromPort" : "-1", "ToPort" : "-1", "SourceCidrIp" : "10.0.0.0/24", Priority: 2} ,
          { "IpProtocol" : "tcp", "FromPort" : "0", "ToPort" : "65535", "SourceCidrIp" : "10.0.0.0/24", Priority: 2} ,
          { "IpProtocol" : "udp", "FromPort" : "0", "ToPort" : "65535", "SourceCidrIp" : "10.0.0.0/24", Priority: 2} ,
5. Steps and instructions of changing security group rules
Changing security group rules can interrupt network communication among instances. To prevent required network communication from being impacted, try to permit required instances using the method below and then execute security group policies to narrow down your changes. After narrowing down the changes, check that service applications are running correctly before performing other required changes.
• Before performing those changes, add instances that need to access each other to the same security group. To do this, you can create a new security group and add those instances into this group so that they can access each other over the intranet.
• Then, add the bound security group IDs of peer instances that require intercommunication into the authorization rules of the security group.
• Also, add intranet IP addresses of peer instances that require intercommunication into the authorization rules of the security group.
This document mainly describes some practices of inbound rules. In Part 2 of this document series, you will learn about detailed security rules of the cloud server and how to add the cloud server to or remove it from security groups.