Windows 10 RDP

[Frank Hartwig]

Moin zusammen,

ich habe gerade von Windows 7 auf Windows 10 umgestellt und ein kleines
Problem mit dem RDP-client.

Ich verbinde mich mittels plink auf einen Linux-Router, der im Netz des
RDP-Servers (Windows Server 2016) steht und tunnele den RDP-Port auf
meinen Windows 10-Rechner:

plink.exe -L 127.0.0.1:13389:192.168.1.10:3389 -l linux-router
85.16.75.175 -i Schlüsseldatei

Auf meinem Windows-7-Rechner und auch von Linux-Rechnern aus konnte ich
mich dann mit dem RDP-Client bzw. Freerdp auf 127.0.0.1:13389 verbinden.

Lediglich vom Windows-10-Rechner aus werde ich bei der Authentifikation
abgewiesen.

Was hat sich hier geändert bzw. wie kann ich das ändern?

Es wäre nett, wenn jemand Vorschläge hätte.

Im Voraus Dank

Frank

[Michael Logies]

Suche auf dem Win 10 nach "erweiterte Systemeinstellungen". Reiter
"Remote". Da den Haken ganz unten rausnehmen.

Grüße

M.

[Frank Hartwig]

Du meintest vermutlich, daß ich die Einstellung auf dem Windows Server
ändern soll, mit dem möchte ich mich ja verbinden.

Habe ich auch versucht, hilft aber nicht, die Authentifikation wird
abgelehnt.

Ich frage mich, was Windows 10 da anders macht als Windows 7.

Trotzdem Dank

Frank

Post by Michael Logies
Suche auf dem Win 10 nach "erweiterte Systemeinstellungen". Reiter
"Remote". Da den Haken ganz unten rausnehmen.
Grüße
M.

[Thomas Krenzel]

On Mon, 13 Jan 2020 20:02:19 +0100

Post by Frank Hartwig
Du meintest vermutlich, daß ich die Einstellung auf dem Windows Server

^^^^^^^^^^^^^^^^^^
Das hat Michael nicht geschrieben und wohl auch nicht gemeint ;)

Post by Frank Hartwig

Post by Michael Logies
Suche auf dem Win 10 nach "erweiterte Systemeinstellungen". Reiter
"Remote". Da den Haken ganz unten rausnehmen.

;)

[Arno Welzel]

Post by Frank Hartwig
Du meintest vermutlich, daß ich die Einstellung auf dem Windows Server
ändern soll, mit dem möchte ich mich ja verbinden.
Habe ich auch versucht, hilft aber nicht, die Authentifikation wird
abgelehnt.
Ich frage mich, was Windows 10 da anders macht als Windows 7.

Es prüft, ob die Clients eine "Authentifizierung auf Netwerkebene"
machen. Diese Option kann man ggf. auch ausschalten.

Siehe hier:
<https://nextcloud.0x0c.de/s/xCqpi3qdZxgxTma/preview>

[Frank Hartwig]

Hallo Arno,

Post by Arno Welzel

Post by Frank Hartwig
Ich frage mich, was Windows 10 da anders macht als Windows 7.

Es prüft, ob die Clients eine "Authentifizierung auf Netwerkebene"
machen. Diese Option kann man ggf. auch ausschalten.

Leider hat das Abschalten der "Authentifizierung auf Netzwerkebene" bei
mir überhaupt keinen Einfluß auf die Authentifizierung.

Ich vermute eher, daß dem Benutzernamen noch etwas hinzugefügt wird.
Nach dem ersten Ablehnen der Authentifikation wird ja nochmals das
Passwort abgefragt. Dabei wird immer nach dem Passwort von:
<Rechnername>\<Benutzer> gefragt. Ich melde mich allerdings nur mit
<Benutzer> an.

Die Kombination aus <Rechnername>\<Benutzer> hat vermutlich kein Recht
RDP zu benutzen.

Aber das ist wie gesagt nur eine Vermutung.

Gruß Frank

[Arno Welzel]

