Gordon
Assistant Engineer
Assistant Engineer
  • UID622
  • Fans3
  • Follows0
  • Posts52
Reads:1767Replies:0

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

Created#
More Posted time:Mar 27, 2017 16:08 PM
In Part 1 of this document series, you have learned about some practices of security group rules and restrictions. These practices are important as they are required parameters during cloud server creation. This document further describes security groups from the following aspects:
• Authorize and deauthorize security group rules.
• Add to and remove from security groups.
Alibaba Cloud network types are classified as classic networks and VPC networks, which support different security group rules. For classic networks, you can set the following rules: intranet inbound, intranet outbound, internet inbound and internet outbound. For VPC networks, you can set the following rules: intranet inbound and intranet outbound.
First of all, let's take a look at some concepts of intranet communication for security groups:
• By default, only computers in the same security group can access each other. In other words, computers of the same user in different security groups are inaccessible to each other on the intranet. This applies to both classic and VPC networks. Therefore, cloud servers on classic networks are intranet-secure.
• If two cloud service networks in different security groups can access each other over the intranet, but this does not actually meet your expectation, please check intranet rules of those security groups. If intranet protocols include the following protocols, you are recommended to reconfigure those intranet protocols. For classic networks, this can expose your intranet to external applications.
o Permit all ports
o Rules for the authorized object with the CIDR network segment (SourceCidrIp) 0.0.0.0/0 or 10.0.0.0/8
• When resources are created in different security groups, network intercommunication must be implemented by authorizing those security groups. For intranet access, you are recommended to use source security group authorization but not CIDR network segments.
Security rules mainly describe different access permissions with the following properties:
• Policy: Authorization policy accept or drop.
• Priority: Security group priorities are sorted by creation time in descending order. The rule priority ranges from 1 to 100. The default value is 1, which is the highest priority. A greater value indicates a lower priority.
• NicType: In mutual security group authorization (namely SourceGroupId is specified while SourceCidrIp is not), you must specify NicType as intranet.
• For rule description, you must select either security group authorization (for NicType, you must select intranet) or CIDR authorization.
o SourceGroupId: Authorize SourceCidrIp through security groups, by default.
o IpProtocol: tcp | udp | icmp | gre | all
o PortRange: For example, 80/80.
o SourceGroupOwnerAccount is not required, but is used for cross-account authorization.
• CIDR authorization rules:
o SourceCidrIp: CIDR network segments.
o IpProtocol: tcp | udp | icmp | gre | all
o PortRange: For example, 80/80.
o SourceGroupOwnerAccount is not required, but is used for cross-account authorization.
Authorizing an inbound request rule
Creating a security group on the console or by using APIs involves no security rules. In this situation, all inbound requests will be denied by default. Therefore, you have to configure inbound rules accordingly.
If you need to enable port 80 on the internet to provide HTTP services for external applications, do not impose any restrictions on IP network segments but set as 0.0.0.0/0 in order to allow all inbound requests. For this purpose, you can refer to the following properties where console parameters are outside of brackets and OpenAPI parameters are within brackets (no difference would be made if both parameters are the same.)
• Network adapter type (NicType): internet (internet). For the VPC type, simply enter intranet to implement through EIP.
• Authorization policy (Policy): permit (accept)
• Rule direction (NicType): inbound
• Protocol type (IpProtocol): TCP (tcp)
• Port range (PortRange): 80/80
• Authorized object (SourceCidrIp): 0.0.0.0/0
• Priority (Priority): 1
The recommended values above are only for the internet. For intranet requests, you are not recommended to use CIDR network segments, but refer to the following:
Denying an inbound request rule
Denying a rule is simple. To do this, you only need to configure a denial policy set with low priority. In this way, you can configure another rule with a higher priority to overwrite this rule when needed. For example, the following explains how to deny access to port 6379.
• Network adapter type (NicType): intranet (intranet)
• Authorization policy (Policy): deny (drop)
• Rule direction (NicType): inbound
• Protocol type (IpProtocol): TCP (tcp)
• Port range (PortRange): 6379/6379
• Authorized object (SourceCidrIp): 0.0.0.0/0
• Priority (Priority): 100
Do not use CIDR or IP authorization for intranet security group rules of classic networks
For cloud servers on classic networks, no inbound rules for the intranet will be enabled by Alibaba Cloud by default. Always exercise caution for intranet authorization.* For security, you are strongly recommended not to enable any authorization that is based on CIDR network segments.* For elastic computing, intranet IP addresses change frequently and the network segment to which the IP addresses map to varies dynamically. For this reason, you are only recommended to authorize intranet access through security groups on classic networks.
For example, if you are building a Redis cluster in the sg-redis security group and only permit certain computers to access the server group of this Redis cluster such as sg-web, no CIDR configuration is required but simply add an inbound rule to specify relevant security group IDs.
• Network adapter type (NicType): intranet (intranet)
• Authorization policy (Policy): permit (accept)
• Rule direction (NicType): inbound
• Protocol type (IpProtocol): TCP (tcp)
• Port range (PortRange): 6379/6379
• Authorized object (SourceGroupId): sg-web
• Priority (Priority): 1
For VPC networks, if you have planned an IP range through multiple VSwitch, you can set it with CIDR. However, if the VPC network segment is ambiguous, you are also recommended to prioritize security groups as inbound rules.
Adding cloud servers requiring intercommunication into the same security group
As mentioned in Part 1 of this document series, a single cloud server can join up to 5 security groups. Also, cloud servers in the same security group can intercommunicate over the intranet. If you have created multiple security groups during planning and directly setting multiple security rules is too complicated, you can select the computers that require intranet communication and add them to the same security group.
Different security groups have different network types. For a classic type of cloud server, it can only join a security group of the classic network type; for a VPC type of cloud server, it can only join a security group of the VPC network type.
Additionally, you are not recommended to add all cloud servers to the same security group as this would make the configuration of security group rules quite messy. For a mid- or large-size application, each server group has different roles and it is important to plan inbound and outbound requests in a rational manner.
Joining a security group is very simple. To do this, you can select a cloud server on the console, click "More" and select a security group to manage. Also, you can select "Instance details" and enter the instance security group to view and perform other operations.
If you are familiar with Alibaba Cloud OpenAPIs, you can also perform batch operations using OpenAPIs. The corresponding Python fragment is as follows:
def join_sg(sg_id, instance_id):
    request = JoinSecurityGroupRequest()
    request.set_InstanceId(instance_id)
    request.set_SecurityGroupId(sg_id)
    response = _send_request(request)
    return response

