7
Sicherheit winrm
Moin,
ich bastel grade ein ziemlich wildes Konstrukt bei dem ich mich mit winrs /r:hostname an einem anderen Host in der selben Domäne anmelde. Ich bleibe entweder in meinem Benutzerkontext oder gebe Benutzername / Passwort als Parameter mit an. Das Passwort wird scheinbar nicht im Klartext durchs Netzwerk geschickt, jedenfalls gibt es einen extra Parameter /unencrypted für winrs, daraus würde ich schlussfolgern das per Default die Verbindung "encrypted" ist. Mehr Infos finde ich dazu aber nicht und ein echter Experte bin ich hier auch nicht, sind die Zugangsdaten sicher sofern ich nicht Zugriff auf das eigentliche Script oder den ausführenden Host habe?
Der Inhalt der Verbindung ist mir egal, mir geht es nur um die Anmeldeinformation.
ich bastel grade ein ziemlich wildes Konstrukt bei dem ich mich mit winrs /r:hostname an einem anderen Host in der selben Domäne anmelde. Ich bleibe entweder in meinem Benutzerkontext oder gebe Benutzername / Passwort als Parameter mit an. Das Passwort wird scheinbar nicht im Klartext durchs Netzwerk geschickt, jedenfalls gibt es einen extra Parameter /unencrypted für winrs, daraus würde ich schlussfolgern das per Default die Verbindung "encrypted" ist. Mehr Infos finde ich dazu aber nicht und ein echter Experte bin ich hier auch nicht, sind die Zugangsdaten sicher sofern ich nicht Zugriff auf das eigentliche Script oder den ausführenden Host habe?
Der Inhalt der Verbindung ist mir egal, mir geht es nur um die Anmeldeinformation.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2423404111
Url: https://administrator.de/contentid/2423404111
Ausgedruckt am: 18.11.2024 um 17:11 Uhr
7 Kommentare
Neuester Kommentar
Moin,
Somit bedeutet "encrypted" wohl auch hier, dass die Anmeldedaten im Klartext durch einen verschlüsselten Tunnel übertragen werden.
Wenn die Verbindung nur über das interne Netzwerk erfolgt, dürfte diese Gefahr wohl aber kaum existend sein.
Für mehr Sicherheit ansonsten Openssh mit RSA-Key-Anmeldung nutzen.
Gruß Thomas
Zitat von @ukulele-7:
Das Passwort wird scheinbar nicht im Klartext durchs Netzwerk geschickt, jedenfalls gibt es einen extra Parameter /unencrypted für winrs, daraus würde ich schlussfolgern das per Default die Verbindung "encrypted" ist.
allein der Logik halber: Das Passwort des Remotereservers existiert am Host nicht - der Abgleich der Anmeldedaten kann folglich nur am Server erfolgen.Das Passwort wird scheinbar nicht im Klartext durchs Netzwerk geschickt, jedenfalls gibt es einen extra Parameter /unencrypted für winrs, daraus würde ich schlussfolgern das per Default die Verbindung "encrypted" ist.
Somit bedeutet "encrypted" wohl auch hier, dass die Anmeldedaten im Klartext durch einen verschlüsselten Tunnel übertragen werden.
sind die Zugangsdaten sicher sofern ich nicht Zugriff auf das eigentliche Script oder den ausführenden Host habe?
Mit Man-in-the-Middle, wo man den verschlüsselten Tunnel einfach zu einem anderen Ziel umleitet, ist eine Anmeldung per Benutzername und Passwort immer angreifbar - sofern die Verbindung also über Internet erfolgt, eher nein.Wenn die Verbindung nur über das interne Netzwerk erfolgt, dürfte diese Gefahr wohl aber kaum existend sein.
Für mehr Sicherheit ansonsten Openssh mit RSA-Key-Anmeldung nutzen.
Gruß Thomas
Die Verbindung erfolgt rein intern zwischen zwei Servern. Als Remote-Host kann man sich daher nicht so einfach ausgeben.
Aber nur mal angenommen man könnte alle Netzwerkpakete mit lesen wie z.B. im WLAN, ließe sich dann das Passwort (oder der Hash) aus dem Verbindungsaufbau auslesen und damit eine Authentifizierung für eine eigene Verbindung durchführen? (z.B. wie bei FTP)
Ich sehe hier einen Unterschied zu FTP weil winrs ohne Credentials auch funktioniert, wenn der Benutzer auf beiden Domänenmitgliedern die passenden Rechte hat. Auch wenn ich es jetzt nicht vermute könnte winrs in der Lage sein die Authentifizierung über die Domäne abzuwickeln.
Sry wenn die Frage zu laienhaft ist, ich stecke da echt nicht tief drin.
Aber nur mal angenommen man könnte alle Netzwerkpakete mit lesen wie z.B. im WLAN, ließe sich dann das Passwort (oder der Hash) aus dem Verbindungsaufbau auslesen und damit eine Authentifizierung für eine eigene Verbindung durchführen? (z.B. wie bei FTP)
Ich sehe hier einen Unterschied zu FTP weil winrs ohne Credentials auch funktioniert, wenn der Benutzer auf beiden Domänenmitgliedern die passenden Rechte hat. Auch wenn ich es jetzt nicht vermute könnte winrs in der Lage sein die Authentifizierung über die Domäne abzuwickeln.
Sry wenn die Frage zu laienhaft ist, ich stecke da echt nicht tief drin.
Hallo,
Mit einen Wireshark Mitschnitt kein Problem.
/unencrypted
Specifies that the messages to the remote shell will not be encrypted. This is useful for troubleshooting or when the network traffic is already encrypted using ipsec, or when physical security is enforced.
By default, the messages are encrypted using Kerberos or NTLM keys.
This command-line option is ignored when HTTPS transport is selected.
Ein Wireshark zeigt es dir auch.
Gruß,
Peter
Mit einen Wireshark Mitschnitt kein Problem.
Sry wenn die Frage zu laienhaft ist, ich stecke da echt nicht tief drin.
Auszug von https://docs.microsoft.com/en-us/windows-server/administration/windows-c .../unencrypted
Specifies that the messages to the remote shell will not be encrypted. This is useful for troubleshooting or when the network traffic is already encrypted using ipsec, or when physical security is enforced.
By default, the messages are encrypted using Kerberos or NTLM keys.
This command-line option is ignored when HTTPS transport is selected.
Ein Wireshark zeigt es dir auch.
Gruß,
Peter
Hallo,
ich habe die Absicherung von winrm & Co im Prinzip aufgegeben. Stattdessen sichere ich die Ports über die Verbindungssicherheitsregeln der Windows Firewall. Da wird dann die Verbindung erst aufgebaut, wenn sie über IPSec zwischen Windows-Client und Windows-Server abgesichert wurde. Netterweise kann man da auch zulässige Remote-Computer und -Benutzer angeben. siehe Windows RDP mit Verbindungssicherheitsregeln absichern
Dann braucht man sich quasi nicht mehr um die winrs/winrm Sicherheitskonfiguration kümmern, sondern regelt das über die Firewall. Funktioniert allerdings nur innerhalb der Domäne.
Grüße
lcer
ich habe die Absicherung von winrm & Co im Prinzip aufgegeben. Stattdessen sichere ich die Ports über die Verbindungssicherheitsregeln der Windows Firewall. Da wird dann die Verbindung erst aufgebaut, wenn sie über IPSec zwischen Windows-Client und Windows-Server abgesichert wurde. Netterweise kann man da auch zulässige Remote-Computer und -Benutzer angeben. siehe Windows RDP mit Verbindungssicherheitsregeln absichern
Dann braucht man sich quasi nicht mehr um die winrs/winrm Sicherheitskonfiguration kümmern, sondern regelt das über die Firewall. Funktioniert allerdings nur innerhalb der Domäne.
Grüße
lcer
Das mit der Windows Firewall klingt ziemlich sinnvoll, das teste ich mal.
Ich bin jetzt nicht grade erpicht darauf den Traffic zwischen 2 VMs mit Wireshark zu sniffen um mir die Frage zu beantworten, das mache ich nicht jeden Tag. Ich denke mal hier kommt Kerberos zum Einsatz (wenn nicht "unencrypted" gesetzt wird) und dann werden wohl keine Credentials zwischen den Servern verschickt sondern ein/die Kerberos-Ticket(s) übermittelt.
https://www.bmc.com/blogs/kerberos-authentication-what-is-it-how-it-work ...
Ich bin jetzt nicht grade erpicht darauf den Traffic zwischen 2 VMs mit Wireshark zu sniffen um mir die Frage zu beantworten, das mache ich nicht jeden Tag. Ich denke mal hier kommt Kerberos zum Einsatz (wenn nicht "unencrypted" gesetzt wird) und dann werden wohl keine Credentials zwischen den Servern verschickt sondern ein/die Kerberos-Ticket(s) übermittelt.
https://www.bmc.com/blogs/kerberos-authentication-what-is-it-how-it-work ...
Hallo,
Das Problem ist, das man nicht sicher sagen kann, welche Authentifizierung verwendet wird. Man kann (per GPO) die möglichen Varianten einschränken, oft gehen dann aber bestimmte Anwendungen nicht.
siehe https://docs.microsoft.com/en-us/powershell/module/cimcmdlets/new-cimses ...
Je nach technischer Umsetzung des Remote-Aufrufes legt der Entwickler fest, ob die Authentifizierung per Default erfolgt oder ob er eine konkrete Variante möchte.
Ich hatte das Problem, dass ich alle Authentifizierungen auf Kerberos umstellen wollte, das funktionierte aber mit dem Monitoring teilweise nicht.
Grüße
lcer
Zitat von @ukulele-7:
Ich denke mal hier kommt Kerberos zum Einsatz (wenn nicht "unencrypted" gesetzt wird)
siehe https://docs.microsoft.com/en-us/windows/win32/winrm/authentication-for- ...Ich denke mal hier kommt Kerberos zum Einsatz (wenn nicht "unencrypted" gesetzt wird)
Das Problem ist, das man nicht sicher sagen kann, welche Authentifizierung verwendet wird. Man kann (per GPO) die möglichen Varianten einschränken, oft gehen dann aber bestimmte Anwendungen nicht.
siehe https://docs.microsoft.com/en-us/powershell/module/cimcmdlets/new-cimses ...
New-CimSession -ComputerName Server01 -Credential $cred -Authentication NegotiateIch hatte das Problem, dass ich alle Authentifizierungen auf Kerberos umstellen wollte, das funktionierte aber mit dem Monitoring teilweise nicht.
Grüße
lcer
Noch ein guter Grund für deine Firewall Variante.
Das Risiko insgesamt ist bei mir sehr gering. Der User kommt ja nicht an den Netzwerktraffic der noch dazu im eigenen VLAN läuft. Aber es kann sein das ich den Code mal irgendwo extern brauche.
Das Risiko insgesamt ist bei mir sehr gering. Der User kommt ja nicht an den Netzwerktraffic der noch dazu im eigenen VLAN läuft. Aber es kann sein das ich den Code mal irgendwo extern brauche.
