Secure Remote Access: SSH, RDP and VPN

Secure Remote Access: SSH, RDP, VPN and Zero Trust — The Guide to Amplify Your Security

Why leaving port 3389 open on the internet is the digital equivalent of leaving your house key under the doormat — and what to do instead.

Introduction

At some point in the last five years, your company needed someone to access a server, desktop, or internal network from outside the office. The pandemic accelerated all of this brutally: services that used to stay within four walls became exposed to the internet overnight. Often without security review, without MFA, without proper logs.

The result? Remote access is today one of the main vectors for intrusion and ransomware worldwide. Practically every major ransomware incident in recent years started with one of three things: phishing, web vulnerability, or exposed and poorly protected remote access. RDP exposed on port 3389 is so common as an initial vector that several ransomware groups have "RDP scanners" as standard tools.

This guide covers:

1. SSH, RDP, VNC, Telnet — what each does, the risks of exposing them, and how to protect them
2. Traditional VPN — IPsec, OpenVPN, WireGuard — when it makes sense, when it doesn't anymore
3. Zero Trust and ZTNA — what it is, why it replaces VPN in many cases
4. Cloudflare One, Tailscale, Twingate, Zscaler — practical comparison
5. Specific risks for each exposure — with real scenarios
6. Practical recommendations — what to do to sleep soundly

Part 1: Classic remote access protocols

1.1 RDP (Remote Desktop Protocol) — port 3389

RDP is Microsoft's proprietary protocol for graphical access to Windows machines. It's extremely popular because it comes installed by default on all Windows Server and Pro versions, and the experience is almost native.

What happens when you expose port 3389 on the internet:

In the first 24 hours after opening a port 3389 on a public IP, it will receive thousands of connection attempts. There are botnets dedicated exclusively to scanning the internet for exposed RDP.

Attacks against exposed RDP include:

• Credential brute force — bots try combinations of Administrator, admin, user, test with common passwords
• Credential stuffing — they use lists of passwords leaked from other services
• CVE exploitation — BlueKeep (CVE-2019-0708) allowed remote code execution without authentication
• NLA bypass attacks — some configurations accept negotiating vulnerable old protocols

Scary statistic: according to reports from various cyber insurers and DFIR companies, exposed RDP is the initial vector in somewhere between 40% and 60% of investigated ransomware cases.

How to protect if you need RDP:

Rule number one: never, under any circumstances, expose RDP directly to the internet.

If you need RDP, use:

