Stop exposing RDP and SSH: a plain-English guide for small businesses

Plenty of small businesses can be reached from the internet in ways nobody remembers setting up. A remote desktop port opened years ago for a contractor. A server someone forwarded SSH to “just for the weekend”. A camera recorder with a web page on the internet. Each is a door with a lock on it, and every day automated programs try every lock.

This guide is for owners and the people who look after IT for them, whether or not they are specialists. It explains the risk without jargon, shows how to find out what is open and describes what to use instead.

Why an open remote access port is a problem

Remote Desktop Protocol (RDP) and Secure Shell (SSH) give someone a full session on a machine. That is exactly what an attacker wants, and exactly what you want to keep from them.

When one of those ports is open to the internet:

It will be found. The internet is scanned constantly, by researchers and by criminals. A new open port is typically probed within hours. There is no such thing as being too small or obscure to notice.
It will be attacked. The usual attack is not clever. Programs try common usernames and passwords, or passwords leaked from other breaches, thousands of times. If one works, the attacker is inside with your user’s permissions.
The software can have flaws. Remote access software has had serious vulnerabilities, including ones that allowed an attacker to take control with no password at all. A well-known example is the RDP flaw nicknamed BlueKeep. When a flaw is found, anything directly exposed is at risk until patched.
One compromised machine is a foothold. From a single machine an attacker can look around, steal credentials and move to others. Exposed remote access is a frequently reported way in for ransomware.

Strong passwords help and are not enough on their own. The better principle is: if a service does not need to be reachable by the whole internet, it should not be.

Step 1: find out what is exposed

You cannot fix what you do not know about. Start with the places an exposure is created.

Your router or firewall. Look for port forwarding, sometimes called virtual servers or NAT rules. Write down every entry: the port, the machine it points at and who asked for it. Ports 3389 (RDP), 22 (SSH), 5900 (VNC) and 23 (Telnet) deserve particular suspicion.
A scan from outside. Test your own public address from a network that is not yours, such as a phone on mobile data. Only scan addresses you own or are authorised to test. From a Linux machine you can run:
```
nmap -Pn -p 22,23,80,443,3389,5900 203.0.113.10
```
Replace 203.0.113.10 with your own public address. Anything reported as open is reachable from the internet.
Internet-wide search engines. Services that index what is reachable on the internet let you search for your own address and see what they have recorded about it.
Cloud servers. In your cloud provider’s console, look at the firewall or security group rules for any that allow “0.0.0.0/0”, meaning everyone, to remote access ports.
Ask. Contractors, managed service providers and former staff may have set up access you know nothing about.

Keep the results as a simple list. It becomes your plan.

Step 2: decide what each one is for

For every open port, ask three questions: who uses it, why and how often? The answers fall into groups:

Nobody uses it. Close it today.
A person uses it for their own work. Replace it with one of the options below.
A supplier uses it for support. Replace it with an arrangement where you grant access when needed and it is logged.
A device or system needs it. Move it behind a gateway so it is not directly on the internet.

Step 3: put something safer in place

A VPN to your firewall. People connect to the office network through a VPN, then use remote desktop or SSH as if they were in the office. The remote access port is no longer exposed, and only the VPN is. Keep the firewall’s software updated, because the VPN service is now the thing on the internet. Require two-factor authentication.

Tunnelled access with a login in front. Cloudflare Tunnel and similar services make an outbound connection from your network and let approved people reach a specific machine after proving who they are. Nothing is open on your firewall. SSH through a Cloudflare Tunnel shows the pattern, and putting a login in front of a tunnelled app explains the identity part.

A mesh network. Services such as Tailscale give each approved device a private address and connect them without opening ports. They suit a small team who need to reach a few machines.

A hardened jump host. One carefully secured machine is the only place the outside world can reach, and everything else is reached through it. It needs two-factor authentication, logging and prompt patching. This is more work than the options above and rarely the best choice for a small business, though it is a long-standing pattern.

The remote access picker can help you choose, and the comparison sets out the trade-offs.

Step 4: the basics that apply to all of them

Whichever you pick, these matter more than the choice:

Two-factor authentication everywhere remote access is possible. It stops most attacks that depend on stolen or guessed passwords.
Individual accounts. No shared logins. When someone leaves, you disable one account, and when something goes wrong you can see who did it.
Least privilege. Most people do not need administrator rights for daily work, and an attacker who steals an ordinary account gets less.
Patching. Operating systems, firewalls, VPN software and remote access tools. Turn on automatic updates where it is safe to.
Logging. Keep records of who logged in and from where, and look at them. If you cannot tell whether someone got in, you cannot tell whether they left.
Backups that an attacker cannot reach. Keep at least one copy offline or otherwise out of reach of the machines it protects, and test restoring from it. Ransomware goes after backups it can reach.

A checklist you can use this week

Listed every port forward on the router or firewall.
Scanned our own public address from outside.
Closed everything nobody can explain.
Checked cloud security groups for “allow from anywhere” on remote access ports.
Chosen a replacement for each remaining use.
Turned on two-factor authentication for remote access.
Removed shared accounts and the accounts of people who have left.
Confirmed updates are applied to the firewall, VPN and remote access software.
Tested that a backup can be restored.

Getting help

If this feels like more than you can take on, that is normal, and it is the kind of work a network or security professional can do in a short engagement. A good one will give you a written list of what was found, what was changed and why.

This guide is general information, not a substitute for advice on your own systems.