When Hong Kong cloud servers first became available, many people's first priority was setting up the environment and deploying their websites. However, what truly determines whether a server can be securely accessed is the security group. A security group acts like a virtual firewall, controlling which traffic can enter and which must be blocked. If the rules are configured too loosely, the server is vulnerable to scanning and attacks; if they are configured too strictly, it may lock the server out. Finding a balance between usability and security hinges on understanding the uses of common ports and adhering to the principle of least privilege.

　　Security groups are essentially a set of rules based on "inbound" and "outbound" traffic. Inbound traffic controls external access to your server, while outbound traffic controls the server's access to the outside world. In most scenarios, the risk primarily comes from the inbound traffic, hence the focus. Rules typically consist of the protocol (TCP/UDP), port range, source IP (CIDR), and policy (allow/deny).

　　Many beginners immediately open "0.0.0.0/0 + allow all ports," which is indeed the easiest approach, but it essentially exposes the server completely to the public internet. Internet scanners operate 24/7, scanning your server every few minutes, resulting in a flurry of weak password attempts and vulnerability probes. This is why many people see numerous unusual accesses in their logs even when they haven't done anything wrong.

　　A more reasonable approach is to first determine "what services your server needs to provide externally," and then decide which ports to open. For example, a typical web server usually only needs to open ports 80 (HTTP) and 443 (HTTPS). These two ports are used for user access to web pages and must be open to the public internet; therefore, the source IP address is typically 0.0.0.0/0.

　　The SSH login port (default 22) is different. It's the management portal and should not be open to the entire world. A safer approach is to restrict the source IP address, such as allowing only your own office network or home broadband IP:

　　Protocol: TCP

　　Port: 22

　　Source: Your public IP/32

　　Policy: Allow

　　If your IP address is not fixed, consider two methods: First, use a bastion host, only allowing access to the bastion host's IP address; second, temporarily allow access, then close it after login. An advanced approach is to directly change the SSH port, for example, to 2222, and combine this with security group restrictions, which can significantly reduce scanning interference.

　　Database ports are another common pitfall. For example, MySQL uses 3306 by default, and Redis uses 6379. These services should not be directly exposed to the public internet. If you only allow your website program to access the database locally, then there is absolutely no need to open these ports in the security group. Many security incidents are caused by exposing database ports to the public internet without setting strong passwords or access restrictions.

　　If remote database connections are indeed necessary, the source IP should be restricted, rather than being completely open:

　　Protocol: TCP

　　Port: 3306

　　Source: Specified IP/32

　　Policy: Allow

　　The same principle applies to services like Redis and MongoDB.

　　For some special applications, such as remote desktop (Windows 3389), FTP (21), and email services (25, 465, 587), access should be granted only as needed, rather than being fully open by default. Ports 3389 and 22, in particular, are among the most frequently scanned ports; once exposed and with weak passwords, they are easily brute-forced.

　　Let's discuss outbound rules. Many cloud platforms default to "all allowed," which is fine in most cases because servers need to access external resources, such as downloading software packages, accessing APIs, and uploading backups. However, if you have higher security requirements, you can tighten the restrictions appropriately, such as allowing access only to specific ports (80/443) to prevent malicious connections from being initiated after a server intrusion. However, this type of configuration requires higher operational experience; otherwise, it may affect normal business operations. Several common misconceptions should be noted during actual configuration. First is the rule order. While most Hong Kong cloud server security groups are "matched by rule," some platforms have a priority concept, so it's crucial to confirm whether the configuration will be overridden by preceding rules. Second is forgetting IPv6. If your server has IPv6 enabled, but the security group only restricts IPv4, IPv6 could become a bypass entry point. Third is the issue of overlapping security groups and system firewalls. For example, using security groups and iptables/firewalld simultaneously can lead to access anomalies if rules conflict.

　　From an operations and maintenance perspective, security groups are not just about "opening ports," but also an access control policy. A relatively sound basic configuration approach is as follows: only open ports 80 and 443 to the public network; allow SSH only from specific IPs; completely disable public access to database and cache ports; open other ports as needed, and restrict the source as much as possible. This ensures normal business operation while minimizing the attack surface.

　　If your business becomes increasingly complex, such as with a microservice architecture or multiple interconnected servers, you can use security groups for internal network isolation. For example, only allow application servers to access port 3306 of the database server, instead of opening it to the entire public network. This "only allow necessary communication" approach is essentially the embodiment of the principle of least privilege at the network layer.

　　The core idea of ​​the principle of least privilege is simple: only grant the "necessary permissions," nothing more. Applied to security groups, this means only opening necessary ports, allowing only necessary sources, and retaining rules only for necessary durations. For example, a port might be closed after temporary debugging; an IP address no longer in use should be removed from the rules. In the long run, this practice can significantly reduce security risks.

　　Additionally, it is recommended to regularly check security group rules. Many people add many "temporary rules" initially for convenience, but then forget to clean them up, leading to a chaotic and even incomprehensible set of rules. Regularly review these rules, deleting unused ports and IPs to keep them concise and clear.

　　Logs and monitoring are also crucial. By reviewing access logs, you can detect abnormal scanning or attack behavior. If you find certain IPs continuously accessing the site maliciously, you can directly block them in the security group. With the help of automation tools, dynamic blocking can also be achieved, improving protection efficiency.

　　In general, there is no "universal template" for configuring security groups on Hong Kong cloud servers, but there are clear principles: clearly define business needs, minimize the exposure surface, restrict access sources, and dynamically adjust policies. As long as these principles are followed, even simple configurations can achieve good protection.