Wenn sich bei dir irgendjemand „von zu Hause über die IP-Nummer" auf einen Bürorechner einloggt — also jemand aus der IT hat irgendwann Port 3389 am Router geöffnet — dann hast du keinen Fernzugriff. Du hast eine zwei Jahre im Voraus verschickte Einladung an die Ransomware.
Das ist keine Angstmacherei. Das ist eine Statistik, die wir bei Kunden alle paar Monate sehen. RDP auf einer öffentlichen IP ist seit Jahren der Einstiegsvektor Nummer eins bei Angriffen auf polnische KMU. Nicht Phishing, nicht ein USB-Stick — RDP. Und nicht, weil jemand das Passwort Sommer2024! nutzt. Einfach, weil ganze Schwärme von Bots rund um die Uhr das Internet nach offenem Port 3389 absuchen und dort jede jemals geleakte Zugangskombination ausprobieren.
In diesem Artikel geht es darum, wie sinnvoller Fernzugriff heute in einer Firma mit 10–50 Personen aussieht. Ohne Enterprise-Übertreibung, ohne das Risiko kleinzureden.
Wie das öffentliche RDP entstanden ist
Das Muster ist fast immer dasselbe. Das Unternehmen hat vor 10–15 Jahren einen Dell- oder HP-Server gekauft, Windows Server darauf installiert, ein ERP eingerichtet (meistens Comarch Optima oder Subiekt GT, manchmal ein älteres enova). Ein paar Leute aus Buchhaltung und Vertrieb melden sich per RDP an. Jahrelang läuft das.
Dann kommt Corona oder das erste Kind eines Verkäufers, und plötzlich müssen Leute von zu Hause arbeiten. Der IT-ler — intern oder extern — fragt nach dem Budget, hört „minimal", öffnet also Port 3389 am Router und zeigt, wie man firmenname.dyndns.org:3389 in den RDP-Client tippt. Alles funktioniert. Drei Jahre lang funktioniert alles.
Bis an einem Samstagmorgen niemand mehr eine Datei öffnen kann, weil alle Dateien jetzt auf .lockbit3 oder .akira enden. Der Pflichtweg dann sind Backups (falls vorhanden) und fünf Tage Stillstand.
Was hier wirklich falsch läuft
Das Problem ist nicht, dass RDP ein schlechtes Protokoll wäre. Microsoft pflegt es aktiv, es ist verschlüsselt. Das Problem sind drei Dinge:
- Die Anmeldesitzung liegt öffentlich. Jeder Bot der Welt kann probieren, sich einzuloggen. Selbst wenn du lange Passwörter hast und Konten nach 10 Versuchen sperrst, umgehen Credential-Stuffing-Angriffe (aus anderen Diensten geleakte Zugangsdaten) solche Schranken zuverlässig.
- Direkter Zugang zur Betriebssystemebene. Sobald sich ein Angreifer einloggt, sitzt er auf dem Server, auf dem ERP, Datenbank und Dateifreigaben laufen. Es gibt keine Zwischenschicht, die seine seitliche Bewegung im Netz verlangsamen würde.
- Kein MFA als Standard. Pures RDP fordert keinen zweiten Faktor. Man kann ihn nachrüsten (Duo, Azure MFA für RDP), aber in 9 von 10 Kundenumgebungen, die wir sehen, ist er nicht nachgerüstet.
Im Vergleich — wenn sich jemand über ein vernünftiges VPN oder ZTNA anmeldet, muss er sich zuerst gegen ein Gateway authentifizieren (mit MFA), und erst danach sieht er irgendetwas aus dem internen Netz. Das sind zwei völlig unterschiedliche Risikoklassen.
Drei Wege, die für KMU Sinn ergeben
Es gibt keine eine richtige Lösung. Es gibt drei, mit unterschiedlichem Kosten-, Komplexitäts- und Komfortprofil.
Weg 1 — klassisches VPN am Router/Firewall. Meistens WireGuard oder OpenVPN auf einem ordentlichen Edge-Router (Mikrotik, Fortigate, Sophos, pfSense, OPNsense). Der Nutzer verbindet den VPN-Client, bekommt eine interne IP, arbeitet, „als säße er im Büro". Günstig, bewährt, vollständig in deiner Kontrolle. Erfordert Disziplin beim Verwalten von Konten und Schlüsseln — vor allem beim Austritt von Mitarbeitenden.
Weg 2 — ZTNA / Mesh-VPN (Tailscale, Cloudflare WARP, Twingate). Ein neueres Vorgehen, bei dem du gar keinen Port nach außen öffnest. Jedes Gerät verbindet sich nach außen zum Anbieter, authentifiziert sich über deine Firmenidentität (Microsoft 365 / Google Workspace), und bekommt erst dann Zugriff auf konkrete Ressourcen. Konfiguration einfacher als klassisches VPN, MFA „gratis" über den IdP. Kosten typischerweise 5–8 USD pro Nutzer und Monat.
Weg 3 — RD Gateway + MFA. Wenn du aus verschiedenen Gründen bei RDP bleiben musst (z. B. eine Legacy-Anwendung verlangt eine bestimmte Sitzungseinstellung), stell ein Remote Desktop Gateway vor den Server und erzwinge MFA. Port 3389 bleibt zu, Nutzer verbinden sich auf Port 443 mit TLS-Zertifikat. Das ist das Mindestmaß an Anstand, wenn RDP bleiben muss.
In der überwiegenden Mehrheit der 10–50-Personen-Firmen, die wir heute neu aufbauen, gehen wir Weg 2 oder Weg 1. Weg 3 ergibt vor allem dort Sinn, wo bestehende Infrastruktur bleiben muss und die Änderung punktuell sein soll.
Ein Beispiel aus der Praxis
Bei einem unserer Kunden — einem 28-köpfigen Elektrogroßhändler mit Comarch Optima und ein paar Lagerapplikationen — war die Ausgangslage lehrbuchhaft. Server im Schrank unter der Treppe, Port 3389 offen mit dyndns-Namen, zehn Leute melden sich „freitags von zu Hause" an, Passwörter zuletzt 2021 geändert.
Nach dem Einbruch (LockBit, Wochenende, alles verschlüsselt) dauerte die Wiederherstellung 6 Tage, davon hatte die Firma die ersten 36 Stunden überhaupt keine Klarheit, ob das Backup brauchbar ist — die Kopien wurden lokal auf eine zweite Platte desselben Servers gemacht, die Offsite-Kopie lag auf einem NAS am gleichen Standort, das die Angreifer ebenfalls verschlüsselt hatten. Die direkten Verluste (entgangene Margen, Arbeit, Wiederherstellung, ein verlorener Kunde) lagen bei rund 180.000 PLN.
Der Umbau nach dem Vorfall kostete weniger. Port 3389 schließen, Tailscale mit Authentifizierung über Microsoft 365 und erzwungenem MFA aufsetzen, Backup nach 3-2-1 mit einer immutablen Offsite-Kopie — das ganze Paket lag bei 17.000 PLN Projektarbeit plus rund 6.000 PLN Abo-Kosten im ersten Jahr. Umsetzungszeit: 9 Arbeitstage, davon eine Woche fließender Umzug der Nutzer auf den neuen Anmeldeweg.
Das hätte man ein Jahr früher machen können. Es hätte sich auch gerechnet — nur ohne Lernen durch Schmerz.
Was du konkret nächste Woche tun kannst
Egal welchen Weg du am Ende wählst, diese Schritte kannst du sofort gehen:
- Inventarisiere, was nach außen exponiert ist. Prüf von außen (z. B.
shodan.ioauf der öffentlichen Firmen-IP oder ein einfacher Portscan), ob 3389, 5900 (VNC), 22 (SSH) leuchten. Wenn ja — schalt das heute Abend ab. - Halt fest, wer sich wie remote anmeldet. Hast du eine Liste? Weißt du, was sie tatsächlich tun — nur die Büroanwendung? Eine Datei? Den ganzen Server? Das ist der erste Schritt zu sinnvoller Einschränkung.
- Aktiviere MFA überall, wo es geht. Microsoft 365, Google Workspace, Cloud-ERP, Bank. Das sind 80% Schutz für 5% Kosten.
- Prüf das Backup richtig — durch eine Wiederherstellung, nicht durch ein grünes Icon. Wenn du nie ein Dokument aus dem Backup zurückgespielt hast, weißt du nicht, ob du eines hast.
Wenn das nach dem Gespräch klingt, das du lieber vorher als nachher führen würdest, können wir es in einem dreißigminütigen Termin beginnen — ohne Versprechen, dass du „etwas bei uns kaufst".
RDP auf einer öffentlichen IP ist heute keine „sparsame Lösung". Es ist eine Schuld, die du früher oder später in einem sehr ungelegenen Moment begleichst.