Remote Desktop Gateway nur über Port 3391 und VPN

[Horstenberg 13]

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 11. Juni 2019 von Horstenberg
Fehlerkorrektur

[daabm 1.366]

Ich bin dafür Je weniger Zugangswege es gibt, um so einfacher sind sie zu überwachen und abzusichern. Und RDP direkt im Internet war noch nie eine gute Idee. Außer Du erzwingst auch da ein Clientzertifikat. Aber bei der letzten Lücke hätte m.W. nicht mal das geholfen.

[xrated2 15]

OT: hat jemand Macros bei Non VL deaktivieren können?

siehe https://www.windowspro.de/wolfgang-sommergut/makros-office-2016-2019-einschraenken-blockieren-gruppenrichtlinien

[Nobbyaushb 1.484]

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

 

Dicht und gut.

[Horstenberg 13]

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:

OT: hat jemand Macros bei Non VL deaktivieren können?

siehe https://www.windowspro.de/wolfgang-sommergut/makros-office-2016-2019-einschraenken-blockieren-gruppenrichtlinien

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.

[Nobbyaushb 1.484]

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.

[xrated2 15]

vor 18 Minuten schrieb Horstenberg:

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.

 

Offiziell nicht, siehe Kommentar dort

[Horstenberg 13]

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 12. Juni 2019 von Horstenberg

[xrated2 15]

Na Super.

Also über Registry kann man die wenigstens noch vollständig verbieten?

[Horstenberg 13]

vor 1 Minute schrieb xrated2:

Na Super.

Also über Registry kann man die wenigstens noch vollständig verbieten?

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

[xrated2 15]

Könnte man die nicht einfach selbst signieren?

[Sunny61 809]

vor 1 Stunde schrieb Horstenberg:

Ich will nach dem Motto vorgehen: Never change a running system.

Das ist eine schlechte Idee. https://www.faq-o-matic.net/2008/02/20/never-change-a-running-system-bullshit/

 

[NorbertFe 2.089]

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. ;)

[Horstenberg 13]

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:

Das ist eine schlechte Idee. https://www.faq-o-matic.net/2008/02/20/never-change-a-running-system-bullshit/

 

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 12. Juni 2019 von Horstenberg

[tesso 375]

Wozu brauchst du von intern das RDP-GW?