Remote Desktop Protocols: RDP, VNC & Modern Alternatives

Remote Support Tools & Techniques

Chapter 4 · Remote Desktop Protocols: RDP, VNC & Modern Alternatives

Chapters 2 and 3 covered SSH — command-line access. This chapter covers the scenarios that genuinely need a GUI instead: a Windows admin tool with no CLI equivalent, a legacy application only usable through its desktop interface, or visually confirming a display issue no remote command can fully capture.

RDP: Windows-Native, Encrypted, Efficient

RDP (Remote Desktop Protocol) is built into Windows, and encrypted by default (TLS-based) in modern versions. A real, genuine technical advantage: RDP sends drawing instructions and screen deltas rather than raw video frames, generally making it more bandwidth-efficient than VNC's typical full-framebuffer approach. Practically, the target account usually needs explicit RDP access granted — membership in the Remote Desktop Users group — a standard, deliberate admin step, not something that happens by default.

VNC: Cross-Platform, But Check the Implementation

VNC works across Windows, macOS, and Linux — genuinely cross-platform, unlike RDP's Windows-native server side. But VNC's own security posture varies significantly by implementation: some VNC servers have historically shipped with weak encryption, or none at all, by default. "VNC" isn't one single security guarantee the way modern RDP roughly is — it depends heavily on which specific server and client you're using and how it's configured.

A genuinely good mitigation: tunnel VNC through SSH

Reusing Chapter 3's own port-forwarding technique directly: tunneling VNC traffic through an SSH port forward gets VNC's real cross-platform reach combined with SSH's own well-understood encryption and authentication guarantees — a practical, common way to close the gap a bare VNC connection can leave open.

Modern Alternatives: TeamViewer, AnyDesk, Chrome Remote Desktop

These tools are generally not what you'd reach for to administer infrastructure you already have RDP/VNC/SSH access to — they solve a genuinely different problem: an ad-hoc session with an end user's own machine, often sitting behind NAT or a firewall with no direct network path available at all. Both sides connect outward to the vendor's own relay servers, meeting there — avoiding any need for inbound firewall rules on either end. This relay model is exactly what makes them practical for helping a random end user, and it's also what sets up Chapter 5's own "different trust model" material directly.

A Clear Decision Table

Situation	Reach for
Infrastructure you administer — a Windows server	RDP, through a VPN or jump host
Infrastructure you administer — cross-platform	VNC, tunneled through SSH
An end user's own machine, ad-hoc, no existing access path	A relay-based tool — TeamViewer, AnyDesk, Chrome Remote Desktop

Never expose RDP directly to the internet

RDP has been a major, persistent attack target specifically because it's so often left directly internet-facing — credential-stuffing campaigns and real, serious exploits (BlueKeep among them) have targeted exposed RDP endpoints repeatedly. Exactly the same principle from Chapter 3's own database example applies here: RDP should be reached through a VPN or a jump host, never opened directly to the internet just for convenience.

Working Example: A GUI-Only Disk Management Tool

A storage issue on a Windows server needs investigating with its own Disk Management tool — no convenient CLI equivalent exposes the same information, the kind of scenario System Monitoring & Performance Diagnosis's own disk-space material assumes a shell for, but this specific tool genuinely doesn't have one. The correct path: connect through the organization's VPN or jump host first, then RDP to the target server from there — never RDP directly to a server exposed on the open internet, confirming the connection is going through the sanctioned path before doing anything else.

Hands-On Exercises

Exercise 1

Explain why this chapter says "VNC" alone isn't a reliable security guarantee the way modern RDP roughly is, and what practical technique it recommends to close that gap.

📄 View solution

Exercise 2

Explain what makes relay-based tools like TeamViewer or AnyDesk genuinely different from RDP/VNC's own connection model, and why that difference makes them better suited to ad-hoc end-user support.

📄 View solution

Exercise 3

Explain why this chapter says RDP should never be exposed directly to the internet, and what real-world evidence it cites for that risk.

📄 View solution

Chapter 4 Quick Reference

RDP: Windows-native, encrypted by default, efficient delta-based rendering, needs explicit access granted
VNC: genuinely cross-platform, but security depends entirely on the specific implementation — tunnel through SSH for real safety
Relay-based tools (TeamViewer/AnyDesk/Chrome Remote Desktop): both sides connect outward to a relay, no inbound firewall rules needed — built for ad-hoc end-user sessions, not infrastructure you administer
Decision table: infrastructure you own → RDP/VNC-over-SSH through a VPN or jump host; someone else's machine, ad-hoc → a relay tool
Never expose RDP directly to the internet — a real, historically exploited attack target; always go through a VPN or jump host
Next chapter: Screen Sharing for End-User Support: A Different Trust Model