1. Corporate VPN — user connects to VPN first, then accesses RDP via internal IP
2. RD Gateway — Microsoft native solution that tunnels RDP inside HTTPS on port 443
3. Bastion host — intermediate machine (Azure Bastion, AWS Session Manager)
4. ZTNA — Zero Trust Network Access (we'll cover this in Part 3)

Always with:

• Mandatory MFA
• Network Level Authentication (NLA) enabled
• Account lockout after X failed attempts
• Centralized logs
• Up-to-date patches

1.2 SSH (Secure Shell) — port 22

SSH is the standard protocol for remote access to Linux/Unix servers. It was created in 1995 to replace Telnet.

What happens when you expose port 22:

Similar to RDP in volume. Bots try credentials — root, admin, ubuntu, pi, oracle, git. The difference is that well-configured SSH is much more resistant than RDP, because it allows authentication via cryptographic key.

How to protect SSH:

# /etc/ssh/sshd_config — minimum recommended configuration

PermitRootLogin no
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no
UsePAM yes
PubkeyAuthentication yes
Protocol 2

KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com

MaxAuthTries 3
MaxSessions 5
LoginGraceTime 30

AllowUsers seuusuario

X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no

LogLevel VERBOSE
SyslogFacility AUTH

And fail2ban:

sudo apt install fail2ban

# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = 22
maxretry = 3
findtime = 600
bantime = 86400

Other tips:

1. Change the default port. It's not real security, but it drastically reduces log noise.
2. Use ED25519 keys: ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519
3. Consider FIDO2: ssh-keygen -t ed25519-sk -f ~/.ssh/ided25519sk
4. SSH bastion in larger environments
5. NEVER expose SSH with password to the internet

1.3 VNC — port 5900

VNC has a catastrophic security history:

• Some old versions accepted connection without authentication
• Weak passwords by design (8-character limit in the classic version)
• No encryption by default in many implementations
• Frequent CVEs for RCE

Bottom line: don't use VNC exposed on the internet.

Alternatives:

1. SSH with X11 forwarding (ssh -X)
2. VNC inside SSH tunnel (ssh -L 5900:localhost:5900 user@server)
3. NoMachine or xrdp
4. VPN or ZTNA in front

1.4 Telnet — port 23

Plain text. No encryption. No strong authentication. Everything in the clear.

Botnets like Mirai specialized in finding Telnet exposed on IP cameras, routers, and DVRs with default credentials. Mirai took down Twitter, GitHub, Reddit, and Spotify in 2016 using this botnet.

Disable today:

sudo systemctl status telnet.socket
sudo systemctl disable telnet.socket
sudo systemctl stop telnet.socket
sudo apt remove telnetd

1.5 Other protocols dangerous when exposed

• FTP (21) — plain text. Use SFTP or FTPS
• SMB/CIFS (445) — WannaCry vector. Never expose
• SNMP v1/v2c (161) — community strings in plain text
• MySQL/PostgreSQL/MongoDB/Redis — databases should never be exposed
• VNC over HTTP (5800) — same problems as VNC
• Webmin (10000), cPanel (2083), Plesk (8443) — restrict by IP or ZTNA

Part 2: Traditional VPN

2.1 The main protocols

IPsec — veteran, industry standard, complex configuration, NAT issues.

OpenVPN — mature open-source, flexible, limited performance (single-threaded).

WireGuard — new generation, ~4,000 lines of code, fixed modern cryptography, exceptional performance.

PPTP — cryptographically broken since 2012. Never use it.

L2TP/IPsec, SSTP — legacy, very specific cases.

2.2 What can go wrong with VPN

The VPN concentrator is the target. Serious vulnerabilities in recent years:

• Pulse Secure (CVE-2019-11510)
• Fortinet FortiGate (CVE-2018-13379)
• Citrix ADC (CVE-2019-19781)

Access is binary. Connected? Access to the entire network. Lateral movement is easy.

Poor performance at global scale. Backhaul to the concentrator.

MFA often optional or poorly implemented.

Limited visibility into what the user accessed within the network.

2.3 When VPN still makes sense

• Site-to-site (connecting two entire networks) — IPsec is still king
• Legacy equipment without modern authentication
• Compliance that requires traditional VPN
• Small environments, low criticality
• Zero budget (WireGuard self-hosted is free)

Part 3: Zero Trust and ZTNA

3.1 The concept

The phrase: "never trust, always verify" — never trust, always verify.

The traditional model was "castle": walls, gates, everyone inside is trustworthy. Zero Trust inverts:

1. Don't trust anyone by default (internal or external)
2. Always verify — every request authenticated and authorized
3. Least privilege — only what you need
4. Assume breach has occurred
5. Total visibility — all access logged and analyzed

3.2 ZTNA — Zero Trust Network Access

While VPN connects you to the entire network, ZTNA connects you to specific applications, after validating who you are, on which device, in which context.

How it works:

1. User tries to access an application
2. ZTNA intercepts the request
3. Verifies: user authenticated? Device OK? Time OK? IP OK? Permission for this app?
4. If everything checks out, grants access only to that application
5. If something is wrong, blocks or asks for MFA

The user never has access to the network, only to the application. The application is not exposed to the internet. The ZTNA connector runs within the network and makes an outbound connection to the provider.

3.3 The main players

Cloudflare One (Cloudflare Access + Tunnel)

• Robust free plan
• Integrates with Google, Microsoft, Okta, GitHub
• Excellent performance — PoPs in hundreds of cities
• Works for HTTP, SSH, RDP, VNC

Tailscale

• Built on WireGuard
• Absurdly easy setup
• Generous free plan
• Excellent P2P performance
• Mostly open-source

Twingate

• "Pure" ZTNA from design
• Good AD/Okta integration
• Fine granularity
• Free plan for small use

Zscaler Private Access (ZPA)

• Robust Enterprise
• Compliance and certifications
• Expensive and complex
• Overkill for small companies

Microsoft Entra Private Access

• Native integration with everything Microsoft
• Licensed within M365
• Powerful Conditional Access

Others: Perimeter 81/Check Point Harmony, NetSkope, Palo Alto Prisma, Cato Networks.

3.4 VPN vs ZTNA Comparison

| Aspect | Traditional VPN | Modern ZTNA | |---|---|---| | Access | Entire network | Specific applications | | Internet exposure | Concentrator exposed | No open ports | | Lateral movement | Easy | Drastically difficult | | Granularity | By user/group | By user + device + context + app | | Visibility | VPN connection | Each access to each app | | Global performance | Backhaul | Closest PoP | | Setup | Complex | Usually simple | | Entry cost | Can be zero (self-hosted) | Can start free |

Part 4: Consolidated risks

| Service | Port | Risk if exposed | What to do | |---|---|---|---| | RDP | 3389 | Critical. Vector #1 ransomware | Never expose. VPN/RD Gateway/bastion/ZTNA | | SSH with password | 22 | High. Brute force | Disable password. Use ED25519 keys | | SSH with key | 22 | Low if updated | Hardening + fail2ban + monitoring | | VNC | 5900 | Critical. Catastrophic history | Never expose. Use SSH tunnel/ZTNA | | Telnet | 23 | Critical. Plain text | Disable. Use SSH | | FTP | 21 | High. Plain text | SFTP or FTPS | | SMB | 445 | Critical. WannaCry vector | Never expose | | SNMP v1/v2c | 161 | High. Community in plain text | SNMPv3, never expose | | Databases | various | Critical. Extortion and theft | Never expose. Firewall + strong auth | | Admin panels | various | High. CVE RCEs | IP whitelist or ZTNA | | VPN concentrator | varies | High. Priority target | Patches + MFA + monitoring |

Part 5: Practical recommendations

1. Make an inventory of what's exposed. You can't protect what you don't know exists.

2. Map what each port should be doing. For each service: does it need to be exposed? Why? Who uses it? When was it last reviewed?

3. Close everything that doesn't need to be open. Immediately.

4. For everything that needs remote access, never expose the service directly. In order:

• ZTNA (first choice)
• Modern VPN (WireGuard)
• Traditional VPN (IPsec/OpenVPN)
• Bastion host with SSH

5. Enable MFA on everything. No exceptions.

6. Keep everything updated. Critical patches within 48 hours.

7. Monitor continuously. Exposures reappear.

8. Centralized logs. Failed attempts, strange IPs, unusual times.

9. Quarterly reviews at minimum.

10. Train your users. Social engineering bypasses MFA.

Final considerations

The difference between a company with adequate remote access hardening and one without is often the difference between being in the news for something good (product launch) or something bad (ransomware attack with a week of downtime).

The good news: modern tools — especially ZTNA — have made doing the right thing easier and cheaper than continuing to do the wrong thing. Cloudflare One, Tailscale, and Twingate have free plans. WireGuard is free. SSH with ED25519 keys is free. Doing nothing costs more.

The worst scenario isn't the sophisticated attack. It's the annoying attack: bot brute-forcing exposed RDP, finding a weak password, installing ransomware, encrypting everything. Not a movie attacker. It's an automated script running for months, waiting for someone to leave the door slightly ajar.

SentinelHub scans exactly this type of exposure: monitors your public IPs, identifies exposed ports and services, alerts when something new appears, crosses with CVE databases to see if the version has known vulnerability, and translates everything to English so you don't have to guess.

Found it useful? Share with your company's IT team. If they still have RDP exposed on the internet, especially share.