Remote Management Ports: Why RDP, SSH, and VNC Need More Than a Firewall Rule

The most dangerous ports on your firewall

Every organisation has them. SSH on port 22. RDP on port 3389. VNC on 5900. WinRM on 5985 and 5986. These are the ports that let administrators, developers, and support staff reach into servers and workstations remotely. They are also the ports that attackers scan for first, probe hardest, and exploit most reliably.

A quick search on Shodan reveals over 4.5 million devices with RDP exposed directly to the internet. More than 20 million SSH services are reachable from anywhere. Each one of those exposed services is a target, and the scanning is relentless. Automated botnets cycle through common credentials 24 hours a day, testing every exposed management port they can find. If your organisation has even one of these ports open to a broad network range, you are almost certainly seeing brute-force attempts in your logs right now.

The problem is not that these protocols exist. They are essential tools for managing infrastructure. The problem is how they get exposed, and how little scrutiny that exposure receives compared to the risk it carries.

The "just open RDP" request

Here is a scenario that plays out in organisations every week. A support engineer needs to troubleshoot a Windows server. They submit a firewall request: open TCP 3389 from the office subnet to the server. It sounds reasonable. The source is internal. The destination is a single host. The port is specific. The business justification makes sense.

The request gets approved. The rule goes in. The support engineer fixes their issue in 20 minutes and moves on. The rule stays forever.

Six months later, that office subnet has grown. New employees, contractors, visitor Wi-Fi segments that got merged during a network refresh. The rule that was meant for one engineer on one afternoon now allows 400 hosts to reach that server over RDP. Nobody remembers why the rule exists. Nobody reviews it. The server is running an unpatched version of Windows because it hosts a legacy application that breaks when you update it.

This is not a hypothetical. This is the story behind a significant proportion of ransomware incidents. According to multiple incident response reports, RDP is consistently the number one initial access vector for ransomware groups. Not phishing. Not zero-day exploits. RDP. Attackers find exposed or broadly accessible RDP, brute-force or buy stolen credentials, log in, and deploy ransomware. The entire attack chain starts with a firewall rule that seemed harmless at the time.

Why each protocol carries its own risk

Not all remote management protocols are equally dangerous, but none of them are safe to expose broadly. Each has specific weaknesses that make casual firewall rules risky.

RDP (TCP 3389) is the most exploited remote management protocol in enterprise environments. It has a history of critical vulnerabilities, including BlueKeep (CVE-2019-0708) which allowed unauthenticated remote code execution. Even when fully patched, RDP is vulnerable to credential brute-forcing, pass-the-hash attacks, and session hijacking. Without Network Level Authentication enabled, the server presents its login screen to any host that connects, giving attackers a target to throw credentials at indefinitely.

VNC (TCP 5900+) is worse in some respects. Many VNC implementations have no authentication at all by default. Others use a single shared password with no username, no account lockout, and no multi-factor support. Critically, VNC traffic is unencrypted by default. Anyone on the network path between the client and the server can observe the entire session, including everything displayed on screen and every keystroke typed. Exposing VNC broadly is roughly equivalent to projecting your server's desktop onto a public billboard and handing out the remote control.

WinRM (TCP 5985/5986) enables PowerShell remoting on Windows systems. Port 5985 is the HTTP listener and port 5986 is the HTTPS listener. The distinction matters enormously. WinRM over HTTP on port 5985 sends PowerShell commands and their output in cleartext across the network. If an attacker has any foothold on a network segment where WinRM HTTP traffic flows, they can capture administrative commands, credentials, and configuration data without breaking any encryption at all. Even WinRM over HTTPS on 5986 requires careful certificate management to be genuinely secure.

SSH (TCP 22) is the most secure of the group by default. It encrypts all traffic, supports key-based authentication, and has a mature security track record. But SSH still carries risks when exposed broadly. Brute-force attacks against SSH are constant and automated. More importantly, SSH supports tunnelling and port forwarding, which means a compromised SSH session can become a gateway to reach other internal services that are not directly exposed. An attacker who gains SSH access to one host can potentially tunnel through it to reach databases, internal web applications, and other systems that the firewall was supposed to protect.

What compliance frameworks actually say

If your organisation follows PCI DSS, CIS Controls, or NIST guidelines, exposing remote management ports broadly is not just risky. It likely violates your compliance requirements.

PCI DSS is particularly explicit. netbobr flags RDP from the internet as a critical finding under rule PCI-NET-051 because PCI DSS requires that remote access to the cardholder data environment uses multi-factor authentication and encrypted tunnels. An open RDP rule from the internet satisfies neither requirement. Similarly, PCI-NET-060 flags any remote management protocol accessible from the internet, and PCI-NET-061 specifically targets VNC exposure due to its weak authentication and lack of encryption.

CIS Controls take a broader view. Rule CIS-NET-040 flags administrative protocols accessible from non-administrative network segments. The principle is straightforward: management traffic should only originate from designated management networks, not from general-purpose user subnets. Rule CIS-NET-042 flags remote access that bypasses VPN controls entirely, which catches the common pattern of opening SSH or RDP directly to a server without requiring users to connect to the VPN first.

