Ist Remote Desktop sicher? Ein ehrliches Bedrohungsmodell

Remote-Desktop-Protokolle verarbeiten Tastenanschläge, Bildschirme und Anmeldeinformationen über das Internet. Hier ist das Bedrohungsmodell, die Kryptographie und die fünf Punkte, die Sie bei jedem Remote-Desktop-Tool überprüfen sollten, bevor Sie ihm vertrauen.
Die Frage "Ist Remote Desktop sicher" hat verschiedene Antworten, je nachdem, welches Remote Desktop Sie meinen. Das native Windows RDP, das dem öffentlichen Internet ausgesetzt ist, gehört zu den am häufigsten missbrauchten Angriffsflächen in der Unternehmens-IT — es taucht jedes Jahr im Ransomware-Bereich des DBIR von Verizon auf. Ein moderner, relay-basierter Client wie GoDesk, AnyDesk oder TeamViewer mit End-to-End-Verschlüsselung hat eine grundlegend andere Sicherheitsarchitektur. Dieser Artikel behandelt das Bedrohungsmodell ehrlich: was tatsächlich geschützt ist, was nicht, und was Sie vor der Installation eines Remote-Desktop-Tools überprüfen sollten.
Zusammenfassung: Transportverschlüsselung (AES-256-GCM) und Schlüsselaustausch (X25519 + ED25519-Signaturen) sind inzwischen Standard — die meisten seriösen Tools verfügen darüber. Die interessante Variation liegt darin, was der Relay sehen kann, wie der unbetreute Zugang gehandhabt wird, ob 2FA durchgesetzt wird und ob der Quellcode überprüft werden kann. Springen Sie zum 5-Punkte-Checkliste am Ende, wenn Sie nur die Aktionspunkte möchten.
Das Bedrohungsmodell: Wogegen verteidigen Sie sich eigentlich?
Drei Klassen von Gegnern spielen für Remote Desktop eine Rolle:
- Netzangreifer (passives oder aktives MITM). Jemand im gleichen WLAN, jemand, der einen bösartigen VPN-Ausstieg betreibt, ein Staatsakteur, der umfassende TLS-Abfangmaßnahmen durchführt. Sie möchten den Datenverkehr zwischen Client und Host lesen oder ändern.
- Anmeldeinformationsangreifer. Jemand, der versucht, sich mit dem Passwort für den unbetreuten Zugriff aus der Ferne einzuloggen. Brute Force, Credential Stuffing, durchgesickerte Datenbankabfragen.
- Vendor-/Relay-Angreifer. Das Remote-Desktop-Unternehmen selbst oder jemand, der sie kompromittiert hat. Sie sitzen definitionsgemäß in der Mitte — was können sie tatsächlich sehen?
Eine vierte Klasse — Endpunktkompromittierung (Schadhafter Code auf einem der beiden Geräte) — macht jedes Remote-Desktop-Tool, das je hergestellt wurde, ineffektiv. Wenn Ihr lokaler PC infiziert ist, rettet Sie kein Verschlüsselungsprotokoll. Wir werden dies hier nicht behandeln, da es außerhalb des Rahmens für das Protokoll selbst liegt.
Transportverschlüsselung: AES-256-GCM
GoDesk (abgeleitet von RustDesk) verschlüsselt jedes Byte zwischen den beiden Clients mit AES-256-GCM, einem authentifizierten Verschlüsselungsmodus, der sowohl Vertraulichkeit (kein Abhören) als auch Integrität (keine Manipulation) schützt. GCM ist der gleiche Chiffremodus, den TLS 1.3 verwendet, der gleiche, den Ihre Bank verwendet, und der gleiche, den das Signal-Protokoll für die symmetrische Ebene verwendet. Es sind bis zum Jahr 2026 keine praktischen Angriffe gegen AES-256-GCM bekannt.
Der Sitzungsschlüssel ist 256 Bit groß, wird pro Sitzung abgeleitet und niemals wiederverwendet. Selbst wenn ein Schlüssel nachträglich auf irgendeine Weise wiederhergestellt werden könnte, wäre nur diese eine Sitzung kompromittiert — vergangene und zukünftige Sitzungen sind unabhängig.
Schlüsselaustausch: X25519 + ED25519
Wie einigen sich die beiden Clients auf einen Sitzungsschlüssel, ohne dass der Relay davon erfährt? X25519, ein elliptischer Kurven-Diffie-Hellman über Curve25519. Jede Seite generiert ein temporäres Schlüsselpaar, tauscht öffentliche Schlüssel über den Relay aus und berechnet unabhängig denselben gemeinsamen geheimen Schlüssel unter Verwendung ihres eigenen privaten Schlüssels plus des öffentlichen Schlüssels der anderen Seite. Der Relay sieht nur die öffentlichen Werte, die ohne einen der privaten Schlüssel nutzlos sind.
Um aktivem Man-in-the-Middle (MITM) vorzubeugen (ein bösartiger oder kompromittierter Relay, der die öffentlichen Schlüssel während der Übertragung austauscht), wird die öffentliche Identität des Hosts mit ED25519 signiert. Beim ersten Mal, wenn Sie sich mit einem Host verbinden, zeigt GoDesk Ihnen den Fingerabdruck des Host-Schlüssels an — dies ist das Vertrauen-bei-erster-Nutzung (TOFU)-Modell, das dasselbe wie SSH ist. Bei nachfolgenden Verbindungen verifiziert der Client, dass der Fingerabdruck übereinstimmt; wenn ein Relay versucht hat, Sie zu hintergehen, würde sich der Fingerabdruck ändern und der Client würde sich weigern, sich zu verbinden.
X25519 + ED25519 ist die gleiche primitive Gruppe, die von WireGuard, Signal, age und modernem SSH verwendet wird. Sie wird breit auditiert und gilt als aktuelle Best Practice.
Was der Relay tatsächlich sieht
Das ist die Frage, die Remote-Desktop-Tools bedeutend voneinander trennt. Einige Produkte beenden TLS am Relay und verschlüsseln die Verbindung erneut zum Client — das bedeutet, dass der Anbieter technisch Ihre Sitzung entschlüsseln kann. Andere, einschließlich GoDesk/RustDesk, leiten den End-to-End-Verschlüsselten Datenstrom durch den Relay: der Anbieter kann Ihre Sitzung nicht entschlüsseln, selbst bei vollem Zugriff auf die Relay-Protokolle.
| Tool | Sieht der Relay nur Chiffretext? | Quellcode auditiert? | Selbst-gehosteter Relay? |
|---|---|---|---|
| GoDesk / RustDesk | Ja | Ja (AGPL-3.0) | Ja |
| AnyDesk | Ja (laut deren Dokumentation) | Nein (proprietär) | Nur im Unternehmensbereich |
| TeamViewer | Ja (laut deren Dokumentation) | Nein (proprietär) | Nur Tensor Enterprise |
| Chrome Remote Desktop | Leitet über die Google-Infrastruktur; Google hält die Schlüssel für ChromeOS-spezifische Abläufe | Teilweise (Erweiterung ist offen) | Nein |
| Native Windows RDP (über WAN) | N/A — direkte Verbindung, wenn exposed | Nein | N/A |
| VNC (RealVNC, TightVNC) unverschlüsselt | Oft standardmäßig unverschlüsselt | Gemischt | Ja |
Zwei Anmerkungen zur Tabelle. Erstens ist „Der Anbieter behauptet, der Relay sieht nur Chiffretext“ etwas, das wir für proprietäre Produkte glauben müssen — ohne Zugriff auf den Quellcode können Sie dies nicht überprüfen. Zweitens ist klassisches VNC über das offene Internet die schlechteste Option in dieser Liste: Viele VNC-Varianten werden standardmäßig ohne Transportverschlüsselung geliefert, und Anmeldeinformationen werden in einer Challenge-Response gesendet, die seit Jahren kompromittiert ist. Führen Sie kein unverschlüsseltes VNC über das Internet aus.
Authentifizierung: Passwörter vs. 2FA
Für den unbetreuten Zugriff (bei dem Sie ein Passwort auf dem Host setzen, sodass Sie später ohne Bestätigung verbinden können) ist das Passwort die gesamte Verteidigung. Zwei Ausfallszenarien:
- Schwaches Passwort: Ein 4-stelliger PIN ist innerhalb von Sekunden mit Brute-Force angreifbar. Ein 6-stelliges alphanumerisches Passwort ist bei Netzwerkzugang innerhalb von Stunden anzugreifen. Verwenden Sie 12+ Zeichen aus einem Passwort-Manager. GoDesk zwingt eine Mindestlänge von 6 Zeichen und warnt vor gängigen Passwörtern; wir empfehlen 16+ für jeden unbetreuten Host, der über das Internet erreichbar ist.
- Kein zweiter Faktor: Wenn das Passwort durchgesickert ist, ist das die gesamte Authentifizierung. Aktivieren Sie 2FA, wenn Ihr Tool dies unterstützt — GoDesk unterstützt TOTP für kostenpflichtige Tarife. AnyDesk und TeamViewer bieten ähnliche Optionen.
Für interaktive Support-Sitzungen (bei denen jemand Ihnen einen Einmal-Code vorliest) ist die Bedrohung viel geringer, da die Sitzung zeitlich begrenzt ist und der Code abläuft. Der klassische Angriff ist, dass Betrüger versuchen, Opfer dazu zu bringen, den Code zu lesen — Microsofts "Technischer Support"-Betrügereien verwenden genau diesen Vektor, und kein Maß an Kryptographie kann das beheben.
Risiken des unbetreuten Zugriffs
Unbetreuter Zugriff ist die nützlichste und riskanteste Funktion. Definitionsgemäß hinterlassen Sie ein Anmeldeinformation auf dem Host, die, falls sie durchgesickert ist, es jedem ermöglicht, sich aus der Ferne ohne Aufforderung einzuloggen. Empfohlene Praktiken:
- Verwenden Sie ein einzigartiges Passwort pro Host. Verwenden Sie das Passwort nicht auf mehreren Maschinen.
- Aktivieren Sie 2FA, wo unterstützt.
- Setzen Sie eine Inaktivitätszeitüberschreitung, sodass ruhende unbetreute Sitzungen getrennt werden. GoDesk hat standardmäßig 4 Stunden.
- Verwenden Sie die Zugriffsliste — beschränken Sie eingehende Verbindungen auf bestimmte Geräte-IDs, die Sie kontrollieren. GoDesk unterstützt dies in den Sicherheitseinstellungen.
- Überwachen Sie das Verbindungsprotokoll regelmäßig. Unerwartete Verbindungen sind ein Warnsignal.
Warum das native RDP, das dem Internet ausgesetzt ist, besonders schlecht ist
RDP selbst ist nicht unsicher — Microsoft hat das Protokoll erheblich gehärtet, und die neuesten Versionen verwenden TLS-geschützte CredSSP. Das Problem liegt im operativen Bereich. RDP hört auf einem bekannten Port (3389) auf, wird normalerweise nur durch ein Windows-Passwort authentifiziert und ist Ziel ständiger Brute-Force-Scans. Sobald ein Angreifer Zugriff hat, hat er eine angemeldete interaktive Windows-Sitzung — der nützlichste mögliche Einstiegspunkt für die Bereitstellung von Ransomware. Aus diesem Grund hebt CISA und das FBI gezielt das exposed RDP als einen der top 3 Ransomware-Zugriffsvektoren hervor. Tools wie GoDesk, AnyDesk und TeamViewer vermeiden das Problem völlig, indem sie niemals einen Dienst im Internet sichtbarer machen.
Die 5-Punkte-Checkliste für jedes Remote-Desktop-Tool
Welche Tools Sie auch immer wählen, überprüfen Sie diese fünf Dinge, bevor Sie ihm bei irgendetwas vertrauen:
- End-to-End-Transportverschlüsselung mit AES-256 oder ChaCha20-Poly1305. Alles andere (keine Verschlüsselung, RC4, unverschlüsseltes VNC) disqualifiziert. Überprüfen Sie die Dokumentation, nicht die Marketingseite.
- Vorwärts-geheime Schlüsselübergabe (Diffie-Hellman irgendeiner Art). X25519 ist der moderne Standard. ECDH P-256 ist akzeptabel. Statische RSA-Schlüsselübergabe ist ein Warnsignal.
- Dokumentiertes Relay-Modell: sieht der Anbieter Chiffretext oder Klartext? Lesen Sie ihr Sicherheits-Whitepaper. Wenn sie darauf keine Antwort haben, gehen Sie weiter.
- Zwei-Faktor-Authentifizierung für unbetreuten Zugriff. Wenn Ihr Tool keine 2FA anbietet, aktivieren Sie keinen unbetreuten Zugang zu Hosts, die über das Internet erreichbar sind.
- Lesbarer Quellcode oder dritte Audits. Open Source (wie GoDesk/RustDesk unter AGPL-3.0) ist der stärkste Beweis. Andernfalls ist ein SOC 2 Typ II-Bericht oder ein veröffentlichtes Pen-Test akzeptabel.
Fazit
Die Frage "Ist Remote Desktop sicher" ist die falsche Frage. Die richtige lautet: welches Remote Desktop, wie eingesetzt. Ein modernes, relay-basiertes Tool mit AES-256-GCM-Transport, X25519-Schlüsselaustausch, End-to-End-Verschlüsselung über den Relay und 2FA bei unbetretem Zugang ist in etwa so sicher wie jedes andere Internetprotokoll, dem Sie täglich vertrauen. RDP, das über einen weitergeleiteten Port mit einem schwachen Passwort exposed ist, ist es nicht. Lesen Sie GoDesks vollständige Sicherheitsarchitektur für die Details auf Protokollebene oder laden Sie den Client herunter und prüfen Sie ihn selbst — der Quellcode ist auf GitHub.
FAQ
Kann das GoDesk-Team meine Remote-Desktop-Sitzungen lesen?
Nein. Der Sitzungsschlüssel wird End-to-End über X25519 zwischen Ihren beiden Clients ausgehandelt. Unser Relay leitet nur AES-256-GCM-Chiffretext weiter. Wir könnten Ihren Datenverkehr auch bei vollem Zugriff auf den Relay-Server nicht entschlüsseln.
Ist Open Source tatsächlich sicherer als Closed Source?
Die Verfügbarkeit des Quellcodes ist notwendig, aber nicht ausreichend. AGPL-3.0 bedeutet, dass ein unabhängiger Auditor überprüfen kann, ob das Protokoll mit der Dokumentation übereinstimmt; bei Closed-Source-Tools muss man dem Anbieter vertrauen. Beide können sicher sein, wenn sie gut implementiert sind; nur eines ist überprüfbar.
Sollte ich mir Sorgen über das Vertrauen-bei-erster-Nutzung-Fingerabdruckmodell machen?
Nur wenn Sie die Verbindung über ein Netzwerk herstellen, dem Sie nicht vertrauen. Für paranoide Setups, überprüfen Sie den Fingerabdruck des Hosts außerhalb der Bandbreite (lesen Sie ihn über einen telefonischen Anruf, nicht über den Chat) bei der ersten Verbindung. Danach speichert der Client den Fingerabdruck lokal.
Gibt es bekannte CVEs in RustDesk / GoDesk?
Das RustDesk-Projekt hatte im Laufe der Jahre einige veröffentlichte Probleme, meist im optionalen, selbst-gehosteten Serverbereich — die in jedem Fall prompt gepatcht wurden. Der Desktop-Client selbst hat bis Mai 2026 keine schwerwiegenden Remote-Code-Execution-CVEs gehabt. Überprüfen Sie die Sicherheitswarnungen-Seite auf GitHub für die aktuelle Liste.
Welche 2FA-Methoden unterstützt GoDesk?
TOTP über jede Standard-Authenticator-App (Authy, 1Password, Google Authenticator) in Lite- und Pro-Tarifen. Unterstützung für Hardware-Schlüssel (WebAuthn) ist auf der Roadmap.
More articles
Remote Desktop ohne Portweiterleitung: Wie es tatsächlich funktioniert
9 Min. Lesezeit
RustDesk vs AnyDesk: Ein Käuferleitfaden 2026 (und die dritte Option, die die meisten Bewertungen auslassen)
11 Min. Lesezeit
AnyDesk Preisgestaltung erklärt: Eine verständliche Dekodierung für 2026
9 Min. Lesezeit