Security Group and Security Group Rule Overview

What Is a Security Group?

A security group is a collection of access control rules for cloud resources, such as cloud servers, containers, and databases, that have the same security protection requirements and that are mutually trusted. After a security group is created, you can configure access rules that will apply to all cloud resources added to this security group.

When creating an instance (for example, an ECS), you must associate it with a security group. If there are no security groups yet, a default security group will be automatically created and associated with the instance. For details, see Default Security Groups. You can also create a security group based on service requirements and associate it with the instance. A cloud resource can be associated with multiple security groups, and traffic to and from the cloud resource is matched by priority in a descending order.

Each security group can have both inbound and outbound rules. You need to specify the source, port, and protocol for each inbound rule and specify the destination, port, and protocol for each outbound rule to control the inbound and outbound traffic to and from the instances in the security group. As shown in Figure 1, you have a VPC (VPC-A) with a subnet (Subnet-A) in region A. An ECS (ECS-A) is running in Subnet-A and associated with security group Sg-A.

• Security group Sg-A has a custom inbound rule to allow ICMP traffic to ECS-A from your PC over all ports. However, the security group does not have rules that allow SSH traffic to ECS-A so you cannot remotely log in to ECS-A from your PC.
• If ECS-A needs to access the Internet through an EIP, the outbound rule of Sg-A must allow all traffic from ECS-A to the Internet.

Figure 1 A security group architecture

Security groups are free of charge.

What Are Security Group Rules?

• A security group has inbound and outbound rules to control traffic that is allowed to reach or leave the instances associated with the security group.
  • Inbound rules: control traffic to the instances in a security group.
  • Outbound rules: control traffic from the instances in a security group to access external networks.
• You can specify protocol, port, source or destination for a security group rule. The following describes key information about a security group rule.
  • Action: Allow or Deny. If the protocol, port, source or destination of the traffic matches a security group rule, traffic will be allowed or denied.
  • Priority: The value ranges from 1 to 100. A smaller value indicates a higher priority. Security group rules are matched first by priority and then by action. Deny rules take precedence over allow rules. For more information, see How Traffic Matches Security Group Rules.
  • Type: IPv4 or IPv6.
  • Protocol & Port: network protocol type and port range.
    • Protocol: the protocol that is used to match traffic. The protocol can be TCP, UDP, ICMP, or GRE.
      • TCP is ideal for applications that require reliable connections and high data integrity, such as remote login, web browsing, email, and file transfers.
      • UDP is ideal for applications demanding high speed and low latency, such as online gaming and video meetings.
      • ICMP is used to communicate data transmission problems. For example, the ping command can be used to check the connectivity between network devices, error reports can be generated for O&M, and diagnosis information can be transmitted for network analysis and optimization.
      • GRE is widely used and enables communications between networks using different protocols by encapsulating one protocol within another, for example, encapsulating IP packets.
    • Port: the destination port range that is used to match traffic. The value ranges from 1 to 65535.
  • Source or Destination: source address of traffic in the inbound direction or destination address of traffic in the outbound direction.
    The source or destination can be an IP address, security group, or IP address group.

    • IP address: a fixed IP address or CIDR block. Both IPv4 and IPv6 addresses are supported, for example, 192.168.10.10/32 (IPv4 address), 192.168.1.0/24 (IPv4 CIDR), or 2407:c080:802:469::/64 (IPv6 CIDR).
    • Security group: If the selected security group and the current security group are in the same region, the traffic is allowed or denied to the private IP addresses of all instances in the selected security group. For example, if there is instance A in security group A and instance B in security group B, and the inbound rule of security group A allows traffic from security group B, traffic is allowed from instance B to instance A.
    • IP address group: If you have multiple IP addresses with the same security requirements, you can add them to an IP address group and select this IP address group when you configure a rule, to help you manage them in an easier way.

How Security Groups Work

