How do you stop Azure network security groups from exposing RDP, SSH and HTTP to the internet?

Why NSG exposure happens in Azure

Azure network security groups become dangerous when their inbound rules are written too broadly, especially for administrative ports and publicly reachable web ports. The practical problem is not the NSG itself, but the combination of an allow rule, an internet source scope, and a route to a live service. A single permissive rule can make a workload reachable from anywhere.

The right mental model is to treat each exposed port as a separate trust decision. RDP and SSH are administrative channels that should usually be reachable only from tightly controlled source ranges, private access paths, or management jump points. HTTP is different, because it may be intentionally public, but it still needs explicit review so that only the intended service is open and only from the intended sources.

For Azure-specific hardening patterns, the Microsoft Azure Security Guide is the most direct place to anchor the broader NSG, policy, and private access model. For cloud pattern context beyond Azure, the Cloud Network Security Guide covers how security groups, private routes, and egress controls fit together.

How to close public RDP and SSH without breaking management

Start by locating inbound NSG rules that allow TCP 3389 and 22 from broad internet ranges such as 0.0.0.0/0 or any equivalent wildcard source. Replace those rules with narrow source addresses, management subnets, VPN ranges, bastion paths, or other private access routes. That preserves admin reachability while removing internet-wide exposure.

When the port is meant for administration, avoid treating it like a normal application port. RDP and SSH should be reachable only through a deliberate management path, not through a public rule that happens to be restricted by convention. If the workload must remain reachable during a transition, use a temporary exception with a tight source scope and a clear expiry condition rather than leaving a broad rule in place.

The operational detail matters for SSH in particular: key handling, bastion design, and orphaned access paths are often the real control boundary, not just the NSG itself. The SSH Key and SSH Certificate Management Guide is useful when you are tightening SSH access alongside network rules. For RDP, the Remote Desktop (RDP) Security Guide provides the complementary view on safe remote desktop access, session abuse, and gated exposure.

How to handle HTTP rules and verify the effective exposure

HTTP deserves separate treatment because some services are intentionally public while others should never face the internet. Review every inbound allow rule for port 80 or 443 and confirm that the destination really is a public web service, not an internal admin surface, a forgotten test endpoint, or a management UI. If the service is not meant to be public, move it behind private networking or restrict the source ranges just as you would for RDP and SSH.

Do not stop at the written rule set. Effective exposure depends on the full path, including subnet placement, load balancers, public IPs, and any later rule changes that override your intent. A clean NSG can still be part of an exposed path if another layer reopens the route, so validate the effective rules after deployment and after every change.

If your environment has a habit of drifting back to permissive network posture, the Cloud Misconfiguration Guide is the best companion reference for spotting open ports and policy drift before they become exposure. For the Azure control-plane side, the Microsoft Azure Security Guide also covers the Azure services that commonly sit beside NSG enforcement.

Risk and Threat Considerations

Publicly exposed RDP and SSH are high-value attack surfaces because they invite scanning, brute force, password spraying, and opportunistic exploitation of weak remote access configurations. Broad HTTP exposure is equally risky when the port lands on an admin console, status page, or internal application that was never meant to be reachable from the internet.

Failure mechanism: A permissive inbound rule, combined with a public source scope, makes the service internet-reachable even when the application owner believes access is limited. Attackers then probe the exposed port, pivot through weak credentials or misconfigurations, and use the reachable service as the initial foothold.

Impact: The result can be unauthorized remote access, credential theft, session abuse, lateral movement, or exposure of internal management surfaces. At scale, one overlooked allow rule can create a repeatable path into multiple workloads, which turns a local configuration error into a broad attack surface.

Practitioner Guidance

What to verify: Confirm the source scope on every inbound rule, not just the destination port. A rule that looks narrow in the portal can still be effectively broad if it uses the wrong address range, applies to the wrong subnet, or is shadowed by another allow path.

Decision rule: If the port is administrative, require a private management route or tightly bounded source addresses. If the port is intended to be public, treat it as a service exposure decision and validate that the workload, listener, and upstream controls are all meant to be internet-facing.

Practitioner takeaway: The control objective is not merely to block famous ports, it is to prove that no effective path exposes them beyond the audience that actually needs them.

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 should security teams use Tailscale to connect a Chromebook without exposing the home network to the public internet?
• How should security teams secure RDP access without exposing port 3389 to the internet?