WinRM und PowerShell-Remoting härten

WinRM ist der Transport unter PowerShell-Remoting, winrs, Server-Manager, Windows Admin Center, JEA und Windows Event Forwarding. Es ist außerdem einer der meistgenutzten Kanäle für Lateral Movement, denn gültige Admin-Anmeldedaten plus offener Port 5985 bedeuten konstruktionsbedingt Remotecodeausführung. Der Leitfaden zur PowerShell-Sicherheit nennt die drei Basiseinstellungen. Dieser Leitfaden behandelt den Rest: was tatsächlich lauscht, wie man starke Authentifizierung erzwingt, wie man HTTPS ergänzt und wie man begrenzt, wer es erreichen kann.

Wissenswerte Standardwerte

Die sicheren Authentifizierungsstandards sind gut. Das Problem ist die Abweichung: Ein Herstellerinstaller, eine Fehlersuche oder ein im Internet gefundenes Skript schaltet Basic ein, setzt TrustedHosts auf * oder fügt auf jeder Schnittstelle einen Listener hinzu. Eine Richtlinie verhindert das.

Schritt 1: inventarisieren, was wirklich konfiguriert ist

Erfassen Sie auf einer Stichprobe von Servern und Arbeitsplätzen die Listener, Authentifizierungseinstellungen und Endpunkte:

winrm enumerate winrm/config/listener
Get-ChildItem WSMan:\localhost\Service\Auth
Get-ChildItem WSMan:\localhost\Client\Auth
Get-Item WSMan:\localhost\Service\AllowUnencrypted
Get-Item WSMan:\localhost\Client\TrustedHosts
Get-PSSessionConfiguration | Select-Object Name, Permission
Get-LocalGroupMember -Group 'Remote Management Users'

Achten Sie auf HTTP-Listener auf Arbeitsplätzen, die sie nicht brauchen, Kompatibilitäts-Listener auf den Ports 80 oder 443, ein nicht leeres TrustedHosts, Basic oder CredSSP auf true und unerwartete Mitglieder von Remote Management Users. Jeder in dieser Gruppe kann auf dem Rechner eine PowerShell-Remotesitzung öffnen, ohne Administrator zu sein.

Schritt 2: Authentifizierung und Verschlüsselung per GPO erzwingen

Unter Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Remote Management (WinRM):

WinRM Service

WinRM Client

Die Registrierungsäquivalente liegen unter HKLM\SOFTWARE\Policies\Microsoft\Windows\WinRM\Service und ...\WinRM\Client (zum Beispiel AllowBasic = 0, AllowUnencryptedTraffic = 0, DisableRunAs = 1). Die Sicherheitsbaselines von Microsoft und CIS setzen die meisten davon; erzwingen Sie sie dort, wo die Baselines nicht hinreichen.

CredSSP verdient eine Anmerkung. Meist wird es aktiviert, um den „Double Hop“ zu lösen (eine Remotesitzung, die eine Dateifreigabe erreichen muss). Bessere Lösungen sind die ressourcenbasierte eingeschränkte Delegierung, ein JEA-Endpunkt, der als gMSA läuft, oder die explizite Übergabe eines Anmeldeobjekts an den zweiten Befehl. Jede davon vermeidet, dass vollständige Anmeldedaten auf dem Zwischenserver zurückbleiben.

Schritt 3: Kerberos bevorzugen und reines Kerberos erwägen

Kerberos bietet gegenseitige Authentifizierung: Der Client weiß, dass er mit dem echten Server spricht. NTLM, auf das Negotiate zurückfällt, bietet das nicht und ist anfällig für NTLM relay. Negotiate fällt auf NTLM zurück, wenn Sie sich per IP-Adresse, mit einem Host außerhalb der Domäne oder mit einem Namen ohne SPN verbinden.

Drei Stufen mit zunehmender Strenge:

1. Per FQDN verbinden und TrustedHosts leer lassen. Clients verwenden dann für Domänenhosts Kerberos und verweigern über HTTP NTLM gegenüber nicht authentifizierten Servern.
2. NTLM domänenweit einschränken mit den Richtlinien zur NTLM-Überwachung und -Einschränkung, damit der Rückfall in den Protokollen sichtbar wird, bevor Sie ihn blockieren.
3. Negotiate auf Tier-0-Servern deaktivieren. Setzen Sie in der Richtlinie WinRM Service Disallow Negotiate authentication = Enabled. Clients müssen sich dann mit -Authentication Kerberos verbinden.

