Jump to content

Remote Desktop Gateway nur über Port 3391 und VPN


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Der Bericht über den Emotet-Einbruch in das Heise-Netzwerk hat mich nachdenklich gemacht. Bislang sind wir zwar von Emotet ua. verschont geblieben, aber wenn es selbst das Netzwerk eines Computer-Nerd-Verlages derart hart treffen kann, dann ist jeder irgendwann dran.

 

Auf heise.de wurde berichtet, dass es den Emotet-Gaunern auch gelungen ist, auf noch nicht ganz geklärtem Wege an die Credentials eines Domain-Admins zu gelangen. In der Folge sind die Gauner dann manuell über Remote-Desktop-Gateway auf die Server des Unternehmens gegangen um dort gezielt Daten und Backups zu kompromitieren und zu verschlüsseln.

 

Wir haben hier nun ein Netzwerk, das wie so viele ein RemoteDesktop-Gateway bereitstellt, das über Port 443 im Netz steht. Über den Web Application Proxy auf Windows Server werden zudem der Exchange und WorkFolders veröffentlicht, auch das über Port 443. Andere Ports werden von der Firewall nicht geforwarded. Weiterhin hat das Unternehmen einen VPN-Zugang, der allerdings auf der Hardware-Firewall eingerichtet ist. Den VPN-Zugang halte ich für nahezu sicher, da er nur über direkten Zugang zur Hardware-Firewall geändert werden kann. 

 

Meine Überlegung ist nun die folgende: Ich beende die Veröffentlichung des RDP-Gateways über Port 443. Das RDP-Gateway wird nur noch veröffentlicht über Port 3391. Effekt: RDP funktioniert nur noch von außerhalb, wenn man sich vorher über das VPN ins Netzwerk einloggt.

 

So will ich erreichen, dass das RDP über Windows-Credentials plus VPN-Erfordernis faktisch eine sehr effektive Zwei-Faktor-Authentifizierung erhält. Damit habe ich natürlich nicht die Emotet-Gefahr besiegt, aber wenigstens den Alptraum beseitigt, dass Emotet-Gauner über RDP unsere Server komplett "erobern."

 

Was haltet ihr davon?

bearbeitet von Horstenberg
Fehlerkorrektur
Link zu diesem Kommentar
vor 9 Stunden schrieb Nobbyaushb:

Wenn du nur via VPN Zugang zulassen willst, warum dann nach extern veröffentlichen?

 

Dicht und gut.

Ich will nach dem Motto vorgehen: Never change a running system. Wenn ich im RDP gateway nur den "Haken" bei der Veröffentlichung über Port 443 wegnehme, scheint mir alles getan zu sein. Jeder andere Zugriff von extern scheitert ja schon an der Firewall. Oder mache ich da einen Denkfehler?

vor 10 Stunden schrieb xrated2:

Verstehe ich das richtig und sollen die in dem Artikel verlinkten GPO-Templates auch für Office-Versionen gelten, die nicht über Volume Licensing erworben wurden? Das wäre in der Tat ein  Fortschritt.

Link zu diesem Kommentar
vor 1 Minute schrieb Horstenberg:

Ich will nach dem Motto vorgehen: Never change a running system. Wenn ich im RDP gateway nur den "Haken" bei der Veröffentlichung über Port 443 wegnehme, scheint mir alles getan zu sein. Jeder andere Zugriff von extern scheitert ja schon an der Firewall. Oder mache ich da einen Denkfehler?

Nö.

Du musst den Portforward an der Firewall von der externen IP abschalten.

Ob das Gateway veröffentlicht spielt dann keine Rolle mehr.

und ggf. geht das intern auch nicht mehr, aber das kannst du besser beurteilen, dazu müsste man die Infrastruktur besser kennen.

Link zu diesem Kommentar
vor 3 Minuten schrieb xrated2:

 

Offiziell nicht, siehe Kommentar dort

Mit den GPOs, die vor ca. einem Jahr online waren, hatte ich es probiert. Die GPOs wurden von den bei uns installierten Home&Business-Office-Versionen nicht verarbeitet. Also habe ich alle Einstellungen von Hand machen müssen. 

bearbeitet von Horstenberg
Link zu diesem Kommentar
vor 1 Stunde schrieb Horstenberg:

ja, das müsste gehen. In vielen Unternehmen kannst Du das aber nicht machen, weil die auf unsignierte Makros usw. zwingend angewiesen sind. 

Nein eben nicht, weil diese Office Versionen eben die /policies Zweige nicht auswerten in denen ein User nicht schreiben darf. Also bleibt bei Office nur die registry im User hive und rate mal, wer da schreiben darf. Aber muss ja immer alles billig sein. ;)

Link zu diesem Kommentar
vor 3 Stunden schrieb NorbertFe:

Nein eben nicht, weil diese Office Versionen eben die /policies Zweige nicht auswerten in denen ein User nicht schreiben darf. Also bleibt bei Office nur die registry im User hive und rate mal, wer da schreiben darf. Aber muss ja immer alles billig sein. ;)

Ich glaube, ich verstehe Dich nicht vollständig. Wir sind auf einen Softwareanbieter angewiesen, der die gesamte Infrastruktur für die Texterstellung usw. bereitstellt und uns so auch zu bestimmten Einstellungen im Office zwingt. Einer von zwei oder drei Softwareanbietern in unserem Berufszweig, das hat nichts mit Kosten zu tun. Die anderen Anbieter sind jedenfalls meiner Meinung nach schlechter.

 

Beispiel, was vor ein paar Tagen passiert ist: Ein Update dieses Herstellers erforderte auch, dass ein lokales Update im Office eines jeden Mitarbeiters eingespielt wurde. Dafür musste "temporär" dem VBA-Projekt vertraut und die Makro-Sicherheit heruntergestellt werden. 

 

Gestern habe ich mal wieder alle Maschinen durchgeguckt: An nur einem Arbeitsplatz war dann wirklich alles wieder zurückgestellt (nur signierte Makros und VBA-Häkchen weg). Bei allen anderen Arbeitsplätzen waren die Sicherheitseinstellungen im Office katastrophal. 

 

Der Kampf um Office-Sicherheit ist in solchen Umgebungen ein Kampf gegen Windmühlen. Wenn ich das mit Geld lösen könnte, ich würde es tun. Deswegen werde ich zB beim nächsten Mal Office über eine Volumenlizenz kaufen, wegen der GPOs. Ich kaufe auch zB immer mehr Windows-Server-Lizenzen, um die einzelnen Prozesse zu isolieren, auch wenn wir nur 10 Mitarbeiter haben. 

vor 4 Stunden schrieb Sunny61:

Ok. Dann habe ich jetzt folgende Idee: Bislang ist bei uns der Web Application Proxy zusammen mit dem Remote Desktop Gateway auf einer (virtuellen) Maschine. Das ist die Maschine, auf die der Port 443 geworwarded wird.

 

Idee jetzt: Ich nehme das Remote Desktop Gateway von dieser Maschine runter. Das installiere ich dann auf einer neuen virtuellen Maschine, die dann ohne geforwardeten (?!) Port im Netz ist. Dann wäre das Remote Desktop Gateway von Außen gar nicht mehr erreichbar, sondern nur nach VPN-Login. Klingt gut?

bearbeitet von Horstenberg
Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...