RDS und AVD sicher veröffentlichen: Schluss mit offenen 3389-Scheunentoren

RDP sicher über die Firewall veröffentlichen — die Frage klingt harmlos, aber dahinter steht die wichtigste Einzelentscheidung der Remote-Access-Sicherheit, und die Kurzantwort vorab: Ein offener Port 3389 im Internet ist keine Option, in keiner Variante, auch nicht »nur vorübergehend« und auch nicht auf 3390 verschoben — offenes RDP ist seit Jahren die Ransomware-Eintrittskarte Nummer eins. Die gute Nachricht: Es gibt drei erwachsene Wege, die alle ohne exponierten 3389 auskommen. Option eins ist das RD-Gateway hinter der XGS — RDP im HTTPS-Mantel, funktioniert mit jedem Client. Option zwei ist Sophos ZTNA — kein exponierter Dienst, Identität und Gerätezustand vor jedem Paket. Option drei ist Azure Virtual Desktop — der Desktop zieht in die Cloud, und dank Reverse Connect braucht nirgends ein eingehender Port offen zu sein. Dieser Artikel stellt die drei Architekturen gegenüber, zeigt die jeweilige XGS-Konfiguration, die flankierende Härtung — und liefert die Entscheidungshilfe, welcher Weg zu welchem Szenario passt.

Warum Port 3389 im Internet ein Totalschaden ist

Zuerst die unbequeme Bestandsaufnahme, denn »wir haben da noch eine RDP-Freigabe« ist in Mittelstands-Audits erschreckend häufig. Ein offener 3389 ist kein Risiko im Sinne von »könnte mal schiefgehen«, sondern ein laufender Prozess mit vorhersagbarem Ende, und die Angriffskette in der Skizze zeigt ihn Stufe für Stufe: Internet-weite Scanner finden den Dienst binnen Minuten — und zwar am Antwortverhalten des Protokolls, nicht an der Portnummer, weshalb der beliebte Umzug auf 3390 exakt nichts bringt. Danach beginnt der Dauerbeschuss: Brute-Force und Password-Spraying rund um die Uhr, gern gefüttert mit Kombinationen aus alten Datenlecks. Irgendwann kommt der eine Treffer — ein schwaches oder wiederverwendetes Passwort genügt, denn nacktes RDP kennt keine MFA. Ab dann hat jemand interaktiven Zugriff auf ein Domänen-System und Zeit: Rechteausweitung, Kontenklau, Seitwärtsbewegung, Backup-Sabotage. Das Finale kennt jeder aus den Schlagzeilen; was danach zu tun ist, behandelt der Incident-Response-Artikel — besser ist, nie dort anzukommen.

Skizze 1: Vom Minuten-Scan zur Ransomware — und wo die drei Architekturen dieses Artikels die Kette brechen: kein exponierter Dienst, MFA vor dem Treffer.

Option 1: RD-Gateway hinter der XGS veröffentlichen

Das Remote-Desktop-Gateway ist der klassische Weg und hat einen unschlagbaren Vorteil: Es funktioniert mit jedem RDP-Client, ohne Agent — auch für den Dienstleister mit dem unverwalteten Notebook. Das Prinzip: Der Client verpackt sein RDP in HTTPS und spricht das Gateway auf 443 an (plus optional UDP 3391 für bessere Performance); das Gateway packt aus, prüft seine Richtlinien und reicht intern auf 3389 weiter — der nackte RDP-Port existiert nur noch im LAN. Die XGS-Konfiguration dazu: das Gateway in eine eigene Zone (DMZ), eine DNAT-Regel für 443 (und bei Bedarf UDP 3391) auf das Gateway, davor Geo-Filter und IPS auf der Regel, und ein öffentliches Zertifikat auf dem Gateway-FQDN. Im Gateway selbst leisten die Verbindungs- und Ressourcenrichtlinien die Feinarbeit: welche Benutzergruppen sich überhaupt verbinden dürfen (CAP) und welche Zielsysteme sie erreichen (RAP) — niemals »alle auf alles«.