Enter-PSSession -ComputerName dc01.corp.example -Authentication Kerberos

Testen Sie Option 3 sorgfältig. Server-Manager, Windows Admin Center und viele Skripte verwenden standardmäßig Negotiate und schlagen fehl, bis sie umkonfiguriert sind.

Schritt 4: HTTPS-Listener ergänzen, wo sie gebraucht werden

HTTPS ergänzt zertifikatbasierte Serverauthentifizierung und TLS. Sie brauchen es für Hosts außerhalb der Domäne und Arbeitsgruppenserver, über Gesamtstrukturen ohne Vertrauensstellungen hinweg und überall dort, wo eine Richtlinie TLS auf der Leitung verlangt. Stellen Sie über Ihre interne Zertifizierungsstelle ein Zertifikat mit der EKU Server Authentication und dem FQDN des Hosts im Subject oder SAN aus, idealerweise per automatischer Registrierung. Dann:

$fqdn = [System.Net.Dns]::GetHostEntry($env:COMPUTERNAME).HostName
$cert = Get-ChildItem Cert:\LocalMachine\My |
  Where-Object { $_.Subject -eq "CN=$fqdn" -and $_.EnhancedKeyUsageList.FriendlyName -contains 'Server Authentication' } |
  Sort-Object NotAfter -Descending | Select-Object -First 1

