RustDesk selbst hosten 2026: souveräne TeamViewer-Alternative richtig absichern

RustDesk vollständig betrieben - als Managed Service - WZ-IT richtet Ihren eigenen ID- und Relay-Server ein, härtet ihn und übernimmt Updates und Monitoring. Souveräne Fernwartung ohne Cloud-Zwang, auf Ihrer Infrastruktur in der EU. Erstgespräch buchen · Mehr zu RustDesk · Remote-Management-Plattformen

RustDesk ist im ersten Halbjahr 2026 mehrfach negativ in den Schlagzeilen gewesen: ein Botnet, das den öffentlichen Server missbraucht, ein erzwungener Login am Demo-Server, ein Malwarebytes-Bericht über gefälschte Installer und die fortbestehende Abwesenheit aus dem Google Play Store. Das klingt zunächst nach einem Argument gegen RustDesk. Bei genauer Betrachtung ist es das Gegenteil: Fast jeder dieser Vorfälle betrifft den öffentlichen RustDesk-Server und fremde Download-Quellen - nicht die Software selbst. Und genau hier setzt die richtige Konsequenz an: RustDesk selbst hosten, bevor man ihm vertraut.

Dieser Beitrag ordnet die Vorfälle datiert und nüchtern ein, erklärt die Architektur aus ID-Server (hbbs) und Relay-Server (hbbr) und zeigt, warum ein eigener RustDesk-Server die souveräne, DSGVO-konforme Alternative zu TeamViewer und AnyDesk ist - wenn man ihn richtig betreibt.

Inhaltsverzeichnis

• Was Mitte 2026 bei RustDesk passiert ist
• Der Kern: der öffentliche RustDesk-Server
• Warum Self-Hosting die richtige Antwort ist
• So funktioniert ein eigener RustDesk-Server
• RustDesk vs. TeamViewer und AnyDesk
• DSGVO und NIS2: was Self-Hosting für Compliance bedeutet
• Checkliste: RustDesk sicher self-hosten
• Unser Vorgehen bei WZ-IT
• Weiterführende Guides

Was Mitte 2026 bei RustDesk passiert ist

Vier Ereignisse gehören zusammengenommen ins Bild, jedes einzeln eingeordnet:

Der "Go Client"-Botnet-Ansturm (Ende Januar 2026). Sicherheitsforscher berichteten von einer automatisierten Kampagne, bei der ein Botnet den öffentlichen RustDesk-Rendezvous-Server systematisch mit Verbindungsanfragen flutete. Betroffene Nutzer sahen eingehende Anfragen von einem Client mit der Bezeichnung "Go Client", der zufällige RustDesk-IDs durchprobierte. Das ist ein Missbrauch der öffentlichen Vermittlungs-Infrastruktur, nicht eine Schwachstelle im RustDesk-Client.

Der Malwarebytes-Bericht (14. Januar 2026). Malwarebytes dokumentierte eine Kampagne über die gefälschte Domain rustdesk[.]work (nicht das offizielle rustdesk.com). Der dort angebotene Installer installierte tatsächlich ein funktionierendes RustDesk - und schob im Hintergrund das Backdoor-Framework Winos4.0 nach. Der Trick: Funktionierende Software entfernt das auffälligste Warnsignal, nämlich kaputte Funktionalität. Auch das ist kein RustDesk-Bug, sondern ein Lieferketten- und Vertrauensangriff über eine manipulierte Download-Quelle.

Der erzwungene Login am öffentlichen Server. Laut dem RustDesk-Wiki (Stand April 2026) müssen sich Controller am öffentlichen Server inzwischen kostenlos per Google- oder GitHub-Konto anmelden - mit der Begründung "aufgrund von anhaltendem Scamming und Botnet-Missbrauch". RustDesk weist im selben Atemzug darauf hin, dass der öffentliche Server nur für Demonstration und Tests gedacht ist, nicht für produktive oder sensible Arbeit.

Die Abwesenheit aus Google Play. RustDesk wurde bereits im September 2023 aus dem Google Play Store entfernt, nachdem die App wiederholt von Betrügern für Support-Scams missbraucht worden war. Die offizielle Android-App wird seitdem über GitHub-Releases (APK) und F-Droid verteilt. Das ist ein Distributions- und Reputationsthema, kein Codeproblem.

Die jüngste stabile Version, RustDesk 1.4.8, ist am 21. Juni 2026 erschienen und setzt die reguläre Release-Kadenz fort (unter anderem Windows-ARM64-Support und Verbesserungen im Multi-Monitor-Betrieb). Dieser Beitrag ist allgemeine Information und keine Rechtsberatung.

Der Kern: der öffentliche RustDesk-Server

Alle vier Vorfälle haben einen gemeinsamen Nenner: den geteilten, öffentlichen RustDesk-Server. Wer RustDesk mit Standardeinstellungen installiert, registriert sein Gerät auf der von RustDesk betriebenen Demo-Infrastruktur. Damit erbt man drei Probleme, die nichts mit der Qualität der Software zu tun haben:

