Restrict security group rules so SSH and RDP are only reachable from approved source addresses or jump hosts, not from 0.0.0.0/0 or equivalent broad ranges. Review both inbound rules and any automation that recreates them. Alert on new public ingress, especially on management ports, and remove exposed rules quickly.
Why OpenStack security group rules should never expose SSH and RDP publicly
OpenStack security groups are stateful network filters, so a rule that allows SSH or RDP from 0.0.0.0/0 is not just “reachable for convenience”, it is an open management path. The control objective is to keep those ports private to trusted source ranges, bastions, or administration networks, and to treat any public ingress on them as a misconfiguration that should be removed quickly.
That matters because SSH and RDP are high-value entry points. If they are internet-facing, they become exposed to password guessing, key theft fallout, credential stuffing, and brute-force scanning at scale. A rule that is technically correct in the cloud console can still be operationally unsafe if it bypasses the intended trust boundary for administrative access.
In practice, the first check is whether the rule is truly needed at all. Many environments can route administration through a jump host, VPN, private connectivity, or a tightly scoped office range instead of direct exposure. If direct access is unavoidable, the source range should be explicit, narrow, and reviewed as a privileged exception rather than a default pattern. NHIMG’s Cloud Network Security Guide is a useful reference for the surrounding network design choices that keep security groups from becoming the only control.
How to remove the exposure without breaking access
The practical fix is to replace broad ingress with source-based allowlisting and then verify that the allowed path is still operational. For SSH, that usually means a bastion or jump host rather than direct host exposure; for RDP, it usually means an RD Gateway, VPN, or another brokered path rather than a public listener. If automation or infrastructure-as-code recreates the rule, the change must be made at the source of truth, not only in the live instance.
Review both inbound and outbound policy where administration paths depend on callbacks, tunneling, or management tooling. A security group may be closed on paper but still permit adjacent exposure through a permissive rule in another tier or through a newly provisioned instance that inherits the wrong template. Reuse of a known-good baseline is safer than hand-editing one server at a time.
NHIMG’s Cloud Misconfiguration Guide is a good companion here because open management ports are a classic drift pattern, and the fix usually belongs in guardrails and policy as much as in the instance itself. If your environment is AWS- or Azure-heavy, the platform-specific guidance in the AWS Security Guide and the Microsoft Azure Security Guide can help you map the same control idea onto native security group or NSG workflows.
What to watch for after the rule is fixed
Once the public ingress rule is removed, the next question is whether it was present long enough to be abused. Check logs, authentication history, and any host telemetry for scans, failed logons, successful logons from unfamiliar source networks, new keys, new local accounts, or unusual remote sessions around the exposure window. A management port exposed to the internet does not prove compromise, but it does raise the value of quick validation.
Alerting is important because this problem often returns through automation, not manual error. A template, stack update, or provisioning pipeline can silently reintroduce 0.0.0.0/0 on SSH or RDP unless you monitor for newly created public ingress and treat it as a high-priority drift event. NHIMG’s Remote Desktop (RDP) Security Guide is useful when the exposed service is RDP specifically, while the SSH Key and SSH Certificate Management Guide helps when the exposure may have affected privileged shell access.
Risk and Threat Considerations
Public SSH and RDP rules create a direct attack surface for automated scanning, brute-force attempts, and credential abuse. The main risk is not just that an attacker can see the port, but that the port becomes a repeatable path into administrative access if credentials, keys, or session controls are weak.
Failure mechanism: A broad source range turns a privileged management service into an internet-reachable authentication target, then automation or copied infrastructure reintroduces the same mistake elsewhere.
Impact: The exposed host can face account compromise, unauthorized remote sessions, lateral movement, and broader cloud or tenant access if the management path is tied to high-privilege credentials.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Open SSH/RDP rules are insecure cloud/network configuration drift. |
| Recommendation — Harden and continuously audit security group baselines to prevent public management-port exposure. | ||
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Security groups enforce network flows to management ports and should restrict public ingress. |
| IA-2 — Identification and Authentication (Organizational Users) | SSH and RDP exposure increases the importance of strong interactive admin authentication. | |
| Recommendation — Enforce approved source restrictions for SSH and RDP ingress paths. Require strong authentication for all administrative remote access sessions. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | The issue is limiting who can reach privileged remote-access services. |
| Recommendation — Restrict administrative access to approved sources and authenticated operators only. | ||
| ISO/IEC 27001:2022 | A.8.20 — Network security | The question is about preventing insecure network exposure of management services. |
| Recommendation — Implement network controls that block public exposure of SSH and RDP by default. | ||
Practitioner Guidance
What to prioritise: Treat SSH and RDP exposure as a control failure, not a tuning issue. The first priority is to remove public ingress, then confirm that the approved replacement path, such as a bastion, VPN, or gateway, still supports legitimate administration.
What to verify: Verify the effective rule set, not just the intended design. In OpenStack, that means checking whether the rule exists in the active security group, whether another security group attached to the port reopens the path, and whether automation or templates will recreate the exposure on the next deployment.
Decision rule: If the service is a management port and the source range is broader than a clearly approved admin network, treat it as an exception that must be justified, time-bounded, and monitored. If you cannot justify it that way, close it.
Practitioner takeaway: The safe pattern is brokered administration with narrow, explicit source paths. If SSH or RDP needs the internet to work, the real problem is usually the access architecture, not the security group rule alone.
Related resources from NHI Mgmt Group
- How do you block RDP and SSH from the internet in Azure network security groups?
- How do you restrict SSH and RDP access from the internet in Alibaba Cloud security groups?
- How do you prevent AWS security groups from allowing unrestricted inbound access from 0.0.0.0/0?
- How do you restrict internet access to database and admin ports in AWS security groups?