6
Gefahr bei rdp (Remote Desktop Protokoll)
Welche Schwachstellen bietet rpd lokal auf dem Client?
Hallo,
folgende Situation:
Alte Struktur: Admins (ca. 20) greifen per Remote Desktop über das Netz auf einen Windows-Update-Server zu.
Bei der Umstellung / Migration kam die Anmerkung, dass rdp unsicher sei und daher nicht mehr verwendet werden sollte.
Ich denke, dass einerseits die Verbindungssicherheit seit Win2003 nicht mehr problematisch ist, dank tls.
Man sagte jedoch, dass die Gefahr sei, dass die User ihren Remote-Client mit einem anderen Server verbinden könnten. Was eine Schwachstelle sei.
Gibt es eine Möglichkeit, dass zu unterbinden?
Danke im Vorraus
folgende Situation:
Alte Struktur: Admins (ca. 20) greifen per Remote Desktop über das Netz auf einen Windows-Update-Server zu.
Bei der Umstellung / Migration kam die Anmerkung, dass rdp unsicher sei und daher nicht mehr verwendet werden sollte.
Ich denke, dass einerseits die Verbindungssicherheit seit Win2003 nicht mehr problematisch ist, dank tls.
Man sagte jedoch, dass die Gefahr sei, dass die User ihren Remote-Client mit einem anderen Server verbinden könnten. Was eine Schwachstelle sei.
Gibt es eine Möglichkeit, dass zu unterbinden?
Danke im Vorraus
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 88963
Url: https://administrator.de/contentid/88963
Printed on: April 19, 2024 at 02:04 o'clock
6 Comments
Latest comment
Wenn die User nicht in der lokalen Gruppe "Remote Desktop Users" auf dem Server drin sind, besteht keine Gefahr. Sie können dann eine Session eröffnen, werden dann beim Login eine Fehlermeldung erhalten, dass sie nicht die Berechtigungen haben, um sich auf den Server einzuloggen.
Dann empfehle ich dir, den RDP-Client per Gruppenrichtlinie zu sperren und ihn nur den lokalen Administratoren zur Verfügung zu stellen. Eine Blockade der "mstsc.exe" müsste reichen...
Man sagte jedoch, dass die Gefahr sei, dass die User ihren Remote-Client mit einem anderen Server verbinden könnten. Was eine Schwachstelle sei.
Dann empfehle ich dir, den RDP-Client per Gruppenrichtlinie zu sperren und ihn nur den lokalen Administratoren zur Verfügung zu stellen. Eine Blockade der "mstsc.exe" müsste reichen...
Danke erstmal für die schnelle Antwort.
Es ist ja so, dass Admins über remote desktop auf einen Server zugreifen.
Also, auf dem Server sollen sie sich ja anmelden. Sie dürfen sich nur nicht an einen anderen Server anmelden. Kann man also unterbinden, dass sie Einstellungen in ihrem Client ändern?
Oder müsste man tatsächlich eine Rollentrennung einbringen? Lokale Admins, die die Clients konfigurieren und die Update-Admins, die über den Client auf den Update-Server zugreifen?
Es ist ja so, dass Admins über remote desktop auf einen Server zugreifen.
Also, auf dem Server sollen sie sich ja anmelden. Sie dürfen sich nur nicht an einen anderen Server anmelden. Kann man also unterbinden, dass sie Einstellungen in ihrem Client ändern?
Oder müsste man tatsächlich eine Rollentrennung einbringen? Lokale Admins, die die Clients konfigurieren und die Update-Admins, die über den Client auf den Update-Server zugreifen?
"dem Server", "andere Server" ... vielleicht verschaffst Du uns erst mal einen Gesamteindruck von Deinem Netzwerk ...
Naja, vom Prinzip ist es recht einfach.
Unabhängig von der Struktur kann die Frage lauten: Wie kann ich sicherstellen, dass sich ein User mit remote desktop client an genau einem für ihn bestimmten remote server anmeldet.
Also eine klassische n:1 Beziehung, n Clients, 1 Server, bzw. für den Einzelfall 1:1, jeder Client darf nur auf einen Server.
Verhindert werden soll n:n bzw. für den Einzelfall 1:n.
Die Frage konkretisiert:
Gibt es Konfigurationsmöglichkeiten im Remote Client, die festlegen, dass der Client sich nur mit einem Server verbinden darf?
Gibt es Gruppenrichtlinien, die ich einsetzen kann?
Danke für die Antworten.
Unabhängig von der Struktur kann die Frage lauten: Wie kann ich sicherstellen, dass sich ein User mit remote desktop client an genau einem für ihn bestimmten remote server anmeldet.
Also eine klassische n:1 Beziehung, n Clients, 1 Server, bzw. für den Einzelfall 1:1, jeder Client darf nur auf einen Server.
Verhindert werden soll n:n bzw. für den Einzelfall 1:n.
Die Frage konkretisiert:
Gibt es Konfigurationsmöglichkeiten im Remote Client, die festlegen, dass der Client sich nur mit einem Server verbinden darf?
Gibt es Gruppenrichtlinien, die ich einsetzen kann?
Danke für die Antworten.
Das beantwortet zwar immernoch nicht die Frage von SareHL, aber sei es drum...
Du kannst über Serverzertifikate authentifizieren und die RDP-Clients so einstellen, daß sie nur bei erfolgreicher Authentifizierung verbinden (Optionen --> Register Leistung --> Bereich Serverauthentifizierung). Falls also alle Server in deinem Netz ein Zertifikat haben, werden die Verbindungen zu allen Servern hergestellt. Vermutlich lief also auch SareHLs Frage darauf hinaus: geht es darum, daß die Admins nicht zufällig auf "fremde" Server (außerhalb des Netzes) gehen oder darum, wirklich mit dem richtigen Server im eingenen Netz verbunden zu sein?
geTuemII
Du kannst über Serverzertifikate authentifizieren und die RDP-Clients so einstellen, daß sie nur bei erfolgreicher Authentifizierung verbinden (Optionen --> Register Leistung --> Bereich Serverauthentifizierung). Falls also alle Server in deinem Netz ein Zertifikat haben, werden die Verbindungen zu allen Servern hergestellt. Vermutlich lief also auch SareHLs Frage darauf hinaus: geht es darum, daß die Admins nicht zufällig auf "fremde" Server (außerhalb des Netzes) gehen oder darum, wirklich mit dem richtigen Server im eingenen Netz verbunden zu sein?
geTuemII
Ja, so langsam wird es klarer. Danke!
Es geht tatsächlich darum, dass die Admins nicht "zufällig" auf fremde Server gehen.
@sarek: Sorry, dass ich die Frage nicht wirklich beantwortet habe, aber wir kommen schon dahinter.
Es geht tatsächlich darum, dass die Admins nicht "zufällig" auf fremde Server gehen.
@sarek: Sorry, dass ich die Frage nicht wirklich beantwortet habe, aber wir kommen schon dahinter.
