A remote desktop service is reachable from the internet

HighHigh confidencenet.ports.remote-admin-exposed

What this check looks for

Port ‹port› on ‹host› accepts connections from anywhere, and that port is where ‹service› listens — remote desktop, either RDP or VNC. This is a full interactive session on the machine, protected by one password.

Why it matters

Internet-facing remote desktop is the single most frequently named entry point in ransomware incident reports. Automated tools try millions of password combinations against these ports continuously, and the protocols themselves have a history of pre-authentication vulnerabilities.

When the check passes, your report says: “No remote desktop service answered from the public internet”.

What it costs your score

When this check fails it removes 30 points from your Network score, before the status, confidence and repeat multipliers are applied. Network carries a weight of 5 in the overall score.

It shares the network.exposure family ceiling of 60 points: however many findings that family produces, together they cannot remove more than that from Network. One underlying problem showing up in several places is still one problem.

Severity: high
Default confidence: high
Status when triggered: fail
Deduction: 30 points
Family cap: network.exposure · 60
Category: Network
Module: Net ports
Fix owned by: user
In the ruleset since: 2026.09

How the whole score is calculated

How to fix it

Put ‹service› behind a VPN or a bastion host and close port ‹port› to the internet.

An internet-facing remote desktop port is under continuous automated attack and gives an attacker who succeeds an interactive session rather than a single record.

Stand up a VPN, a cloud bastion, or the provider's session-manager service, and confirm you can reach the machine through it.
Deny port ‹port› at the firewall and at the cloud security group, leaving only the VPN or bastion path.
Where the service is Windows RDP, enable Network Level Authentication so an unauthenticated client never reaches the session host.
Enable multi-factor authentication at the gateway, and account lockout on the machine itself.
Review the machine's authentication log for successful logins from addresses you do not recognise before you close the port, not after.

How to confirm it worked

nc -z -w 3 ‹host› ‹port› — should fail from an address outside your VPN
Connect through the VPN or bastion and confirm the service is still reachable that way

A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.

Remediation by platform

Linux host

# 1. Find out what is listening, and on which address.
sudo ss -tlnp | grep -E ':(21|1433|3306|3389|5432|5900|6379|27017)\b'

# 2. Bind the service to the loopback interface or a private address, not 0.0.0.0.
#    MySQL/MariaDB: bind-address = 127.0.0.1      (my.cnf)
#    PostgreSQL:    listen_addresses = 'localhost' (postgresql.conf)
#    Redis:         bind 127.0.0.1                 (redis.conf) + requirepass
#    MongoDB:       net.bindIp: 127.0.0.1          (mongod.conf)

# 3. Deny the port at the host firewall, then allow only the hosts that need it.
sudo ufw deny 3306/tcp
sudo ufw allow from 203.0.113.10 to any port 3306 proto tcp

# 4. Restart the service and confirm it is no longer bound to a public address.
sudo ss -tlnp | grep 3306

Cloudflare

Cloudflare's proxy only carries HTTP and HTTPS traffic, so no Cloudflare setting closes a database or remote-administration port. If the origin's address is publicly known, the port is reachable regardless of what the DNS record says.

Do both: bind the service privately *and* deny at the firewall. Either alone is one mistake away from re-exposure — a package upgrade that restores a default config, or a firewall flush on reboot.
Listed to rule it out. The fix is at the host firewall or the cloud provider's security group. Cloudflare Tunnel or Access can replace a direct exposure once the port itself is closed.

Technical detail

A TCP connection to ‹host›:‹port› completed. ‹implication›

**RDP and VNC are not equally bad, and both are bad enough.** RDP is encrypted and has a history of pre-authentication vulnerabilities; VNC in its common configurations is not encrypted at all, has a password scheme that is weak by design, and is sometimes deployed with no authentication whatsoever. Which one this is shows in the service name above.

This is a different risk from an exposed database. A database leaks data; an interactive session is the machine. Once inside, an attacker has whatever the logged-in account has, and the sessions are hard to distinguish from legitimate administration in a log.

We did not attempt authentication, so we make no claim about whether the credentials are weak. The exposure is the finding: this service should not be one password away from the entire internet regardless of how good that password is.

**The fix is not a stronger password.** Put the service behind something that terminates the connection before it reaches the desktop — a VPN, the cloud provider's bastion or session-manager service, or an identity-aware proxy. Where that is genuinely impossible, the minimum is an address allow-list at the firewall plus multi-factor authentication at the gateway, and network-level authentication enabled so an unauthenticated client never reaches the session layer.

Confidence is high rather than confirmed because an endpoint accepting a connection is not proof of which software is behind it.