• Security groups are stateful. If you send a request from your instance and the outbound traffic is allowed, the response traffic for that request is allowed to flow in regardless of how inbound security group rules are defined. Similarly, if inbound traffic is allowed, responses to allowed inbound traffic are allowed to flow out, regardless of how outbound rules are defined.
• Security groups use connection tracking to track traffic to and from instances. Changes to inbound rules take effect immediately for existing connections. Changes to outbound security group rules do not affect existing persistent connections and take effect only for new connections.
  If you add, delete, or update rules in a security group, or add or remove instances in a security group, the details are as follows:

  • For connections established by inbound traffic, the system automatically clears the connection tracking entries corresponding to the existing persistent connections based on Table 1. That is, the connection tracking entries are expired in advance. Then, the system re-establishes connections to match the new inbound rules of the security group.
    • If the security group rules allow the traffic of the connections, the connections can be established and network communication is not affected.
    • If the security group rules deny the traffic of the connections, the connections cannot be established again and the network communication will be interrupted.

    Table 1 Scenarios and policies for clearing connection tracking entries

    Scenario	Clearing Policy
    Adding instances to security group A	Clear inbound connection tracking entries of the instances newly added to security group A. If an inbound rule of another security group (for example, security group B) denies access from security group A, clear inbound connection tracking entries of all instances in security group B.
    Removing instances from security group A	Clear inbound connection tracking entries of all instances in security group A. If an inbound rule of another security group (for example, security group B) allows access from security group A, clear inbound connection tracking entries of all instances in security group B.
    Adding rules to security group A	If a Deny rule is added in the inbound or outbound direction, clear inbound connection tracking entries of all instances in security group A.
    Deleting rules from security group A	If an Allow rule is deleted in the inbound direction, clear inbound connection tracking entries of all instances in security group A.
    Modifying rules in security group A	If the priority, action, protocol, port, or source address of a rule is modified in the inbound direction, clear inbound connection tracking entries of all instances in security group A.
    Changing IP address entries in an IP address group	If an IP address group is associated with an inbound rule in security group A, deleting or adding an IP address entry from or to the IP address group will clear inbound connection tracking entries of all instances in security group A.

  • The existing outbound persistent connections will not be disconnected, and the original rule will still be applied. All the new connections will match the new rules.

After a persistent connection is disconnected, new connections will not be established immediately until the timeout period of connection tracking expires. For example, after an ICMP persistent connection is disconnected, a new connection will be established and a new rule will be applied when the timeout period (30s) expires.

• The timeout period of connection tracking varies by protocol. The timeout period of a TCP connection in the established state is 600s, and that of an ICMP connection is 30s. For other protocols, if packets are received in both inbound and outbound directions, the connection tracking timeout period is 180s. If packets are received only in one direction, the connection tracking timeout period is 30s.
• The timeout period of TCP connections varies by connection status. The timeout period of a TCP connection in the established state is 600s, and that of a TCP connection in the FIN-WAIT state is 30s.

• Security group rules work like a whitelist. If there are no rules that allow or deny some traffic, the security group denies such traffic to or from the instances in the security group.
  • Inbound rules: If the source of a request matches the source specified in a rule with Action set to Allow, the request is allowed. For this reason, you do not need to configure a deny rule in the inbound direction.

    The rules in Table 2 ensure that instances in a security group can communicate with each other. Do not delete or modify these rules.

  • Outbound rules: The rules in Table 2 allow all traffic to leave the instances in the security group so that the instances can access any external IP address. If you delete these rules, the instances in the security group cannot access external networks.

    Table 2 Security group rules

    Direction	Action	Type	Protocol & Port	Source/Destination
    Inbound	Allow	IPv4	All	Source: current security group
    Inbound	Allow	IPv6	All	Source: current security group
    Outbound	Allow	IPv4	All	Destination: 0.0.0.0/0
    Outbound	Allow	IPv6	All	Destination: ::/0

How Traffic Matches Security Group Rules

An instance can have multiple security groups associated, and a security group can contain multiple security group rules. Security group rules are matched first by priority and then by action. Deny rules take precedence over allow rules. The following takes inbound traffic as an example to match security group rules:

1. First, traffic is matched based on the sequence number of security groups. You can adjust the security group sequence. A smaller security group sequence number indicates a higher priority.

   If the sequence number of security group A is 1 and that of security group B is 2, the priority of security group A is higher than that of security group B. Traffic preferentially matches the inbound rules of security group A.

2. Second, traffic is matched based on the priorities and actions of security group rules.
   1. Security group rules are matched by priority first. A smaller value indicates a higher priority.

      If the priority of security group rule A is 1 and that of security group rule B is 2, the priority of security group rule A is higher than that of security group rule B. Therefore, traffic preferentially matches security group rule A.

   2. Deny rules take precedence over allow rules of the same priority.
3. Traffic matches all inbound rules of a security group based on the protocol, ports and source.
   • If the traffic matches a rule:
     • With Action of Allow, the traffic is allowed to access the instances in the security group.
     • With Action of Deny, the traffic is denied to access the instances in the security group.
   • If the traffic does not match any rule, the traffic is denied to access the instances in the security group.

Figure 2 Security group matching sequence

Security Group Examples

You can allow given IP addresses to access instances in a security group, or allow access from another security group to enable instances in different security groups to communicate with each other. You can add security group rules to flexibly control the traffic in and out of a network to ensure network security. The following provides some examples on how security groups can be used.

Security Group Configuration Process

Figure 6 Process of using a security group

Constraints on Using Security Groups

