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.
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: SSH, RDP, VNC, Telnet — what each does, the risks of exposing them, and how to protect them Traditional VPN — IPsec, OpenVPN, WireGuard — when it makes sense, when it doesn't anymore Zero Trust and ZTNA — what it is, why it replaces VPN in many cases Cloudflare One, Tailscale, Twingate, Zscaler — practical comparison Specific risks for each exposure — with real scenarios 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: Corporate VPN — user connects to VPN first, then accesses RDP via internal IP RD Gateway — Microsoft native solution that tunnels RDP inside HTTPS on port 443 Bastion host — intermediate machine (Azure Bastion, AWS Session Manager) 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: And fail2ban: Other tips: Change the default port. It's not real security, but it drastically reduces log noise. Use ED25519 keys: ssh-keygen -t ed25519 -a 100 -f /.ssh/id ed25519 Consider FIDO2: ssh-keygen -t ed25519-sk -f /.ssh/id ed25519 sk SSH bastion in larger environments 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: SSH with X11 forwarding (ssh -X) VNC inside SSH tunnel (ssh -L 5900:localhost:5900 user@server) NoMachine or xrdp 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: 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), Ple…