Der entscheidende Baustein ist die MFA, denn ein Gateway ohne zweiten Faktor verschiebt das Passwort-Problem nur um eine Schicht: Der bewährte Weg führt über einen NPS mit der Entra-MFA-Erweiterung — das Gateway fragt den NPS, der die Microsoft-Authenticator-Bestätigung einholt, bevor die Verbindung zustande kommt; die Mechanik ist dieselbe RADIUS-Konstruktion wie bei der VPN-MFA aus dem Cluster, mit denselben Eigenheiten (keine Conditional-Access-Auswertung auf diesem Pfad). Die ehrliche Einordnung: Das RD-Gateway ist ein exponierter Windows-Dienst — er will gepatcht, überwacht und eng gehalten werden. Dafür ist er der einzige der drei Wege, der wirklich jedes Fremdgerät bedient.

Option 2: Zugriff über Sophos ZTNA

Der zweite Weg dreht die Logik um: Statt einen Dienst zu exponieren und Ankömmlinge zu prüfen, wird zuerst geprüft und erst dann verbunden. Sophos ZTNA vermittelt RDP als einzelne Anwendung: Der Agent — als Bestandteil von Intercept X ohnehin auf verwalteten Geräten — meldet den Benutzer gegen Entra ID an (inklusive MFA und Conditional Access), prüft den Gerätezustand, und erst nach bestandener Prüfung stellt das ZTNA-Gateway auf der XGS die Verbindung zum Terminalserver her. Von außen existiert kein ansprechbarer RDP-Dienst — nichts zu scannen, nichts zu beschießen; der Zugriff gilt exakt einer Anwendung statt einem Netz, was die Seitwärtsbewegung im Kompromittierungsfall gleich mit erschwert. Die XGS-Seite ist erfreulich schlank: Das ZTNA-Gateway läuft als kostenfreie Funktion auf der Firewall, die RDP-Ziele werden als Ressourcen definiert und Entra-Gruppen zugeordnet. Die Grundlagen — Funktionsweise, Lizenzbedarf für die Agents, Abgrenzung zu Conditional Access und die schrittweise VPN-Ablösung — stehen im ZTNA-Artikel [LINK: B3]; hier zählt die Anwendung auf den RDP-Fall.

Die Grenze der Option ist ihre Voraussetzung: ZTNA braucht den Agenten, und der Agent braucht ein verwaltetes Gerät. Für die eigene Belegschaft mit Intercept X ist das die eleganteste Lösung des ganzen Artikels — für den externen Wartungstechniker mit Firmenfremd-Notebook ist sie ungeeignet, und genau deshalb endet dieser Artikel nicht nach Option zwei: Der Dienstleister-Fall bekommt in der FAQ eine eigene Antwort, und in der Praxis läuft es meist auf eine Kombination hinaus, wie die Entscheidungshilfe zeigt.

Option 3: AVD — was die Firewall dafür braucht

Der dritte Weg verlegt die Desktops gleich ganz: Bei Azure Virtual Desktop laufen die Session-Hosts in Azure, und die Verbindungslogik ist das eigentliche Sicherheits-Kunststück — der Faktenkasten bringt sie auf den Satz. Für die XGS bedeutet das eine fast schon enttäuschend kurze Aufgabenliste: Es gibt schlicht keine eingehende Freigabe zu konfigurieren — weder on-prem noch in Azure zeigt ein RDP-Port ins Internet. Was die Firewall braucht, ist ausschließlich ausgehender HTTPS-Verkehr der Clients zu den AVD- und Anmelde-Endpunkten (Tabelle), idealerweise als gepflegte FQDN-Gruppe von der TLS-Inspection ausgenommen — Anmeldeverkehr und Desktop-Streaming vertragen keinen Mittelsmann. Optional, aber für die Benutzererfahrung lohnend: RDP Shortpath, das den Desktop-Verkehr von TCP auf UDP hebt (Hinweis-Kasten). Und wenn die AVD-Desktops auf On-Prem-Ressourcen zugreifen sollen — Dateiserver, Drucker, Legacy-Anwendungen —, läuft das über den Site-to-Site-Tunnel aus [LINK: B6]: Die Session-Hosts kommen dann als ganz normale Azure-Teilnehmer durchs VNet ins Firmennetz, mit Firewall-Regeln wie für jedes andere Segment.

Absicherung flankierend: MFA, Geo und IPS

