RDP-Schutz ohne VPN: 5 Situationen, in denen es alternativlos ist

Wer einen aktuellen Leitfaden zum Fernzugriff liest, bekommt überall denselben Rat: RDP nicht direkt exponieren — stattdessen hinter VPN, Tailscale, Cloudflare Tunnel oder RD Gateway setzen. Der Rat ist richtig. Sowohl die Empfehlung von Microsoft als auch die StopRansomware-Checkliste der CISA sagen das.

Nur sind richtiger Rat und umsetzbarer Rat nicht immer dasselbe. Viele Admins, die das hier lesen, können ihren Mietern nicht vorschreiben, was sie nutzen. Sie können nicht in sechs Monaten einen VPN-Client an 80 wechselnde Freelancer ausrollen. Und sie sitzen vor einem Windows Server 2012 R2, auf dem der moderne VPN-Client schlicht nicht installierbar ist. Für sie lautet die Frage nicht "soll ich VPN nutzen?", sondern "wie halte ich Port 3389 offen, ohne der nächste Verizon-DBIR-Datenpunkt zu werden, in dem gestohlene Zugangsdaten 88 % der grundlegenden Web-App-Angriffe ausmachten (laut Verizon DBIR 2025)?"

Fünf Situationen folgen, in denen die VPN-Pflicht nicht auf dem Tisch liegt, und was wirksamer RDP-Schutz ohne VPN in jedem Fall bedeutet. Er ist für Sysadmins, MSPs und Hosting-Teams gedacht, die die Idealantwort kennen — und eine funktionierende Antwort für die unordentliche Realität brauchen.

Warum ist "nimm einfach ein VPN" nicht immer möglich?

Ein VPN funktioniert, wenn eine Organisation beide Enden der Verbindung kontrolliert. Sobald diese Annahme bricht, bricht das Modell mit ihr.

Hosting-Anbieter und Rechenzentren können keinen VPN-Client auf das Notebook eines Kunden zwingen. MSPs, die 50 oder mehr Kundenumgebungen betreuen, erben oft RDP-Exposition, die sie nicht entworfen haben. Freelancer kommen und gehen im Wochenrhythmus, und für jeden ein VPN-Konto zu provisionieren erzeugt mehr Angriffsfläche, als es entfernt. Auf älteren Windows-Server-Boxen — und davon laufen noch viele — ist die VPN-Client-Kompatibilität wackelig. Und wenn das VPN selbst um 2 Uhr nachts ausfällt, muss trotzdem jemand auf den Server kommen.

Der realistische Rahmen: VPN ist die beste Standardlösung, und direkter RDP-Zugriff ist das, was man absichert, wenn die Standardlösung nicht verfügbar ist. Die Zahlen sind ernüchternd. Der Active Adversary Report von Sophos führt kompromittierte Zugangsdaten und exponiertes RDP als die wichtigsten initialen Einstiegsvektoren in Incident-Response-Einsätzen. Externe Remote-Dienste waren laut Sophos in 65 % der verfolgten Incident-Response-Fälle aus 2023 beteiligt — RDP wurde in 90 % dieser Angriffe missbraucht. Der Schutz muss also echt sein, kein Theater.

Situation 1: Hoster und Rechenzentren

Ein Hoster verkauft Windows-VPS-Instanzen. Der Kunde registriert sich, bekommt RDP-Zugangsdaten und verbindet sich direkt. Es gibt kein gemeinsames Firmennetz, kein LDAP, kein zentrales VPN. Der Anbieter kann keine Client-Software auf Geräten erzwingen, die ihm nicht gehören.

Was hier funktioniert:

• Per-VM-RDP-Brute-Force-Schutz auf OS-Ebene — eine Komponente, die das Windows-Sicherheitsereignisprotokoll auf Event-ID 4625 überwacht und nach wenigen Versuchen die Quell-IP in der Windows-Firewall blockiert. Das lässt sich ins Basis-VM-Image einbauen, ohne den Workflow des Kunden zu stören.
• Geo-Blocking auf der Host-Firewall, wenn die Nutzerbasis regional ist. Wer 90 % der Quellländer abschneidet, schneidet ungefähr genauso viel automatisierten Brute-Force-Lärm ab.
• Network Level Authentication (NLA) erzwingen auf jedem Image. NLA prüft die Zugangsdaten, bevor die RDP-Sitzung vollständig aufgebaut ist, und stoppt damit die meisten Pre-Auth-Exploit-Versuche.
• Kontosperrungs-Richtlinie auf der VM selbst — typisch sind 5 fehlgeschlagene Versuche und 30 Minuten Sperre. Zusammen mit 4625-Monitoring stoppt das langsames Password Spraying, bevor es Erfolg hat.

Wenn du eine Hosting-Plattform betreibst und wissen willst, wie exponiert deine Kundenflotte aktuell ist, beschreibt der Artikel zu RDP im Internet genau das, was Angreifer beim Scan von Port 3389 sehen.

Situation 2: MSPs mit gemischten Kundenumgebungen

