Block RDP and SSH from the internet by removing broad inbound allow rules and limiting those ports to trusted management sources only. Use explicit deny or higher-priority restriction rules where appropriate, then verify that no public source can reach administrative ports. Confirm the change against all subnets and associated network security groups, and check for overlooked public IP exposures.
What changes in an Azure NSG when you want to stop internet RDP and SSH?
In Azure network security groups, the practical control is to stop treating RDP and SSH as broadly reachable management ports. That means removing or overriding any inbound allow rule that lets the internet reach TCP 3389 or 22, and replacing it with a narrower rule that only permits trusted management sources, such as a jump host, VPN range, or administrative subnet.
An NSG is evaluated by priority, so the real question is not only whether a deny exists, but whether it is higher priority than any permissive rule. If a lower-priority deny is added after a broad allow, the allow still wins. The change must be applied wherever traffic can enter: the subnet NSG, the NIC NSG, and any other attached path that could still permit public reachability.
For Azure-specific hardening patterns, the Microsoft Azure Security Guide is the best starting point because it frames NSGs alongside the other controls that typically close off public administrative access. For broader cloud segmentation and exposure reduction, the Cloud Network Security Guide explains how security groups, subnet boundaries, and egress or ingress controls work together.
How do you confirm the internet is actually blocked?
Validation matters because NSG intent and effective reachability are not always the same thing. Confirm the final rule set against every subnet and every network interface that fronts a host, then test from an address outside your trusted management range. If a public IP, load balancer rule, bastion exception, or another attached rule path still exposes the port, the environment is still reachable even if one NSG looks correct.
That verification should be done from the perspective of the source, not just from inside the Azure portal. Review effective security rules, public IP associations, and any alternative ingress path that could bypass the subnet-level control. If you allow administrative access through a managed entry point, document that exception so it is obvious the service is intentionally reachable only through that path.
The Cloud Misconfiguration Guide is useful here because public ports and overlooked exposures are a common failure mode, and the Remote Desktop (RDP) Security Guide gives the same exposure problem a more protocol-specific treatment. For SSH, the SSH Key and SSH Certificate Management Guide is the better companion when access is being narrowed to approved administrators rather than removed entirely.
What is the safe operational pattern for Azure admin access?
The safest pattern is to separate administration from general internet access. Use a controlled source such as a VPN, a dedicated management subnet, or a bastion-style workflow, then allow RDP or SSH only from that source. That gives you a tight source list instead of an open port, and it also makes access review much easier when you need to answer who can administer which systems.
Where Windows and Linux administration coexist, keep the rule logic consistent so one platform is not left more exposed than the other. Avoid temporary broad allow rules that are intended to be removed later, because those are the ones that often survive change windows and become long-lived exposure. If you need a rule exception, make it explicit, time-bound, and easy to locate in your rule inventory.
For operational guardrails, the Azure RBAC and Service Principals Guide helps when the same environment also needs tight control over who can change NSGs, while the CIS Controls Guide supports the broader discipline of reducing unnecessary exposure and managing access pathways consistently.
Risk and Threat Considerations
Leaving RDP or SSH open to the internet creates immediate exposure to scanning, brute-force attempts, password spraying, and opportunistic exploitation of weak or forgotten management access. The danger is not only direct login attempts, but also the possibility that an overlooked public IP, stale rule, or alternate attached path still exposes the service after the intended NSG change.
Failure mechanism: A permissive inbound rule, a lower-priority deny, or an unreviewed secondary ingress path keeps TCP 3389 or 22 reachable from untrusted networks, so attackers can keep probing until they find valid credentials or another weakness.
Impact: Successful exposure can lead to full host takeover, credential theft, lateral movement, and faster privilege escalation because remote administration channels are high-value entry points.
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 | Limits exposed management services and unsafe network rules. |
| Recommendation — Harden network ACL and firewall rules to block public administrative ports. | ||
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | NSG rules enforce whether internet traffic may reach admin ports. |
| IA-2 — Identification and Authentication (Organizational Users) | Remote admin access should require strong authenticated entry, not open internet reachability. | |
| Recommendation — Enforce explicit inbound flow restrictions for RDP and SSH. Require strong authentication for administrative remote access paths. | ||
| ISO/IEC 27001:2022 | A.8.20 — Network security | Network security controls must restrict externally reachable management services. |
| Recommendation — Restrict public network exposure for administrative protocols. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | Administrative access must be restricted to approved identities and sources. |
| Recommendation — Limit admin access paths to approved users and sources only. | ||
Practitioner Guidance
What to verify: Check the effective rules on every subnet and NIC involved, not just the rule you edited. If any public source can still reach the port, treat the change as incomplete.
Common mistake: Adding a deny rule without checking priority, or assuming one NSG change covers all paths. In Azure, effective exposure is the sum of all attached controls, not the intent of a single rule.
Practitioner takeaway: The control objective is to make administrative access intentionally reachable from a small trusted source set, and nowhere else. If you cannot prove that reachability boundary from outside the environment, the port is still effectively exposed.
Related resources from NHI Mgmt Group
- What happens when remediation policies are applied to Azure Network Security Groups with overly broad access?
- How should security teams configure Azure network security groups to reduce accidental exposure?
- How should security teams decide whether JIT access is safe for non-human identities?
- How should organizations prioritize security in their MCP implementations?