Egal welcher Weg gewinnt — drei flankierende Schichten gehören immer dazu, und alle drei sind auf der XGS schnell gebaut. Erstens MFA als nicht verhandelbare Grundregel: kein Remote-Desktop-Zugriff ohne zweiten Faktor, egal ob per NPS-Erweiterung am RD-Gateway oder nativ über Entra bei ZTNA und AVD — die Angriffskette aus Kapitel eins bricht genau an dieser Stelle. Zweitens die Reduktion der Angriffsfläche beim exponierten Weg: Die Publishing-Regel des RD-Gateways bekommt einen eingehenden Geo-Filter (wenn die Techniker nur aus DACH zugreifen, muss der Rest der Welt die Tür gar nicht erst sehen — die Feinheiten samt Ausnahmen-Fallen stehen in [LINK: A5]), dazu ein IPS-Profil auf der Regel, das die einschlägigen Angriffsmuster auf exponierte Dienste abdeckt. Drittens die Sichtbarkeit: Fehlanmeldungen am Gateway und verworfene Zugriffsversuche gehören protokolliert und ausgewertet — wer die Sentinel-Anbindung aus dem Cluster betreibt, hat mit einer Brute-Force-Erkennung auf Gateway-Anmeldungen in Minuten eine passende Detektion gebaut. Und die vierte Schicht für den Fall der Fälle: Terminalserver ins eigene Segment mit engen Regeln Richtung Rest-LAN — eine kompromittierte Sitzung soll in einem kleinen Zimmer aufwachen, nicht in der ganzen Wohnung.

Entscheidungshilfe nach Szenario

Bleibt die Frage: Welcher Weg für wen? Der Entscheidungsbaum in der Skizze sortiert sie über zwei Fragen. Frage eins: Wo sollen die Desktops laufen? Wer ohnehin neu baut, Standorte eröffnet oder die Terminalserver-Hardware am Lebensende hat, sollte AVD ernsthaft rechnen — die Sicherheitsarchitektur ist konkurrenzlos, der Preis sind laufende Azure-Kosten statt abgeschriebener Blechserver. Frage zwei, für den On-Prem-Bestand: Wer greift zu? Ausschließlich eigene, verwaltete Geräte mit Intercept X → Sophos ZTNA, die eleganteste Lösung ohne exponierten Dienst. Auch Fremdgeräte und Dienstleister → RD-Gateway mit NPS-MFA, der einzige Agent-lose Weg. Die Vergleichstabelle stellt die drei Optionen den Kriterien gegenüber — und die ehrliche Realität steht unter dem Baum: Meist wird es eine Kombination, etwa ZTNA für die Belegschaft plus ein eng gehaltenes Gateway für die zwei externen Wartungszugänge. Entscheidend ist nur der gemeinsame Nenner: Kein Weg endet an einem offenen 3389.

Skizze 2: Zwei Fragen sortieren die drei Wege — und die Realität ist meist eine Kombination mit einem gemeinsamen Nenner.

FAQ — häufige Fragen zur sicheren RDP-Veröffentlichung

Wie veröffentliche ich RDP sicher über die Sophos XGS?

Die kurze Antwort: gar nicht direkt — sondern über eine der drei Architekturen, bei denen der Port 3389 nie ins Internet zeigt. Weg eins: ein RD-Gateway in der DMZ, per DNAT auf 443 veröffentlicht (plus optional UDP 3391), mit öffentlichem Zertifikat, MFA über die NPS-Erweiterung, Geo-Filter und IPS auf der Publishing-Regel — der richtige Weg, wenn auch unverwaltete Fremdgeräte zugreifen müssen. Weg zwei: Sophos ZTNA, bei dem der Agent in Intercept X den Benutzer erst gegen Entra ID authentifiziert (MFA, Conditional Access, Gerätezustand) und das ZTNA-Gateway auf der XGS danach exakt die eine RDP-Verbindung vermittelt — kein exponierter Dienst, die eleganteste Lösung für verwaltete Geräte. Weg drei: Azure Virtual Desktop — dank Reverse Connect existiert keine eingehende Freigabe, die XGS lässt nur ausgehenden HTTPS-Verkehr zu den AVD-Endpunkten durch. Was in keiner Variante vorkommt: eine DNAT-Regel mit Ziel 3389 und Quelle Internet — die ist keine Veröffentlichung, sondern eine Einladung.

Reicht ein geänderter Port als Schutz?