These are not obscure edge cases. They represent the consensus view of what minimum security looks like for remote management access. If your firewall ruleset would trigger these findings, you have rules that need attention.

Direct access versus jump host architecture

The difference between a risky remote management setup and a secure one often comes down to architecture. Consider two approaches to the same problem: an administrator needs to manage a database server.

In the direct access model, the firewall rule allows a broad source range to reach the server on a management port. Every host in that range is a potential attack origin. If any one of those machines is compromised, the attacker has a direct line to the management interface.

In the jump host model, the management port is only accessible from a single, hardened bastion host. Users must first authenticate to the jump host through a VPN with multi-factor authentication. The jump host logs every session. The firewall rule on the database server allows RDP only from the jump host's specific IP address. The attack surface shrinks from hundreds of potential sources to exactly one, and that one is purpose-built to be monitored and defended.

Building a defensible remote access architecture

Moving from broadly exposed management ports to a controlled architecture does not happen overnight, but the path is well-established. Here are the layers that matter most.

Jump hosts and bastion hosts. Every remote management connection should pass through a dedicated jump host. This host sits in its own network segment, runs minimal services, and logs everything. It becomes the single point of control for all administrative access. When you need to audit who accessed what server and when, you have one place to look instead of correlating logs across dozens of endpoints.

VPN-only access. Management ports should never be reachable without first connecting to a VPN. This applies to internal access as well, not just external. If your office Wi-Fi subnet can reach RDP on your domain controllers, you are one compromised laptop away from a domain compromise. VPN access adds an authentication gate before the management protocol's own authentication, creating defence in depth.

Multi-factor authentication. Every remote management session should require MFA, ideally at the VPN level and again at the jump host level. Stolen credentials are cheap and plentiful. MFA is the single most effective control against credential-based attacks on management ports. For RDP specifically, Network Level Authentication should be mandatory, as it requires the user to authenticate before the server creates a full session, reducing the attack surface for unauthenticated exploits.

Just-in-time access. Rather than maintaining permanent firewall rules for management ports, implement just-in-time (JIT) access where the rule is only active during a defined window. An administrator requests access, the system verifies their identity and approval, opens the port for a set duration (say, 4 hours), and automatically closes it afterwards. The management port is reachable for 4 hours instead of 8,760 hours per year. That is a 99.95% reduction in exposure time.

Session recording and monitoring. For high-value systems, record management sessions entirely. If an administrator connects to a production database server via RDP through the jump host, the session recording captures every action taken. This is not about trust. It is about having a forensic trail when something goes wrong and being able to answer the question "what happened on that server last Tuesday at 3pm" with certainty rather than guesswork.

The rule review problem

Even organisations that build good initial architectures face a persistent challenge: rule decay. The jump host rule that was correctly scoped in 2023 might reference a jump host that was decommissioned in 2024, with traffic now routing through a less secure path. The "temporary" SSH rule for a migration project becomes permanent because nobody set a review date.

This is where automated rule analysis becomes essential. netbobr evaluates your firewall ruleset against known compliance frameworks and flags rules that expose management ports too broadly. Rather than manually auditing hundreds of rules to find the one that allows SSH from the entire office subnet, you get a prioritised list of findings: this rule allows RDP from the internet, that rule permits VNC from a non-management subnet, this WinRM rule uses the HTTP port instead of HTTPS.

The value is not in telling you that exposed management ports are bad. You already know that. The value is in finding the specific rules in your specific environment that create the exposure, especially the ones that accumulated gradually and escaped notice.

Practical steps for the next 30 days

If your organisation has management ports exposed more broadly than they should be, here is a realistic approach to reducing the risk.

Week one: discover. Export your firewall ruleset and search for rules involving ports 22, 3389, 5900, 5985, and 5986. For each rule, document the source range, whether the rule is still needed, and who requested it. You will likely find rules that nobody can explain, referencing sources that no longer exist or servers that were decommissioned months ago.

Week two: classify. Sort the rules into three buckets. Rules that can be removed immediately because the source or destination no longer exists. Rules that can be tightened by reducing the source range to a specific jump host or management subnet. Rules that require architectural changes, such as deploying a bastion host, before they can be addressed.

Week three: act on the easy wins. Remove the dead rules. Tighten the source ranges on rules where the jump host already exists but the rule was never updated. These changes have zero impact on legitimate users and immediately reduce your attack surface.

Week four: plan the architectural work. For the rules that require bastion hosts, VPN changes, or JIT access mechanisms, build a project plan with realistic timelines. These are not afternoon tasks, but they are the changes that produce the most lasting improvement.

The cost of doing nothing

Remote management ports are different from other firewall rules because the consequence of getting them wrong is so severe. An overly broad rule allowing HTTP traffic to a web server is a risk, but the web server was designed to handle untrusted connections. An overly broad rule allowing RDP to a database server gives an attacker a full interactive desktop session with whatever privileges the compromised account holds.

Every ransomware report, every penetration test, every threat intelligence briefing tells the same story. Management ports are the front door. If your firewall rules leave that door open wider than it needs to be, the question is not whether someone will try the handle. It is when. And reviewing those rules with netbobr takes considerably less time than recovering from the incident that follows.