Restrict it by removing inbound rules that allow SSH or RDP from broad internet ranges and replacing them with specific trusted source addresses or private management paths. Keep separate rules for administration and application access, and verify that no default or inherited rule reopens those ports. Recheck security group changes after new instances or templates are deployed.
How internet exposure happens in Alibaba Cloud security groups
In practice, SSH and RDP become internet-exposed when a security group allows inbound traffic from broad source ranges such as 0.0.0.0/0 or other large public CIDRs. The fix is to make the rule source-specific, or to remove public exposure entirely and route admin access through a private management path such as VPN, bastion, or other controlled entry point.
That matters because security groups are stateful allow lists, so a single permissive rule can override the intended “private only” design. A clean rule set separates administrative access from application traffic, which makes it easier to prove that management ports are reachable only from approved sources and not from the general internet.
For cloud network design and rule hygiene, Cloud Network Security Guide is the best starting point, and the broader Cloud Security Guide helps place security groups inside the wider cloud control model.
What to change in the security group rule set
The immediate change is to replace any inbound SSH or RDP rule that trusts the internet with a rule that trusts only the smallest workable source set. For a small admin team, that may be a fixed office egress range or a jump host subnet; for a distributed team, it is usually safer to use a managed remote-access path than to keep widening public allow lists.
Keep the management port rules distinct from application ports so you can review them separately and avoid accidental reuse of the same source scope. This is especially important when templates, copied security groups, or inherited defaults are involved, because a future deployment can reopen the port if the hardened rule was not built into the baseline.
When SSH hardening is part of the answer, the SSH Key and SSH Certificate Management Guide is useful for the access side of the problem, while the Remote Access Identity Guide helps with the decision to move admin access behind stronger entry controls instead of public exposure.
How to keep SSH and RDP closed after deployment
Security group hardening fails most often at the deployment boundary, not the initial edit. New instances, launch templates, auto scaling groups, and copied environments can reintroduce broad rules unless the approved security group is attached everywhere the workload can be created.
So the practical test is not “did I edit the rule once,” but “can a new instance come up with the same restricted inbound posture?” That means checking effective rules after deployment, confirming no default group or inherited association reopens the port, and validating that private management access still works before you remove the broad rule.
The cloud-specific risk is similar to other exposure patterns described in Cloud Misconfiguration Guide, while the Remote Access Identity Guide is the right companion when you decide to retire direct public admin paths.
Risk and Threat Considerations
Public SSH and RDP exposure raises the chance of brute-force attempts, password spraying, scanning, and opportunistic exploitation. Once one of those services is reachable from the internet, the control question is no longer only who should have access, but also how quickly you can detect abuse and whether the service is still needed on a public interface at all.
Failure mechanism: A broad inbound rule, a copied template, or a later deployment drift reopens TCP/22 or TCP/3389 to the internet, bypassing the intended private management path.
Impact: Attackers can attempt direct logon abuse, establish an initial foothold, or use the exposed remote service as a persistent access path if credentials are weak or reused.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud security groups govern who can reach admin ports from where. |
| Recommendation — Restrict management access paths to approved sources and remove broad public ingress. | ||
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Security group rules enforce allowed inbound network flows to SSH and RDP. |
| Recommendation — Enforce inbound flow restrictions so only approved management sources can connect. | ||
| ISO/IEC 27001:2022 | A.8.20 — Network security | Public SSH and RDP exposure is a network security control problem. |
| Recommendation — Apply network security controls to block unnecessary internet-reachable admin ports. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Secure network rule management prevents exposed management services. |
| Recommendation — Review and harden network rules that expose SSH and RDP to the internet. | ||
| NIST CSF 2.0 | PR.AA-05 — Assets are managed commensurate with risk to the organization and the environment. | Network-exposed admin ports must be governed as risk-bearing assets. |
| Recommendation — Manage exposed management endpoints according to their risk and approved access scope. | ||
Practitioner Guidance
What to verify: Confirm the effective inbound source for each management port, not just the named security group rule. In Alibaba Cloud, check the instance attachment, any cloned group, and any template or automation that can recreate the workload with a different network posture.
Decision rule: If SSH or RDP must remain reachable for administration, constrain it to a private path or a tightly bounded trusted source. If that cannot be done cleanly, treat the public exposure as temporary exception handling and document the expiration point.
Practitioner takeaway: The durable fix is not “lock the port once,” it is “make public management access impossible to reintroduce by deployment drift.”
Related resources from NHI Mgmt Group
- How do you block RDP and SSH from the internet in Azure network security groups?
- How should security teams restrict access to cloud audit logs without losing visibility?
- How should security teams restrict new cloud permissions before they expand access to humans and machine identities?
- How should security teams manage file transfer workflows when relying on cloud-based SSH access controls?