• Die eigene Geräte-ID liegt in einem gemeinsamen Pool mit Millionen anderer IDs - genau das macht das Durchprobieren durch ein Botnet überhaupt erst möglich.
• Man hängt an Verfügbarkeit, Richtlinien und neuerdings am Login-Zwang eines fremden Servers.
• Der Vermittlungs-Traffic läuft über Infrastruktur, deren Standort und Betreiber man nicht kontrolliert - ein Problem für DSGVO und für jede Lieferketten-Bewertung nach NIS2.

Die Session-Inhalte sind zwar in jedem Fall Ende-zu-Ende verschlüsselt, der Relay sieht keinen Klartext. Aber Metadaten, Erreichbarkeit und Vertrauenskette hängen am öffentlichen Server. Das ist für ein Demo-Setup in Ordnung und für produktive Fernwartung die falsche Grundlage.

Warum Self-Hosting die richtige Antwort ist

Der entscheidende Schalter ist denkbar einfach: Sie betreiben Ihren eigenen ID- und Relay-Server und tragen dessen Adresse plus Public Key in die Client-Konfiguration ein. Ab diesem Moment

• registrieren sich Ihre Geräte ausschließlich auf Ihrem Server, nicht im öffentlichen Pool - der "Go Client"-Ansturm und der Login-Zwang gehen ins Leere;
• bleiben Geräte-IDs, Verbindungszeiten und Logs im Haus, auf Infrastruktur in der EU;
• pinnen Sie über den hinterlegten Public Key den Server fest, sodass sich kein fremder Vermittler dazwischenschieben kann;
• liegt die Binär-Herkunft in Ihrer Hand: Clients und Server kommen aus den offiziellen GitHub-Releases, nicht von rustdesk[.]work.

Self-Hosting löst also exakt die drei strukturellen Probleme des öffentlichen Servers - Pool, Fremdkontrolle und Datensouveränität - und macht aus RustDesk eine echte, herstellerunabhängige TeamViewer-Alternative zum Selbst-Hosten.

So funktioniert ein eigener RustDesk-Server

RustDesk ist quelloffen, mit einem Kern in Rust und einer Oberfläche in Flutter, und die Sessions sind Ende-zu-Ende über NaCl/libsodium verschlüsselt. Der Server besteht aus zwei kleinen Diensten:

• hbbs (ID-/Rendezvous-Server) registriert Geräte, hält ihre Erreichbarkeit aktuell und vermittelt Verbindungen. Standard-Ports: TCP 21115, 21116 und 21118 sowie UDP 21116 (der API-Port 21114 ist nur in RustDesk Server Pro relevant).
• hbbr (Relay-Server) übernimmt den Datenverkehr, wenn keine direkte Peer-to-Peer-Verbindung zustande kommt. Standard-Ports: TCP 21117 und 21119.

Beide stecken im quelloffenen Paket rustdesk-server und laufen problemlos auf einer kleinen Linux-VM. Beim ersten Start erzeugt hbbs ein Schlüsselpaar (id_ed25519 / id_ed25519.pub); den öffentlichen Schlüssel tragen Sie in die Clients ein, damit nur Ihr Server akzeptiert wird. Für direkten Fernzugriff ohne separaten VPN-Tunnel ist RustDesk damit eine pragmatische Variante der Fernwartung ohne VPN-Client - alternativ lässt sich der Server zusätzlich hinter ein eigenes Overlay-Netz legen.

Wer mehr Komfort braucht (Web-Konsole, Adressbuch, LDAP/SSO, Zwei-Faktor), nutzt die kostenpflichtige Variante RustDesk Server Pro pro Gerätelizenz. Für viele Mittelständler reicht die OSS-Variante plus sauberem Betrieb.

RustDesk vs. TeamViewer und AnyDesk

Der Unterschied ist kein Feature-Vergleich, sondern ein Vertrauensmodell. TeamViewer und AnyDesk nehmen Ihnen den Betrieb ab - im Gegenzug vertrauen Sie einem geschlossenen Backend und einem fremden Server. RustDesk selbst gehostet behält die Kontrolle im Haus, verlangt dafür aber einen geordneten Betrieb.

DSGVO und NIS2: was Self-Hosting für Compliance bedeutet

Aus Datenschutzsicht ist der Schritt vom öffentlichen zum eigenen Server der Unterschied zwischen "ein Dritter vermittelt unsere Wartungssitzungen" und "die Verarbeitung findet vollständig bei uns statt". Selbst gehostet auf EU-Infrastruktur entfällt der Drittland-Transfer, es ist kein externer Auftragsverarbeiter an der Vermittlung beteiligt, und Logs und Zugriffe liegen bei Ihnen - dokumentierbar für Auskunfts- und Löschpflichten.