• For better network performance, you are advised to associate an instance with no more than five security groups.
• A security group can have no more than 6,000 instances associated, or its performance will deteriorate.
• For inbound security group rules, the sum of the rules with Source set to Security group, of the rules with Source set to IP address group, and of the rules with inconsecutive ports, cannot exceed 120. If there are both IPv4 and IPv6 security group rules, up to 120 rules can be added for each type.

  The limits on outbound security group rules are the same as those on inbound rules.

  For example, to add inbound IPv4 rules to a security group (Sg-A), you can refer to Table 4 for rules that meet the restrictions. Of these rules, rule A02 uses inconsecutive ports (TCP: 22,25,27) and security group Sg-B as the source. In this case, only one quota is occupied.

  Table 4 Inbound security group rules

  Rule No.	Action	Type	Protocol & Port	Source
  Rule A01	Allow	IPv4	All	Current security group: Sg-A
  Rule A02	Allow	IPv4	TCP: 22,25,27	Another security group: Sg-B
  Rule A03	Allow	IPv4	TCP: 80-82	IP address group: ipGroup-A
  Rule A04	Allow	IPv4	TCP: 22-24,25	IP address: 192.168.0.0/16

• Traffic from load balancers is not restricted by network ACL and security group rules if:

  Transfer Client IP Address is enabled for the listeners of a load balancer.

  The load balancer can still forward traffic to backend servers, even if there is a rule that denies traffic from the load balancer to the backend servers.

Security Group Application Guidance

Proper security group rule configuration is vital for cloud service protection. The following provides practical guidance for building a secure and reliable network.

1. Analyzing Service Requirements and Planning Security Groups

   Analyze the service architecture to identify public and internal services, and then define tailored security group rules based on their specific requirements.

   • Use different security groups to isolate public and private cloud servers.

     Associate public and private cloud servers with different security groups for network isolation. The security group rules must follow the principal of least privileged access. By default, all ports and protocols are disabled. Only those required for services are explicitly enabled.

     If you have web servers that are accessible from the Internet, associate these servers with the same security group that only allows traffic over specific ports (such as ports 80 and 443) and denies all other external access requests by default. Do not run internal services, such as MySQL and Redis databases, on web servers that can be accessed from the Internet. Instead, deploy them on ECSs that cannot be accessed from the Internet, associate these ECSs with a dedicated security group, and use security group rules to authorize instances in other security groups to access the databases, minimizing the risk of exposing the internal services to the Internet.

   • Associate cloud servers running different OSs or applications with different security groups.

     Associate cloud servers running different OSs or applications with different security groups for refined access control. For example, open port 22 (SSH) for Linux cloud servers for remote management and port 3389 (RDP) for Windows cloud servers. Even cloud servers with identical system images should be associated with different security groups if they run different applications. This allows stronger isolation and flexible management.

   • Associate cloud servers in different environments with different security groups.

     To ensure stability and security, associate cloud servers in the production and test environments with different security groups. Use the access control function of security groups to isolate networks between different environments and prevent test changes from affecting the production environment. Additionally, associate different security groups with cloud servers in different test environments (such as development and integration) to avoid cross-environment interference and enhance efficiency.

   • Control public network access and avoid assigning EIPs to cloud servers that do not require it.

     Huawei Cloud provides multiple secure and reliable public network access solutions. Do not assign EIPs to cloud servers unless necessary.

     • If you only need to log in to an ECS, use secure channels such as CBH, CloudShell, or VNC.
     • If your services running on multiple cloud servers need to be accessed from the Internet, use ELB to distribute public traffic. ELB prevents single points of failure, improves service availability, and reduces security risks.
     • If your cloud servers need to access the Internet, use a NAT gateway. A NAT gateway enables cloud servers without EIPs in a VPC to access the Internet by configuring SNAT rules, enabling multiple cloud servers to share an EIP for Internet access.
2. Configuring Security Group Rules
   • Default security group

     If no security group is created, the system automatically generates a default one upon first use. The default security group only allows instances in the security group to communicate with each other but denies all external requests by default. For details, see Default Security Groups.

   • Internal network isolation for different security groups by default

     Cloud servers under the same account are isolated by default if they are associated with different security groups.

   • Whitelist principle for security group rules

     Security group rules follow the whitelist principle, which is the basis of a secure system. Instances in a security group deny all external access requests by default, but you can add rules to allow specific requests. You should open only the minimum set of ports required for services.

   • Least privilege principle for security group rules

     When adding a security group rule, grant the minimum permissions possible. For example, only allow specific IP addresses to log in to a cloud server over port SSH (22) or RDP (3389). Do not use 0.0.0.0/0 (all IP addresses).

   • Using IP address groups to reduce the number of security group rules

     If you have multiple IP addresses with the same security requirements, you can add them to an IP address group and select this IP address group when you configure a rule. If an IP address changes, updating it in the group automatically applies the change to all associated rules. This improves efficiency. For details, see Using IP Address Groups to Reduce the Number of Security Group Rules.

   • Typical service ports

     Applications use standard communication ports. You need to allow the corresponding ports in the security group based on your service requirements. For details, see Common ECS Ports.

3. Maintaining Security Groups and Rules

   As services evolve, existing security groups and rules may become outdated. You are advised to periodically review your architecture and update security groups to align with current requirements. To avoid disrupting live services, avoid modifying active rules directly. Instead, clone the security group, validate network functionality with the cloned group, and then apply necessary changes. This approach minimizes service impact. For details, see Cloning a Security Group.