Post by Frank Hartwig
Leider hat das Abschalten der "Authentifizierung auf Netzwerkebene" bei
mir überhaupt keinen Einfluß auf die Authentifizierung.
Ich vermute eher, daß dem Benutzernamen noch etwas hinzugefügt wird.
Nach dem ersten Ablehnen der Authentifikation wird ja nochmals das
<Rechnername>\<Benutzer> gefragt. Ich melde mich allerdings nur mit
<Benutzer> an.

Probiere alternativ Remmina als Client:

<https://remmina.org/>

Das Ding beherrscht auch RDP und zumindest bei mir hat damit auch der
Zugriff auf Windows 10-Kisten funktioniert.

Ach ja - bei Windows 10 Home geht RDP generell nicht. Dazu ist
mindestens "Pro" nötig.

[Frank Hartwig]

Post by Arno Welzel
<https://remmina.org/>
Das Ding beherrscht auch RDP und zumindest bei mir hat damit auch der
Zugriff auf Windows 10-Kisten funktioniert.

Hier gibt es wohl ein Mißverständnis. Das Verbinden *von* Windows-10
funktioniert nicht richtig. Das Verbinden *zu* Windows-10-Rechnern
funktioniert (zumindest von Windows 7).

Genauer gesagt funktioniert die Authentifizierung *von* einem
Windows-10-Rechner an einem Windows Server 2016 nicht.

Remmina benutzt meines Erachtens freerdp und damit funktioniert die
Anmeldung. Remmina läuft aber meines Erachtens nur auf Linux-Systemen.
Allerdings ist es ziemlicher Krampf, erst eine Linux-VM zu booten um
dann freerdp zu benutzen, was auch noch deutlich langsamer ist als
Windows RDP. Ist aber zur Zeit meine einzige Möglichkeit.

Gruß Frank

[Arno Welzel]

Post by Frank Hartwig

Post by Arno Welzel
<https://remmina.org/>
Das Ding beherrscht auch RDP und zumindest bei mir hat damit auch der
Zugriff auf Windows 10-Kisten funktioniert.

Hier gibt es wohl ein Mißverständnis. Das Verbinden *von* Windows-10
funktioniert nicht richtig. Das Verbinden *zu* Windows-10-Rechnern
funktioniert (zumindest von Windows 7).

Ok, dann gilt meine Aussage zur Netzwerkauthentifizierung naürlich für
den Server und nicht den Windows 10-Client.

Post by Frank Hartwig
Genauer gesagt funktioniert die Authentifizierung *von* einem
Windows-10-Rechner an einem Windows Server 2016 nicht.
Remmina benutzt meines Erachtens freerdp und damit funktioniert die
Anmeldung. Remmina läuft aber meines Erachtens nur auf Linux-Systemen.

Ich dachte, Du benutzt einen Linux-Client, deswegen die Empfehlung.

[Frank Hartwig]

On Fri, 17 Jan 2020 09:02:16 +0100, Frank Hartwig
https://administrator.de/forum/alternativer-rdp-client-windows-206827.html

Davon habe ich jetzt eine Alternative getestet. Da scheint aber die
Windows-software im Hintergrund zu arbeiten, das Verhalten ist dasselbe.

Ich habe die Diskussion nicht mehr so vor Augen: Kommst Du vom
Win10-Rechner aus z. B. auf den Win 7-Pro-Rechner? Vielleicht ist
irgendeine Komponente bei Deinem Win 10 kaputt, wenn nicht?

Ich komme von meinem Windows-10-Rechner nicht auf andere Windows-Rechner
im gewünschten Netz, wenn ich den RDP-Port mittels plink auf eine lokale
IP lege.

plink.exe -L 127.0.0.1:13389:192.168.1.10:3389 <IP des Routers> ...

Nutze ich Windows 7 oder einen Linux-Rechner mit freerdp, funktioniert
alles wie gewünscht.

Nutze ich eine Portweiterleitung im Router, funktioniert die Anmeldung
ebenfalls. Ich möchte die Portweiterleitung aber nicht so gerne
dauerhaft offen lassen. Das mappen des Ports für die Dauer der Nutzung
ist m.E. die sicherere Variante.

[Wolfgang Ottenweller]

Post by Arno Welzel
<https://remmina.org/>

<klick>

"Install it on any OS you like"

I like IOS, IpadOS and Windows.