Für Einrichtungen im NIS2-Anwendungsbereich kommt die Lieferketten- und Zugriffsdimension hinzu: Fernwartungszugänge sind ein klassischer Angriffspfad, und Artikel 21 verlangt geeignete Maßnahmen unter anderem zu Zugriffskontrolle und Lieferkettensicherheit. Ein eigener, gehärteter RustDesk-Server mit nachvollziehbaren Zugriffslogs ist hier deutlich leichter zu begründen als ein fremder Demo-Server. Für Fernwartung an Maschinen und Anlagen, wie wir sie etwa im ABCO-Water-Projekt betreiben, ist diese Nachweisbarkeit Pflicht, nicht Kür. Dieser Beitrag ist allgemeine Information und keine Rechtsberatung.

Checkliste: RustDesk sicher self-hosten

Ein produktiver RustDesk-Server braucht mehr als einen laufenden Container:

1. Eigener hbbs/hbbr auf einer dedizierten Linux-VM in der EU, nicht der öffentliche Server.
2. Public-Key-Pinning in allen Clients, damit ausschließlich Ihr Server akzeptiert wird.
3. Binäre nur aus offizieller Quelle (GitHub-Releases / rustdesk.com), niemals von Tippfehler-Domains wie rustdesk[.]work - die Lehre aus dem Malwarebytes-Fall.
4. Firewall und Exposure minimieren: nur die nötigen Ports öffnen, Management-Zugang nur intern oder über ein Overlay-Netz.
5. Unbeaufsichtigten Zugriff absichern: starkes Permanent-Passwort, Zugriff nur für definierte Geräte, kein offener Self-Service.
6. Updates zeitnah einspielen - 1.4.8 vom 21. Juni 2026 als aktueller Stand, mit strukturiertem CVE-Monitoring.
7. Backup der Server-Schlüssel (id_ed25519) und der Konfiguration - ohne den Key verlieren alle Clients die Verbindung.
8. Zugriffslogs aufbewahren und für Audits aufbereiten.

Unser Vorgehen bei WZ-IT

Wir betreiben RustDesk im Rahmen unseres Managed-Open-Source-Portfolios als vollständig betriebenen Dienst - in drei Stufen.

Stufe 1 - Aufbau und Hardening. Eigener hbbs/hbbr auf Ihrer Infrastruktur (typisch Hetzner Cloud, netcup oder Ihr eigener Proxmox-Cluster), mit Public-Key-Pinning, minimaler Port-Exposure, Firewalling und abgesichertem Management-Zugang. Auf Wunsch hinter einem eigenen Overlay-Netz, sodass der Server nicht offen im Internet steht.

Stufe 2 - Updates und CVE-Monitoring. Über unser CVE-Monitoring verfolgen wir Releases von rustdesk/rustdesk und rustdesk/rustdesk-server sowie die einschlägigen NVD-/BSI-Feeds und spielen Updates geordnet ein - dokumentiert mit Zeitpunkt im Report.

Stufe 3 - Betrieb, Backup und Compliance. Backup der Server-Schlüssel und Konfiguration, Zugriffslogs, und auf Wunsch ein Security-Audit der gesamten Fernwartungs-Kette. Für regulierte Umgebungen liefern wir die Belege, die DSGVO- und NIS2-Nachweise erwarten. Wer den Schritt von TeamViewer/AnyDesk plant, bekommt von uns eine ehrliche Migrations- und Betriebsbewertung - inklusive der Frage, ob die OSS- oder die Pro-Variante passt.

Weiterführende Guides

• RustDesk - vollständig betrieben auf Ihrer Infrastruktur - Service-Übersicht und Leistungsumfang
• Remote-Management-Plattformen - das große Bild für Fernzugriff und Fernwartung
• TeamViewer-Alternative zum Selbst-Hosten - die Optionen im Vergleich
• Fernwartung ohne VPN-Client - wann direkter Zugriff sinnvoll ist
• CVE-Monitoring für Self-Hosted Software - strukturierte Reaktion auf Schwachstellen
• Security-Audit - die Fernwartungs-Kette geprüft
• Case Study: ABCO Water Systems - Fernwartung von Anlagen in der Praxis

Sie nutzen RustDesk noch über den öffentlichen Server - oder denken über den Wechsel von TeamViewer/AnyDesk nach? Wir bewerten Ihre aktuelle Fernwartung kostenfrei: Server-Setup, Hardening, Binär-Herkunft, Backup und Audit-Tauglichkeit. Output: konkrete Empfehlung mit Priorisierung oder direkte Übernahme als Managed Service.

Kostenloses Erstgespräch buchen · Mehr zu RustDesk · Remote-Management-Plattformen

Quellen

• Malwarebytes: How real software downloads can hide remote backdoors (14.01.2026)
• RustDesk Security Alert: "Go Client" botnet attack (GitHub Discussion #14167)
• Daily CyberSecurity: The "Go Client" Trap - RustDesk under automated botnet siege
• RustDesk Wiki: Login required for public server
• RustDesk 1.4.8 Release (GitHub, 21.06.2026)
• RustDesk Discussion: Availability in Google Play (#5660)
• RustDesk Docs: Self-host (hbbs / hbbr)
• RustDesk Docs: RustDesk Server OSS