Nein — und zwar nicht als Meinungsfrage, sondern messbar. Der Gedanke hinter dem Port-Umzug stammt aus einer Zeit, in der Scanner stumpf Portlisten abklapperten; moderne Internet-Scanner arbeiten anders: Sie sprechen jeden offenen Port an und identifizieren den Dienst an seinem Protokoll-Handshake — RDP verrät sich durch sein Antwortverhalten, völlig egal, ob es auf 3389, 3390 oder 53211 lauscht. Suchmaschinen für Internet-Dienste führen entsprechend RDP-Endpunkte auf allen erdenklichen Ports, und der Beschuss beginnt nach der Entdeckung genauso zuverlässig wie auf dem Standardport — allenfalls ein paar Stunden später. Was der Umzug real kostet: Sonderkonfiguration in jedem Client, Stolperfallen bei jeder Fehlersuche, ein falsches Sicherheitsgefühl. Dasselbe Urteil trifft die verwandten Hausmittel — die »unbekannte« IP ohne DNS-Eintrag und die veraltete Quell-IP-Beschränkung. Die Energie gehört in eine der drei Architekturen dieses Artikels; jede macht den Port-Umzug gegenstandslos, weil es keinen zu versteckenden Port mehr gibt.

Welche Ports braucht Azure Virtual Desktop?

Auf der Firewall der Client-Seite — also der XGS — ausschließlich ausgehende Freigaben, und die Liste ist kurz: TCP 443 zu den AVD-Dienstendpunkten (*.wvd.microsoft.com), zu den Entra-Anmeldeendpunkten (login.microsoftonline.com und Verwandte) und zu den Vermittlungsdiensten (*.servicebus.windows.net) — sinnvollerweise als gepflegte FQDN-Gruppe, ausgenommen von der TLS-Inspection. Dazu optional, aber empfohlen: die ausgehenden UDP-Freigaben für RDP Shortpath (UDP 3478 zu den Microsoft-Vermittlungsdiensten plus hohe ausgehende UDP-Ports), damit der Sitzungsverkehr statt über TCP über das flüssigere UDP laufen kann — blockiert fällt er stumm auf TCP zurück, was funktioniert, aber zäher wirkt. Eingehende Freigaben: keine, nirgends — das ist der Kern des Reverse-Connect-Modells, bei dem Client wie Session-Host sich ausgehend beim Dienst melden. Die Endpunktlisten der Session-Hosts gelten Azure-seitig im VNet; an der XGS werden sie nur relevant, wenn die Hosts über den Site-to-Site-Tunnel auf On-Prem-Ressourcen zugreifen — dann gelten normale Segment-Regeln.

Ist ZTNA für RDP-Zugriff geeignet?

Ja — für verwaltete Geräte ist es sogar die eleganteste der drei Optionen. RDP ist als klassische TCP-Anwendung ein dankbarer ZTNA-Kandidat: Der Terminalserver wird als Ressource definiert, einer Entra-Gruppe zugeordnet, und der Agent stellt die Verbindung erst her, nachdem Benutzer (MFA, Conditional Access) und Gerät (Zustandsprüfung) bestanden haben — von außen existiert kein ansprechbarer Dienst, und der Zugriff gilt genau dieser einen Anwendung statt dem Netz dahinter, was im Kompromittierungsfall die Seitwärtsbewegung gleich mit ausbremst. Auf der XGS läuft das Gateway als kostenfreie Funktion mit; die Agents kommen mit Intercept X aufs Gerät. Zwei ehrliche Grenzen: Erstens die Voraussetzung — ohne verwaltetes Gerät mit Agent kein Zugriff, weshalb Dienstleister-Szenarien einen anderen Weg brauchen. Zweitens die Betriebsdisziplin: Die Erreichbarkeit hängt an Agent, Identitätsdienst und Gateway — ein Break-Glass-Konzept für den administrativen Notzugriff gehört dazu. Funktionsweise, Lizenzdetails und Migrationsstrategie stehen im ZTNA-Artikel des Clusters.

Wie erzwinge ich MFA vor dem RDP-Zugriff?