Post by Arno Welzel
Ach ja - bei Windows 10 Home geht RDP generell nicht. Dazu ist
mindestens "Pro" nötig.

Als Client?

[Arno Welzel]

Post by Wolfgang Ottenweller

Post by Arno Welzel
<https://remmina.org/>

<klick>
"Install it on any OS you like"
I like IOS, IpadOS and Windows.

Post by Arno Welzel
Ach ja - bei Windows 10 Home geht RDP generell nicht. Dazu ist
mindestens "Pro" nötig.

Als Client?

Nein, als Server. Ich dachte irrtümlich, es geht um den Zugriff *auf*
ein System mit Windows 10 von außen und nicht *mit* Windows 10.

[Jörg Hermes]

Lediglich  vom Windows-10-Rechner aus werde ich bei der Authentifikation
abgewiesen.

Wie lautet denn die Fehlermeldung, oder gibt es keine?

[Frank Hartwig]

Post by Jörg Hermes

Lediglich  vom Windows-10-Rechner aus werde ich bei der
Authentifikation abgewiesen.

Wie lautet denn die Fehlermeldung, oder gibt es keine?

Nein , es gibt keine, ich bekomme nur immer wieder die Anmeldemaske, wie
das eben so ist, wenn die Anmeldung nicht akzeptiert wird.

Die Ereignisanzeige des Servers zeigt auch nichts an.

Gruß Frank

[Olaf Schmitt]

Post by Frank Hartwig
Moin zusammen,
ich habe gerade von Windows 7 auf Windows 10 umgestellt und ein kleines
Problem mit dem RDP-client.
Ich verbinde mich mittels plink auf einen Linux-Router, der im Netz des
RDP-Servers (Windows Server 2016) steht und tunnele den RDP-Port auf
plink.exe -L 127.0.0.1:13389:192.168.1.10:3389 -l linux-router
85.16.75.175 -i Schlüsseldatei
Auf meinem Windows-7-Rechner und auch von Linux-Rechnern aus konnte ich
mich dann mit dem RDP-Client bzw. Freerdp auf 127.0.0.1:13389 verbinden.
Lediglich  vom Windows-10-Rechner aus werde ich bei der Authentifikation
abgewiesen.
Was hat sich hier geändert bzw. wie kann ich das ändern?
Es wäre nett, wenn jemand Vorschläge hätte.
Im Voraus Dank
Frank

Ich würde zum Test einmal die Firewall von W10 ausschalten.
Wenn es dann geht, dann musst du dich darum kümmern, welche Ports
wirklich benutzt werden.

Olaf

[Falk Dµbbert]

Post by Frank Hartwig
Moin zusammen,
ich habe gerade von Windows 7 auf Windows 10 umgestellt und ein kleines
Problem mit dem RDP-client.
Ich verbinde mich mittels plink auf einen Linux-Router, der im Netz des
RDP-Servers (Windows Server 2016) steht und tunnele den RDP-Port auf
plink.exe -L 127.0.0.1:13389:192.168.1.10:3389 -l linux-router
85.16.75.175 -i Schlüsseldatei
Auf meinem Windows-7-Rechner und auch von Linux-Rechnern aus konnte ich
mich dann mit dem RDP-Client bzw. Freerdp auf 127.0.0.1:13389 verbinden.

Versuch mal .\ vor dem Benutzernamen oder
***@primäreIPdesZielrechners als Benutzername.

Das hilft zumindest bei meinen Putty-ssh-Tunnels, mit denen ich mich
durch die Kundennetze stückele.

Falk D.

[Frank Hartwig]

Post by Falk Dµbbert
Versuch mal .\ vor dem Benutzernamen oder

Kannst Du das genauer ausführen?

Kann man die RDP-Anmeldung per Skript durchführen?

Vielleicht stehe ich da auf einem mir unbekannten Schlauch.

Gruß Frank

[Arno Welzel]

Post by Frank Hartwig

Post by Falk Dµbbert
Versuch mal .\ vor dem Benutzernamen oder

Kannst Du das genauer ausführen?

Da, wo man den Benutzernamen eingibt, statt dessen
"***@IP-Adresse" angeben. Also wenn der Server mit 10.0.0.200
läuft, eben "***@10.0.0.200". Alternative geht auch
"***@servername".