Der typische MSP-Albtraum: 50 Kunden, 200 Server und eine VPN-Strategie, die sich pro Kunde unterscheidet. Kunde A hat Tailscale. Kunde B eine zehn Jahre alte SonicWall. Kunde C zahlt den VPN-Posten nicht. Kunde D ist eine Vier-Mann-Zahnarztpraxis, in der die Ärztin jeden Montag um 7 Uhr beim Helpdesk anruft, damit ihr VPN-Client zurückgesetzt wird.

Eine einheitliche VPN-Einführung ist nicht immer die Entscheidung des MSP, und selbst wenn sie es ist, dauert der Rollout über das gesamte Kundenbuch oft 6 bis 12 Monate. In dieser Zeit ist RDP bei einem Teil der Kunden exponiert, und das Einbruchsrisiko trägt der MSP.

Was hier funktioniert:

• Standardisierte RDP-Härtung als Baseline — NLA an, RDP-Benutzergruppe eingeschränkt, Kontosperrung konfiguriert, Brute-Force-Schutz beim Onboarding installiert. Die Windows-Server-Sicherheits-Checkliste enthält die praxistaugliche Version dieser Liste.
• Zentrale Logweiterleitung, damit 4625-Spitzen im SIEM oder RMM des MSP innerhalb von 5 Minuten auftauchen, nicht wenn der Kunde anruft.
• Conditional Access, wo Microsoft 365 vorhanden ist — Entra-ID-Conditional-Access kann MFA für RDP-Zugriff über RD Gateway mit Azure-MFA-Integration erzwingen, ohne das bestehende VPN des Kunden zu berühren.
• Notabschalt-Playbook für Kunden, die Härtung ablehnen: schriftlich dokumentiert, vom Kunden unterschrieben, mit einer 24-Stunden-RDP-Deaktivierungsprozedur für den Tag, an dem aus einer 4625-Spitze etwas Ernsteres wird.

Das ist keine Sicherheit durch Perfektion. Das ist Sicherheit durch wiederholbare Defaults in nicht-einheitlichen Umgebungen.

Situation 3: Wie schützt man RDP für externe Freelancer und kurzzeitige Nutzer?

Freelancer sind der dritte schwierige Fall. Ein typisches mittelständisches IT-Team hat vielleicht 15 Festangestellte und 30 Freelancer, die in 6-Monats-Projekten rotieren. Jeden mit VPN-Konto, Firmen-Notebook und Offboarding-Prozedur auszustatten kostet schätzungsweise rund 1.200 US-Dollar pro Person und Jahr an Lizenz- und Verwaltungsaufwand — und am Offboarding-Schritt scheitern die meisten Organisationen. Der Verizon DBIR 2024 zeigt: Missbrauch gültiger Konten, einschließlich verwaister Zugangsdaten, war an etwa 1 von 3 Vorfällen beteiligt.

Das pragmatische Muster, wenn du nicht jedem Kurzzeitnutzer VPN-Zugang geben kannst:

• Zeitlich begrenzte RDP-Firewall-Allowlists. Eine geplante Aufgabe oder ein PowerShell-Skript öffnet Port 3389 für die IP des Freelancers für die Dauer des Projekts und schließt ihn anschließend automatisch. Im Grunde manueller Just-in-Time-Zugriff — funktioniert bei kleiner Anzahl von Freelancern.
• Pro-Nutzer-RDP-Konten, niemals geteilt. Geteilte Konten machen 4625-Forensik nahezu unbrauchbar, weil sich nicht zuordnen lässt, wessen gestohlenes Passwort gerade probiert wird.
• MFA über Duo, Entra ID oder ein Drittanbieter-RD-Gateway-Plugin. MFA für RDP ist nicht gratis in der Einrichtung — kalkuliere 4 bis 8 Stunden pro Server — entfernt aber Credential Stuffing als realistischen Angriffspfad. Microsoft gibt an, dass MFA 99,9 % der automatisierten Kontoübernahmeversuche blockiert.
• Sitzungs-Timeout: 15 Minuten Leerlauf, 8 Stunden absolut. Erzwingt erneute Authentifizierung und begrenzt den Schaden, wenn das Gerät eines Freelancers während der Sitzung kompromittiert wird.

Der Deep-Dive zu Event-ID 4625 erklärt genau, welche Felder zu beobachten sind, wenn Freelancer-Zugangsdaten in fehlgeschlagenen Anmeldungen von unerwarteten Quell-IPs auftauchen.

Situation 4: Wie sicherst du RDP auf Legacy-Windows-Server ohne VPN-Unterstützung?

Windows Server 2012 R2 hat das Ende des erweiterten Supports am 10. Oktober 2023 erreicht. Server 2016 hat den Mainstream-Support im Januar 2022 verloren. Trotzdem laufen viele dieser Maschinen produktiv — Line-of-Business-Anwendungen, an die niemand ran will, ERP-Systeme auf altem SQL Server, Maschinensteuerungen, die an spezielle Hardware gebunden sind.