# send open api request
def _send_request(request):
    request.set_accept_format('json')
    try:
        response_str = clt.do_action(request)
        logging.info(response_str)
        response_detail = json.loads(response_str)
        return response_detail
    except Exception as e:
        logging.error(e)


Removing cloud servers from security groups
Adding cloud servers to inappropriate security groups can result in exposure or block your services. If this is the case, you can select and remove those servers from security groups. Given that each cloud server must belong to a security group, another security group is required in this case.
Joining a security group is very simple. To do this, you can select a cloud server on the console, click "More" and select a security group to manage. Also, you can select "Instance details" and enter the instance security group to view and perform other operations.
You are recommended to perform sufficient tests as removing a cloud server from a security group may cause the server and the intranet of the current security group to be inaccessible.
The corresponding Python fragment is as follows:
def leave_sg(sg_id, instance_id):
    request = LeaveSecurityGroupRequest()
    request.set_InstanceId(instance_id)
    request.set_SecurityGroupId(sg_id)
    response = _send_request(request)
    return response

# send open api request
def _send_request(request):
    request.set_accept_format('json')
    try:
        response_str = clt.do_action(request)
        logging.info(response_str)
        response_detail = json.loads(response_str)
        return response_detail
    except Exception as e:
        logging.error(e)


Defining reasonable names and tags for security groups
Defining reasonable and meaningful names and descriptions for security groups can effectively help you quickly identify the meanings of current complicated rule combinations. For this reason, you can change security group names and descriptions as needed. Also, you can set tags for security groups. You can manage your own security groups by grouping them with tags. To set tags, you can directly configure them in the console or by using APIs.
Deleting undesired security groups
As mentioned before, security rules of security groups are like whitelist and blacklist items. For undesired security groups, you are recommended to delete them to prevent unexpected problems caused by adding cloud servers to those groups by mistake.
Guest