[Frank Hartwig]

Post by Arno Welzel

Post by Frank Hartwig

Post by Falk Dµbbert
Versuch mal .\ vor dem Benutzernamen oder

Kannst Du das genauer ausführen?

Da, wo man den Benutzernamen eingibt, statt dessen

OK, verstanden. Aber leider wird weder "***@IP-Adresse" noch
"***@Servername" zusammen mit korrektem Paßwort akzeptiert.

Gruß und Dank

Frank

[Arno Welzel]

Post by Frank Hartwig
Moin zusammen,
ich habe gerade von Windows 7 auf Windows 10 umgestellt und ein kleines
Problem mit dem RDP-client.
Ich verbinde mich mittels plink auf einen Linux-Router, der im Netz des
RDP-Servers (Windows Server 2016) steht und tunnele den RDP-Port auf
plink.exe -L 127.0.0.1:13389:192.168.1.10:3389 -l linux-router
85.16.75.175 -i Schlüsseldatei
Auf meinem Windows-7-Rechner und auch von Linux-Rechnern aus konnte ich
mich dann mit dem RDP-Client bzw. Freerdp auf 127.0.0.1:13389 verbinden.
Lediglich vom Windows-10-Rechner aus werde ich bei der Authentifikation
abgewiesen.
Was hat sich hier geändert bzw. wie kann ich das ändern?
Es wäre nett, wenn jemand Vorschläge hätte.

Vielleicht helfen die Hinweise hier:

<https://docs.microsoft.com/de-de/windows-server/remote/remote-desktop-services/troubleshoot/rdp-error-general-troubleshooting>

<https://docs.microsoft.com/de-de/windows-server/remote/remote-desktop-services/troubleshoot/cannot-authenticate-or-must-authenticate-twice>

[Frank Hartwig]

Post by Arno Welzel

Post by Frank Hartwig
Moin zusammen,
ich habe gerade von Windows 7 auf Windows 10 umgestellt und ein kleines
Problem mit dem RDP-client.
Ich verbinde mich mittels plink auf einen Linux-Router, der im Netz des
RDP-Servers (Windows Server 2016) steht und tunnele den RDP-Port auf
plink.exe -L 127.0.0.1:13389:192.168.1.10:3389 -l linux-router
85.16.75.175 -i Schlüsseldatei
Auf meinem Windows-7-Rechner und auch von Linux-Rechnern aus konnte ich
mich dann mit dem RDP-Client bzw. Freerdp auf 127.0.0.1:13389 verbinden.
Lediglich vom Windows-10-Rechner aus werde ich bei der Authentifikation
abgewiesen.
Was hat sich hier geändert bzw. wie kann ich das ändern?
Es wäre nett, wenn jemand Vorschläge hätte.

<https://docs.microsoft.com/de-de/windows-server/remote/remote-desktop-services/troubleshoot/rdp-error-general-troubleshooting>
<https://docs.microsoft.com/de-de/windows-server/remote/remote-desktop-services/troubleshoot/cannot-authenticate-or-must-authenticate-twice>