New-Item -Path WSMan:\localhost\Listener -Transport HTTPS -Address * `
  -CertificateThumbPrint $cert.Thumbprint -Force

Clients verbinden sich mit -UseSSL. Verwenden Sie außerhalb eines Labors keine selbstsignierten Zertifikate mit -SkipCACheck und -SkipCNCheck: Damit werfen Sie genau die Serverauthentifizierung weg, für die Sie HTTPS eingeführt haben.

Der Listener ist an einen Fingerabdruck gebunden und folgt der Zertifikatserneuerung nicht. Aktualisieren Sie ihn nach jeder Erneuerung über Ihr Konfigurationsmanagement:

Set-WSManInstance -ResourceURI winrm/config/Listener `
  -SelectorSet @{ Address = '*'; Transport = 'HTTPS' } `
  -ValueSet @{ CertificateThumbprint = $cert.Thumbprint }

Sobald jedes Management-Werkzeug HTTPS nutzt, können Sie den HTTP-Listener auf sensiblen Servern entfernen. Lassen Sie ihn dort bestehen, wo Collectoren für Windows Event Forwarding oder Werkzeuge noch von Port 5985 abhängen.

Schritt 5: begrenzen, wer WinRM erreichen kann

Die wirksamste WinRM-Maßnahme ist keine WinRM-Einstellung, sondern die Host-Firewall. Nur Jump-Server, Privileged Access Workstations und Managementserver müssen 5985/5986 erreichen.

• Ersetzen Sie in der Firewall-GPO die integrierte Regel Windows Remote Management (HTTP-In) durch Regeln, deren Remoteadresse Ihre Managementsubnetze sind, für 5985 wie für 5986. Siehe Härtung der Windows-Firewall und Firewallrichtlinien im großen Maßstab verwalten.
• Blockieren Sie auf Arbeitsplätzen eingehendes WinRM vollständig, sofern kein bestimmtes Werkzeug es braucht.
• Verlassen Sie sich dafür nicht auf Allow remote server management through WinRM. Deren IPv4/IPv6-Filter steuert, an welche lokalen Adressen der Listener gebunden wird, nicht welche Remoteclients sich verbinden dürfen.

Beschränken Sie außerdem, wer sich authentifizieren kann, sobald er es erreicht. Halten Sie Remote Management Users leer oder streng kontrolliert, und denken Sie daran, dass lokale Administratorkonten den UAC-Remoteeinschränkungen unterliegen. Lassen Sie diese Einschränkungen aktiv, wie unter UAC und Administratorschutz beschrieben.

Endpunktberechtigungen

Jeder Remoting-Endpunkt hat eine eigene Sicherheitsbeschreibung. Get-PSSessionConfiguration zeigt sie an. Die Standardendpunkte (microsoft.powershell, microsoft.powershell32 und, sofern installiert, PowerShell.7) erlauben Administrators und Remote Management Users. Hersteller registrieren manchmal zusätzliche Endpunkte mit weiter gefassten Berechtigungen, und JEA-Endpunkte definieren ihre eigenen über Rollendefinitionen. Prüfen Sie die Liste nach jedem Software-Rollout, entfernen Sie ungenutzte Endpunkte mit Unregister-PSSessionConfiguration und behandeln Sie einen neu auftauchenden Endpunkt auf einem Server als Konfigurationsänderung, die einen Verantwortlichen braucht. Auf sensiblen Servern, auf denen niemand volles Remoting nutzen soll, können Sie die Standardendpunkte mit Set-PSSessionConfiguration -SecurityDescriptorSddl auf eine dedizierte Tier-0-Admin-Gruppe beschränken und für alles andere JEA-Endpunkte veröffentlichen.

Was kaputtgeht

• Server-Manager und Windows Admin Center scheitern an Hosts, auf denen Negotiate deaktiviert oder nur HTTPS verfügbar ist, bis sie auf Kerberos oder HTTPS eingestellt sind.
• Skripte, die sich per IP-Adresse verbinden, funktionieren mit leerem TrustedHosts nicht mehr. Das ist beabsichtigt; stellen Sie sie auf Namen um.
• Double-Hop-Abläufe, die sich auf CredSSP stützten, brechen. Verlagern Sie sie auf eingeschränkte Delegierung oder einen gMSA-gestützten JEA-Endpunkt.
• Die Ereignisweiterleitung stoppt, wenn Sie den WinRM-Dienst auf den Quellen deaktivieren oder 5985 auf dem Collector per Firewall sperren. Siehe Windows Event Forwarding im großen Maßstab.
• Abgelaufene Zertifikate legen HTTPS-Listener stillschweigend lahm. Überwachen Sie den Ablauf der Listener-Zertifikate.

Überprüfen

# Richtlinie angewendet?
Get-Item WSMan:\localhost\Service\AllowUnencrypted          # false
Get-ChildItem WSMan:\localhost\Service\Auth                  # Basic false, CredSSP false
Get-Item WSMan:\localhost\Client\TrustedHosts                # leer

# Kerberos und HTTPS funktionieren von einem Managementhost aus
Test-WSMan -ComputerName srv01.corp.example -UseSSL
Invoke-Command -ComputerName srv01.corp.example -UseSSL -ScriptBlock { hostname }

# Von einem normalen Arbeitsplatz aus blockiert (sollte in ein Timeout laufen)
Test-NetConnection srv01.corp.example -Port 5985

Für die Erkennung zeigen sich Remotesitzungen als wsmprovhost.exe-Prozesse auf dem Ziel (4688 oder Sysmon 1), als Netzwerkanmeldungen (4624 Typ 3) und als Einträge in Microsoft-Windows-WinRM/Operational. Alarmieren Sie bei WinRM-Sitzungen zu Servern, die nicht aus Ihren Managementsubnetzen stammen, und bei Änderungen an der WinRM-Konfiguration außerhalb Ihres Änderungsprozesses. Die Themenseite PowerShell-Sicherheit bündelt die zugehörigen Leitfäden, einschließlich JEA, um einzuschränken, was diese Sitzungen tun dürfen.

Checkliste

• Listener, Authentifizierungseinstellungen, TrustedHosts und Endpunktberechtigungen inventarisiert
• Basic, unverschlüsselter Verkehr, CredSSP und Digest per GPO deaktiviert (Dienst und Client)
• Speichern von RunAs-Anmeldedaten verboten; Kompatibilitäts-Listener aus
• TrustedHosts leer; Verbindungen per FQDN mit Kerberos
• Negotiate auf Tier-0-Servern nach Tests deaktiviert
• HTTPS-Listener mit von der Zertifizierungsstelle ausgestellten Zertifikaten, wo nötig; Fingerabdruck bei Erneuerung aktualisiert
• Eingehendes 5985/5986 nur aus Managementsubnetzen zugelassen
• Mitgliedschaft in Remote Management Users überprüft
• Erkennungen für WinRM-Sitzungen und Konfigurationsänderungen eingerichtet