Je nach Architektur auf einem von drei Wegen — gemeinsam ist allen: Die MFA passiert vor dem Verbindungsaufbau, nicht irgendwo dahinter. Beim RD-Gateway läuft es über RADIUS: Das Gateway fragt einen NPS-Server, auf dem die Entra-MFA-Erweiterung installiert ist — der Benutzer bestätigt in der Authenticator-App, erst dann kommt die Verbindung zustande; die Konstruktion entspricht der VPN-MFA-Mechanik aus dem Cluster, inklusive ihrer Eigenheit, dass auf diesem Pfad kein Conditional Access ausgewertet wird. Bei ZTNA und AVD ist die MFA nativer Bestandteil der Entra-Anmeldung, die ohnehin vor jedem Zugriff steht — inklusive Conditional Access, sodass sich Regeln wie »nur von konformen Geräten« oder »kein Zugriff aus bestimmten Regionen« gleich mit durchsetzen lassen. Was ausdrücklich nicht als MFA-Ersatz taugt: die reine Netzwerkebenen-Authentifizierung (NLA) von RDP — sie verhindert nur den Sitzungsaufbau vor der Anmeldung, prüft aber weiterhin bloß Benutzername und Passwort. Und auch interne administrative RDP-Zugriffe profitieren von einem zweiten Faktor — Angreifer nutzen RDP nach dem Erstzugriff intern genauso gern wie von außen.

Was tun mit Dienstleister-Zugängen?

Dienstleister sind der Härtetest jeder Remote-Access-Architektur: fremde, unverwaltete Geräte, unregelmäßiger Bedarf, und historisch die Quelle der schlimmsten »temporären« Freigaben. Das tragfähige Muster hat vier Bausteine. Erstens der Weg: ein RD-Gateway mit NPS-MFA — der einzige Agent-lose Pfad — oder, wo der Dienstleister mitspielt, ein Entra-Gastkonto mit eigenem MFA-Faktor für ZTNA- oder AVD-Zugriff. Zweitens die Identität: personalisierte Konten je Techniker statt des ewigen Sammelkontos »wartung« — sonst ist im Log niemand verantwortlich und beim Personalwechsel des Dienstleisters niemand ausgesperrt. Drittens die Begrenzung: Zugriff nur auf die tatsächlich betreuten Systeme (RAP-Richtlinien beziehungsweise ZTNA-Ressourcen), zeitlich befristet oder auf Anforderung freigeschaltet statt dauerhaft offen, flankiert vom Geo-Filter. Viertens die Nachvollziehbarkeit: Anmeldungen und Sitzungen protokollieren, bei kritischen Systemen mit Aufzeichnung — auch als Absicherung für den Dienstleister selbst. Und die Gegenprobe für den Bestand: Jede Freigabe, die auf einer IP-Beschränkung von vor zwei Jahren ruht, gehört auf die Prüfliste — die Praxis-Geschichte oben erzählt, warum.

Fazit: Drei erwachsene Wege — und keiner endet auf 3389

Die Remote-Desktop-Frage hat 2026 keine Ausreden mehr: Offenes RDP wird binnen Minuten gefunden und dauerhaft beschossen, der Port-Umzug ist ein Umzugsschild, und die veraltete IP-Beschränkung ein Zeitzünder. Die drei erwachsenen Wege sind sauber sortiert — das RD-Gateway hinter der XGS als Agent-loser Klassiker für gemischte Gerätewelten (mit NPS-MFA, Geo-Filter und IPS als Pflichtzubehör), Sophos ZTNA als elegantester Weg für die verwaltete Belegschaft ohne jeden exponierten Dienst, und AVD als architektonische Abschaffung des Problems dank Reverse Connect. Meist wird es eine Kombination, und das ist völlig in Ordnung — solange der gemeinsame Nenner steht: MFA vor jeder Verbindung, Terminalserver im eigenen Segment, Protokolle mit Auswertung, und nirgends ein 3389 Richtung Internet. Wer heute noch so eine Zeile im Regelwerk hat, weiß jetzt, was zu tun ist — idealerweise vor dem Review, nicht durch ihn.

Von hier aus weiter im Cluster: Das Gesamtbild der XGS in Microsoft-Umgebungen zeichnet der Pillar-Artikel [LINK: Pillar]. Funktionsweise, Lizenzen und Migrationsstrategie von Sophos ZTNA vertieft [LINK: B3]. Den eingehenden Geo-Filter samt seiner Ausnahmen-Fallen erklärt [LINK: A5]. Und was zu tun ist, wenn die Angriffskette doch einmal durchläuft — Isolation, Meldepflichten, Wiederanlauf —, steht im Incident-Response-Artikel [LINK: C9].