Danke für die Links. Ich habe sie leider ohne Erfolg durchgearbeitet.
Ich habe also kein "bekanntes Problem" ;-(

Inzwischen habe ich das Problem weiter eingegrenzt. Ich komme von meinem
Windows-10-Rechner auch nicht auf andere Windows-Rechner im gewünschten
Netz, wenn ich den RDP-Port mittels plink auf eine lokale IP lege.

plink.exe -L 127.0.0.1:13389:192.168.1.10:3389 <IP des Routers> ...

Nutze ich eine Portweiterleitung im Router, oder benutze Windows 7,
funktioniert die Anmeldung. Ich möchte die Portweiterleitung aber nicht
so gerne dauerhaft offen lassen. Das mappen des Ports für die Dauer der
Nutzung ist m.E. die sicherere Variante.

Windows 10 nutzt offensichtlich zusätzliche Informationen aus der
Verbindung zur Authentifizierung und wird dann abgewiesen.

Wenn man das nicht abstellen kann, werde ich mir andere Lösungen
einfallen lassen müssen.

Gruß und Dank

Frank

[Thorsten Albrecht]

Post by Frank Hartwig
Wenn man das nicht abstellen kann, werde ich mir andere Lösungen
einfallen lassen müssen.

Warum nimmst Du überhaupt eine Portweiterleitung, und nicht gleich
eine VPN-Verbindung? Ich nutze ausschließlich VPN-Einwahlen auf
remote-Router (via IPsec). Damit gibt es maximal
Namensauflösungsprobleme.

Thorsten

[Frank Hartwig]

Post by Thorsten Albrecht

Post by Frank Hartwig
Wenn man das nicht abstellen kann, werde ich mir andere Lösungen
einfallen lassen müssen.

Warum nimmst Du überhaupt eine Portweiterleitung, und nicht gleich
eine VPN-Verbindung? Ich nutze ausschließlich VPN-Einwahlen auf
remote-Router (via IPsec). Damit gibt es maximal
Namensauflösungsprobleme.

Ich muß diese Verbindungsmöglichkeit auch Personen gewähren, die ihren
Rechner/Netze evtl. nicht so "sauber" halten. Da erscheint mir eine
Portweiterleitung deutlich sicherer zu sein.

Gruß Frank

[Thorsten Albrecht]

Post by Frank Hartwig

Post by Thorsten Albrecht

Post by Frank Hartwig
Wenn man das nicht abstellen kann, werde ich mir andere Lösungen
einfallen lassen müssen.

Warum nimmst Du überhaupt eine Portweiterleitung, und nicht gleich
eine VPN-Verbindung? Ich nutze ausschließlich VPN-Einwahlen auf
remote-Router (via IPsec). Damit gibt es maximal
Namensauflösungsprobleme.

Ich muß diese Verbindungsmöglichkeit auch Personen gewähren, die ihren
Rechner/Netze evtl. nicht so "sauber" halten. Da erscheint mir eine
Portweiterleitung deutlich sicherer zu sein.

Das ist korrekt, wenn man es nicht schafft, die VPN-Verbindung so zu
konfigurieren, dass sie lediglich dem Einwählenden exakt einen
einzigen Port und einen Zielrechner zur Verfügung stellt. Falls man
diese Einschränkung jedoch hinkriegt (mittels VPN-Server bzw. Firewall
auf dem Zielsystem), dann dürfte der VPN-Ansatz Deinem ebenbürtig sein
(und vielleicht sogar noch besser, da IPsec). Allerdings sparst Du
durch Deinen Ansatz einen (ggf. teuren) VPN-Client auf den
Remote-Rechnern; nicht schlecht. Dafür hat muss man sich mit einem
Linux-Router auf dem Zielsystem herumschlagen; das wäre nix für
mich... (ich würde eher einen Lancom-Router bevorzugen!).

BTW Falls Du den "anderen Personen" eine CLI Konfiguration mittels
plink bzw. Putty ersparen willst, empfehle ich Dir, ihnen den Tunnel
mittels Bitwise SSH Client zu erstellen. Dann musst Du ihnen lediglich
ein Profil (für's GUI) zuschicken, und alles funktioniert
out-of-the-box. Erheblich komfortablerer SSH-Client als Putty, und
erstaunlicherweise sogar umsonst.

Der Unterschied zu Putty ist übrigens auch, dass dort eine echte Firma
hintersteht, die Bitvise seit zig Jahren kontinuierlich, d.h. fast
jeden Monat, verbessert und Sicherheitslöcher stopft. Bei Putty gab es
dagegen in der Vergangenheit teilweise lange und mehrjährige Pausen
in den Release-Notes. Zwischen 2007 und 2011 dachte ich, dass das Tool
komplett gestorben sei.

Thorsten

[Thorsten Albrecht]

On Sun, 19 Jan 2020 18:09:18 +0100, Thorsten Albrecht

Post by Thorsten Albrecht

Post by Frank Hartwig
Ich muß diese Verbindungsmöglichkeit auch Personen gewähren, die ihren
Rechner/Netze evtl. nicht so "sauber" halten. Da erscheint mir eine
Portweiterleitung deutlich sicherer zu sein.

Das ist korrekt, wenn man es nicht schafft, die VPN-Verbindung so zu
konfigurieren, dass sie lediglich dem Einwählenden exakt einen
einzigen Port und einen Zielrechner zur Verfügung stellt.

Besteht die Gefahr nicht nur in einem schlecht gesicherten
Windows-LAN? Wenn die Dateifreigaben im Windows-LAN auf bestimmte
Personen beschränkt und mit guten Paßwörtern abgesichert sind, kommt
doch ein externer auch übers VPN nicht weit? Und diese
Netzwerkfreigaben sind doch, durch entsprechende Nutzer- und
LAN-Paßwortwahl, unabhängig vom Zugriff auf den RDP-Server zu
gestalten.

Der OP meinte das aber IMO anders herum: der Einwählende hat ein
"schlechtes/verseuchtes" Netz. Wenn der sich jetzt mit VPN einwählt,
besteht die Gefahr, dass sich eine Schadware aus dem Remote-Netz des
Einwählenden im Zielnetz breitmachen könnte. Könnte ja sein, dass das
Zielnetz eine Schwachstelle hat. Durch Porteinschränkungen i.V.m. VPN
kann man dieses Risiko ziemlich gut auf günstige Weise vermindern.

Ich nutze fürs VPN seit ca. 10 Jahren Hamachi.

Ja, das ist (sicherlich nicht nur mir) seit langem bekannt. Das hast
Du in dieser Gruppe bereits gefühlte 250mal wiederholt, und ich habe
es so sehr verinnerlicht, dass ich, wenn ich das Wort "Hamachi" höre,
sofort diesen Produktnamen mit "Zahnartzt" assoziiere.


Thorsten

[Michael Logies]

On Mon, 20 Jan 2020 11:10:47 +0100, Thorsten Albrecht

Post by Thorsten Albrecht
Der OP meinte das aber IMO anders herum: der Einwählende hat ein
"schlechtes/verseuchtes" Netz. Wenn der sich jetzt mit VPN einwählt,
besteht die Gefahr, dass sich eine Schadware aus dem Remote-Netz des
Einwählenden im Zielnetz breitmachen könnte. Könnte ja sein, dass das
Zielnetz eine Schwachstelle hat. Durch Porteinschränkungen i.V.m. VPN
kann man dieses Risiko ziemlich gut auf günstige Weise vermindern.

Ich meinte das genau wie oben. Das Zielnetz bzw. dessen
Netzwerkfreigaben sollten sowieso durch sichere Benutzer/Paßwörter und
die eingebauten Desktopfirewalls abgesichert sein. Dann sollte egal
sein, wenn ein verseuchter Rechner per VPN darauf zugreift, weil er
nur auf den offenen RDP-Port kommen sollte.

Post by Thorsten Albrecht

Ich nutze fürs VPN seit ca. 10 Jahren Hamachi.

Ja, das ist (sicherlich nicht nur mir) seit langem bekannt.

Gute Sachen kann man nicht oft genug anpreisen, sonst funktioniert die
Marktwirtschaft nicht. ;-) Gutes setzt sich leider nicht von alleine
durch, sondern bedarf auch des Marketings.

Aktuell kommen als Alternative (für ein einfach zu konfigurierendes
VPN mit Clients auf den Endgeräten) noch NeoRouter und Zerotier in
Frage:
https://alternativeto.net/software/hamachi/?license=opensource

Konnte ich beide leider noch nicht ausprobieren. Hat jemand
Erfahrungen?

Neu für mich in den letzten 6 Wochen war, wie leicht Hamachi dank
Haguichi mittlerweile auch unter Linux zu nutzen ist. Ich habe
parallel zum Windows 10 auf meinen beiden eher schwächlichen Laptops
(Full HD und 2*3 MP, also 6 Megapixeldisplay) Linux MX19 installiert.
Und die Desktopskalierung (Zielsystem: 1950*1200) ist mit Remmina auf
MX19 flexibler als mit MS-RDP. Flotter als Win 10 ist MX auch noch.
(Für Videos über RDP gilt das nicht, aber da habe ich meine
Testergebnisse nicht mehr genau vor Augen. xrdp ist aktuell jedenfalls
einem RDP-Terminalserver (wie Thinstuff) auf Win 10 für Videos
deutlich unterlegen) .

Grüße

M.

[Thorsten Albrecht]

Post by Michael Logies
On Mon, 20 Jan 2020 11:10:47 +0100, Thorsten Albrecht

Post by Thorsten Albrecht
Der OP meinte das aber IMO anders herum: der Einwählende hat ein
"schlechtes/verseuchtes" Netz. Wenn der sich jetzt mit VPN einwählt,
besteht die Gefahr, dass sich eine Schadware aus dem Remote-Netz des
Einwählenden im Zielnetz breitmachen könnte. Könnte ja sein, dass das
Zielnetz eine Schwachstelle hat. Durch Porteinschränkungen i.V.m. VPN
kann man dieses Risiko ziemlich gut auf günstige Weise vermindern.

Ich meinte das genau wie oben. Das Zielnetz bzw. dessen
Netzwerkfreigaben sollten sowieso durch sichere Benutzer/Paßwörter und
die eingebauten Desktopfirewalls abgesichert sein. Dann sollte egal
sein, wenn ein verseuchter Rechner per VPN darauf zugreift, weil er
nur auf den offenen RDP-Port kommen sollte.

Die echte Gefahr lauert m. E. sowieso nicht in einer VPN-Einwahl von
außen, sondern im Öffnen eines gefaketen Word-Dokumentes. Einmal auf
die falsche Email geklickt, und das war's. Und teilweise merkt man es
erst Wochen später, dass da was nicht stimmt. Siehe der kleine Unfall
bei Heise...:
https://www.heise.de/ct/artikel/Trojaner-Befall-Emotet-bei-Heise-4437807.html

BTW Und auch per RDP kann man ein solches gefaketes Word-Dokument
versehentlich öffnen. Da ist es dann auch egal, wie man auf den
Rechner gekommen ist, ob via SSH-Tunnel, VPN-Server oder Hamachi.

Thorsten

[Michael Logies]

On Mon, 20 Jan 2020 15:06:38 +0100, Thorsten Albrecht

Post by Thorsten Albrecht
Die echte Gefahr lauert m. E. sowieso nicht in einer VPN-Einwahl von
außen, sondern im Öffnen eines gefaketen Word-Dokumentes

Sehe ich auch so. Und Emotet nutzt nicht nur SMB-Lücken, für die die
Updates nicht eingespielt wurden, sondern knackt auch per Brute-Force
schwache, administrative Paßwörter, um sich auf andere Rechner im
LAN/VPN ausbreiten zu können. Sichere Paßwörter im LAN bleiben also m.
E. mit das wichtigste. Es gab Penetrationstests in Arztpraxen. Viele
haben gar keine Paßwörter im LAN oder unsichere (wie "Praxis").

Grüße

M.

[Frank Hartwig]

Post by Frank Hartwig
Moin zusammen,
ich habe gerade von Windows 7 auf Windows 10 umgestellt und ein kleines
Problem mit dem RDP-client.
Ich verbinde mich mittels plink auf einen Linux-Router, der im Netz des
RDP-Servers (Windows Server 2016) steht und tunnele den RDP-Port auf
plink.exe -L 127.0.0.1:13389:192.168.1.10:3389 -l linux-router
85.16.75.175 -i Schlüsseldatei
Auf meinem Windows-7-Rechner und auch von Linux-Rechnern aus konnte ich
mich dann mit dem RDP-Client bzw. Freerdp auf 127.0.0.1:13389 verbinden.
Lediglich  vom Windows-10-Rechner aus werde ich bei der Authentifikation
abgewiesen.

Ich antworte mir mal selber, da das Problem an anderer Stelle gelöst wurde.

Die Frage, wo sich der RDP-Client von Windows 10 anders verhält als der
von Windows 7, und ob man das abstellen kann, bleibt ungeklärt.

Ich habe den Tunnel jetzt direkt mit putty aufgebaut statt mit plink und
habe keine Probleme mehr. Es gibt also offensichtlich auch Unterschiede
im Tunnelaufbau zwischen putty und plink.

Dank an alle, die mitgedacht haben

Gruß Frank