Moderne VPN-Clients lassen sich darauf häufig nicht sauber installieren. Tailscale unterstützt Windows Server 2016 und neuer. WireGuard auf Server 2012 R2 ist bestenfalls inoffiziell. Selbst klassische IPSec-VPNs stolpern über Treibersignatur- und TLS-Versionskonflikte.

Für solche Umgebungen:

• Patche, was du kannst. Setze ESU (Extended Security Updates) ein, wo verfügbar. Für Server 2012 R2 läuft ESU bis Oktober 2026 — kostenlos auf Azure, oder über Azure Arc bzw. Volumenlizenzierung für On-Premises-Maschinen.
• Behandle die Maschine als zerbrechlich. Keine experimentellen Sicherheitsagenten, keine ungetesteten Kernel-Filter. Ein RDP-Brute-Force-Schutz, der rein im User-Mode läuft und das Eventlog liest, ist hier sicherer als alles, was sich in den Netzwerkstack einklinkt.
• Aggressiv segmentieren. Wenn der Legacy-Server keine ausgehende Internetverbindung braucht, blockiere ausgehenden Traffic auf der vorgelagerten Firewall. Die meisten Ransomware-Akteure brauchen ausgehenden C2-Verkehr.
• Plane die Ablösung. Legacy-Härtung ist eine Übergangslösung, kein Ziel. Dokumentiere einen Migrationsplan über 12 bis 18 Monate, auch wenn die Umsetzung sich verzögert.

Situation 5: Break-Glass und Notfallzugang

Jedes VPN-First-Design braucht eine Break-Glass-Antwort für den Fall, dass das VPN selbst das ist, was kaputtgegangen ist. Wenn die Firewall-Konfiguration korrupt ist, das Zertifikat der VPN-Appliance über Nacht abgelaufen ist oder der Cloud-VPN-Anbieter einen Ausfall hat, musst du trotzdem auf den Server kommen.

Das verbreitete Muster reifer Operations-Teams:

• Ein einziger Jump-Host mit RDP, exponiert auf eine eng begrenzte Admin-IP-Allowlist (Heim-IP, Büro-IP, statische IP des Bereitschaftsanalysten — typisch 3 bis 5 Einträge). Nicht der Produktivserver. Der Jump-Host.
• Hardware-MFA für den RDP-Login auf dem Jump-Host. YubiKey oder Äquivalent. Wenn Zugangsdaten leaken, kommt der Angreifer trotzdem nicht rein.
• Brute-Force-Schutz auf diesem Jump-Host als Sicherheitsnetz. Selbst mit Allowlist und MFA fängt 4625-Monitoring den Fall ab, in dem die Heim-IP eines Admins kompromittiert wird.
• Quartalsweise Übungen. Geh den Break-Glass-Pfad an einem geplanten Datum tatsächlich durch. Wenn du es nie getestet hast, existiert es nicht.

Das ist der eine Fall, in dem direkte RDP-Exposition eindeutig richtig ist. Der Trade-off ist anerkannt, die Angriffsfläche winzig — und das Ganze ist das Einzige, was zwischen dir und einem nächtlichen Site-Down ohne Zugangsweg steht.

Wo passt BruteFence in dieses Bild?

BruteFence ist die Schicht, die Punkt 1 in den meisten dieser Situationen erledigt: ein kleiner Windows-Agent, der Event-ID 4625 beobachtet, Brute-Force-Muster erkennt und Quell-IPs in der Windows-Firewall blockiert, bevor Zugangsdaten erraten werden. Er läuft lokal, ohne Cloud-Abhängigkeit — wichtig für Legacy-Maschinen und für Hosting-Kunden, die keine Telemetrie ihrer VM an Dritte senden möchten.

Was er nicht tut, und das sagen wir klar: Er ersetzt kein VPN, fügt kein MFA hinzu und versteckt nicht die Tatsache, dass Port 3389 offen ist. Wenn du RDP hinter Tailscale oder ein RD Gateway mit MFA stellen kannst — tu das. Es ist die stärkere Kontrolle. BruteFence ist die Schicht, die in den oben genannten Situationen, wo die stärkere Kontrolle nicht verfügbar ist, verhindert, dass aus Brute-Force-Lärm ein erfolgreicher Treffer wird.

Das größere Bild beschreibt der Artikel Wie RDP-Brute-Force-Schutz 2026 funktioniert. Für eine VPN-lose Bereitstellung willst du Defense-in-Depth: NLA an, Lockout-Policy konfiguriert, Geo-Block wo sinnvoll, Brute-Force-Monitoring aktiv — und einen echten Plan, irgendwann auf VPN-vorgelagerten Zugriff zu migrieren, sobald es die Lage erlaubt.

Die Situationen in diesem Artikel sind keine Ausreden, das Ideal zu überspringen. Sie sind das Eingeständnis, dass eine heute funktionierende, teilweise Verteidigung mehr wert ist als ein perfekter Plan, der in neun Monaten produktiv geht.

Wenn Sie sehen möchten, was auf Ihrem Server passiert, testen Sie BruteFence 7 Tage kostenlos.