Sicherheitsüberlegungen für PowerShell-Remoting mit WinRM
PowerShell Remoting ist die empfohlene Methode zum Verwalten von Windows-Systemen. PowerShell-Remoting ist in Windows Server 2012 R2 und höher standardmäßig aktiviert. Dieses Dokument behandelt Sicherheitsbedenken, Empfehlungen und bewährte Methoden bei der Verwendung von PowerShell Remoting.
Was ist PowerShell-Remoting?
PowerShell-Remoting verwendet Windows Remote Management (WinRM), um Benutzern das Ausführen von PowerShell-Befehlen auf Remotecomputern zu ermöglichen. WinRM ist die Microsoft-Implementierung des Web Services for Management (WS-Management) Protokoll. Weitere Informationen zur Verwendung von PowerShell-Remoting finden Sie unter Ausführen von Remotebefehlen.
PowerShell-Remoting unterscheidet sich von der Ausführung eines Cmdlets auf einem Remotecomputer unter Verwendung des Parameters ComputerName, wobei ein Remoteprozeduraufruf (Remote Procedure Call, RPC) als zugrunde liegendes Protokoll verwendet wird.
Standardeinstellungen für PowerShell-Remoting
PowerShell-Remoting (und WinRM) lauschen an folgenden Ports:
- HTTP: 5985
- HTTPS: 5986
Standardmäßig lässt PowerShell-Remoting nur Verbindungen von Mitgliedern der Gruppe "Administratoren" zu. Sitzungen werden im Kontext des Benutzers gestartet, sodass alle Zugriffssteuerungen des Betriebssystems, die auf einzelne Benutzer und Gruppen angewendet werden, weiterhin für sie gelten, während sie über PowerShell-Remoting verbunden sind.
In privaten Netzwerken akzeptiert die Standardmäßige Windows-Firewallregel für PowerShell-Remoting alle Verbindungen. In öffentlichen Netzwerken lässt die Windows-Firewall-Standardregel Verbindungen mit PowerShell-Remoting nur aus demselben Subnetz heraus zu. Sie müssen diese Regel explizit ändern, um PowerShell-Remoting für alle Verbindungen in einem öffentlichen Netzwerk zu öffnen.
Warnung
Die Firewallregel für öffentliche Netzwerke soll den Computer vor potenziell böswilligen externen Verbindungsversuchen schützen. Achten Sie beim Entfernen dieser Regel auf Vorsicht.
Prozessisolation
PowerShell Remoting verwendet WinRM für die Kommunikation zwischen Computern. WinRM wird als Dienst unter dem Netzwerkdienstkonto ausgeführt und startet isolierte Prozesse, die unter Benutzerkonten laufen, um PowerShell-Instanzen zu hosten. Eine Instanz von PowerShell, die als ein Benutzer ausgeführt wird, hat keinen Zugriff auf einen Prozess, der eine Instanz von PowerShell als einen anderen Benutzer ausführt.
Von PowerShell Remoting generierte Ereignisprotokolle
FireEye stellt eine gute Zusammenfassung der Ereignisprotokolle und andere Sicherheitsinformationen, die von PowerShell-Remotingsitzungen generiert werden, unter Investigating PowerShell Attacks (Untersuchen von PowerShell-Angriffen) bereit.
Verschlüsselungs- und Transportprotokolle
Es ist hilfreich, die Sicherheit einer PowerShell-Remoting-Verbindung aus zwei Perspektiven zu berücksichtigen: die anfängliche Authentifizierung und die fortlaufende Kommunikation.
Unabhängig vom verwendeten Transportprotokoll (HTTP oder HTTPS) verschlüsselt WinRM immer die gesamte PowerShell-Remoting-Kommunikation im Anschluss an die anfängliche Authentifizierung.
Anfängliche Authentifizierung
Die Authentifizierung bestätigt die Identität des Clients beim Server – und idealerweise – des Servers gegenüber dem Client.
Stellt ein Client eine Verbindung mit einem Domänenserver mithilfe seines Computernamens her, ist das Standardprotokoll für die Authentifizierung Kerberos. Kerberos garantiert sowohl die Benutzeridentität als auch die Serveridentität, ohne eine Art wiederverwendbarer Anmeldeinformationen zu senden.
Wenn ein Client mithilfe seiner IP-Adresse eine Verbindung mit einem Domänenserver herstellt oder eine Verbindung mit einem Arbeitsgruppenserver herstellt, ist die Kerberos-Authentifizierung nicht möglich. In diesem Fall basiert PowerShell Remoting auf dem NTLM-Authentifizierungsprotokoll. Das NTLM-Authentifizierungsprotokoll garantiert die Benutzeridentität, ohne delegierbare Anmeldeinformationen zu senden. Um die Benutzeridentität zu bestätigen, erfordert das NTLM-Protokoll, dass sowohl der Client als auch der Server einen Sitzungsschlüssel aus dem Kennwort des Benutzers berechnen, ohne das Kennwort selbst auszutauschen. Der Server kennt in der Regel das Kennwort des Benutzers nicht, daher kommuniziert er mit dem Domänencontroller, der das Kennwort des Benutzers kennt und den Sitzungsschlüssel für den Server berechnet.
Das NTLM-Protokoll garantiert jedoch keine Serveridentität. Wie bei allen Protokollen, die NTLM für die Authentifizierung verwenden, könnte ein Angreifer mit Zugriff auf das Computerkonto eines in die Domäne eingebundenen Computers den Domänencontroller aufrufen, um einen NTLM-Sitzungsschlüssel zu berechnen und sich dadurch als Server auszugeben.
DIE NTLM-basierte Authentifizierung ist standardmäßig deaktiviert, kann jedoch entweder durch Konfigurieren von SSL auf dem Zielserver oder durch Konfigurieren der WinRM TrustedHosts-Einstellung auf dem Client zulässig sein.
Verwenden von SSL-Zertifikaten zum Überprüfen der Serveridentität bei NTLM-basierten Verbindungen
Da das NTLM-Authentifizierungsprotokoll die Identität des Zielservers nicht sicherstellen kann (nur dass es Ihr Kennwort kennt), können Sie Zielserver für die Verwendung von SSL für PowerShell-Remoting konfigurieren. Das Zuweisen eines SSL-Zertifikats zum Zielserver (wenn von einer Zertifizierungsstelle ausgestellt wird, der der Client ebenfalls vertraut) ermöglicht die NTLM-basierte Authentifizierung, die sowohl die Benutzeridentität als auch die Serveridentität garantiert.
Ignorieren von NTLM-basierten Serveridentitätsfehlern
Wenn die Bereitstellung eines SSL-Zertifikats auf einem Server für NTLM-Verbindungen nicht möglich ist, können Sie die daraus resultierenden Identitätsfehler vermeiden, indem Sie den Server zur WinRM-TrustedHosts--Liste hinzufügen. Bitte beachten Sie, dass das Hinzufügen eines Servernamens zur Liste TrustedHosts nicht als Ausdruck der Vertrauenswürdigkeit der Hosts selbst betrachtet werden sollte, da das NTLM-Authentifizierungsprotokoll nicht garantieren kann, dass Sie tatsächlich die Verbindung mit dem Host herstellen, zu dem Sie eine Verbindung beabsichtigen. Stattdessen sollten Sie die Einstellung "TrustedHosts" als eine Liste von Hosts betrachten, für die Sie den Fehler unterdrücken möchten, der durch die fehlende Überprüfung der Identität des Servers entsteht.
Fortlaufende Kommunikation
Sobald die anfängliche Authentifizierung abgeschlossen ist, verschlüsselt winRM die laufende Kommunikation. Beim Herstellen einer Verbindung über HTTPS wird das TLS-Protokoll verwendet, um die Verschlüsselung auszuhandeln, die zum Transport von Daten verwendet wird. Beim Herstellen einer Verbindung über HTTP wird die Verschlüsselung auf Nachrichtenebene durch das verwendete anfängliche Authentifizierungsprotokoll bestimmt.
- Die Standardauthentifizierung stellt keine Verschlüsselung bereit.
- Die NTLM-Authentifizierung verwendet eine RC4-Verschlüsselung mit einem 128-Bit-Schlüssel.
- Die Verschlüsselung mithilfe der Kerberos-Authentifizierung wird durch den Wert für
etypeim TGS-Ticket bestimmt. Dies ist AES-256 auf modernen Systemen. - Die CredSSP-Verschlüsselung verwendet die TLS-Verschlüsselungssammlung, die im Handshakevorgang ausgehandelt wurde.
Durchführen des zweiten Hops
Standardmäßig verwendet PowerShell-Remoting Kerberos (sofern verfügbar) oder NTLM für die Authentifizierung. Beide Protokolle führen eine Authentifizierung gegenüber dem Remotecomputer durch, ohne Anmeldeinformationen an diesen zu senden. Dies ist die sicherste Methode zur Authentifizierung, da der Remotecomputer jedoch nicht über die Anmeldeinformationen des Benutzers verfügt, kann er nicht im Namen des Benutzers auf andere Computer und Dienste zugreifen. Dies ist als „zweites Hop-Problem“ bekannt.
Es gibt mehrere Möglichkeiten, dieses Problem zu vermeiden. Eine Beschreibung dieser Methoden mit ihren jeweiligen Vor- und Nachteilen finden Sie unter Making the second hop in PowerShell Remoting (Das zweite Hop-Problem in PowerShell Remoting).
