Wenn die meisten Menschen „WinRM über HTTP“ hören, gehen sie sofort davon aus, dass dies eine Sicherheitskatastrophe ist, die nur darauf wartet, sich zu ereignen. Schließlich wird uns seit Jahren eingetrichtert, dass HTTP schlecht und HTTPS gut ist.
In der Praxis ist die Verwendung des Windows Remote Management (WinRM)-Protokolls jedoch nicht ganz so eindeutig. In vielen Umgebungen ist HTTP nicht wesentlich unsicherer als HTTPS.
Das Missverständnis bezüglich der Verschlüsselung:
Ist WinRM über HTTP von Natur aus unsicher?
Das größte Missverständnis ist, dass WinRM Daten unverschlüsselt über HTTP überträgt. Das ist nicht der Fall.
Standardmäßig verwendet WinRM die Kerberos- oder NT LAN Manager (NTLM)-Authentifizierung, und die Geheimnisse dienen dazu, die Nutzdaten der Nachricht auf der Anwendungsebene zu verschlüsseln, unabhängig vom Transportprotokoll.
Bei WinRM dient HTTP lediglich als Transportkanal; die Verschlüsselung und Authentifizierung erfolgen auf der darüber liegenden Anwendungsebene. Ein Angreifer, der Ihr Netzwerk abhört, kann weder Ihren Befehl noch die Ausgabe sehen. Er ist auch nicht in der Lage, die Authentifizierung gegenüber dem WinRM-HTTP-Endpunkt weiterzuleiten.
WinRM wurde unter Berücksichtigung dieser Trennung entwickelt und unterscheidet sich damit grundlegend von beispielsweise einer über HTTP betriebenen Website, bei der die Nutzdaten tatsächlich im Klartext übertragen werden.
Was bringt HTTPS eigentlich?
HTTPS verschlüsselt die gesamte Verbindung mit Transport Layer Security (TLS), was zwei zusätzliche Garantien bietet:
- Verschlüsselung auf Transportschicht
- zertifikatsbasierte Serverauthentifizierung
Angesichts der in WinRM integrierten Nachrichtenverschlüsselung ist die Verschlüsselung auf Transportschicht weitgehend überflüssig.
Die Zertifikatsüberprüfung ist von großem Nutzen. Sie bietet Ihnen eine höhere Sicherheit, dass Sie tatsächlich mit dem Gerät kommunizieren, mit dem Sie glauben, zu kommunizieren, was zum Schutz vor bestimmten Man-in-the-Middle-Angriffen (MiTM) in nicht vertrauenswürdigen Netzwerken beiträgt.
In einem gut verwalteten internen Netzwerk mit angemessenen DNS- und Active Directory (AD)-Kontrollen werden solche Bedrohungen jedoch bereits durch andere Maßnahmen erheblich gemindert.
Wenn WinRM über HTTP durchaus sinnvoll ist
In einer domänengebundenen Umgebung bietet WinRM über HTTP drei Funktionen, die für eine sichere Fernverwaltung tatsächlich von Bedeutung sind:
- Integrität der Nachricht
- Nachrichtenverschlüsselung und eine
- Ein gewisses Maß an gegenseitiger Authentifizierung, sofern Kerberos verwendet wird
Ein wichtiger Hinweis: Die Basisauthentifizierung sollte stets deaktiviert sein – was standardmäßig auch der Fall ist.
Die Basisauthentifizierung übermittelt Anmeldedaten ohne wirklichen Schutz und wäre die einzige echte Sicherheitslücke von WinRM über HTTP, wenn sie aktiviert bliebe. Stellen Sie daher sicher, dass sie deaktiviert bleibt.
In vielen etablierten Unternehmensumgebungen wird WinRM intern über HTTP ausgeführt, ohne dass dies mit einem nennenswerten erhöhten Risiko verbunden ist. Darüber hinaus kann der administrative Aufwand für die Verwaltung von HTTPS-Zertifikaten bei unsachgemäßer Handhabung sogar Risiken mit sich bringen; abgelaufene Zertifikate, falsch konfigurierte Zertifizierungsstellen und fehlerhafte Automatisierungspipelines sind reale Probleme, die bei HTTP vollständig vermieden werden.
Wann sollten Sie HTTPS verwenden? Lesen Sie dies zuerst
HTTPS ist die richtige Wahl, wenn Sie über nicht vertrauenswürdige Netzwerke arbeiten.
Wenn Sie WinRM jedoch über HTTPS einsetzen, ohne ein Channel Binding Token (CBT) ordnungsgemäß zu konfigurieren, kann dies dazu führen, dass Sie in einer schlechteren Sicherheitslage sind als bei HTTP.
CBT bindet den Authentifizierungs-Handshake an den jeweiligen TLS-Kanal und verhindert so, dass ein Angreifer abgefangene Anmeldedaten weiterleitet, um sich im Namen des betroffenen Benutzers bei WinRM zu authentifizieren.
HTTPS ohne CBT kann ein falsches Gefühl der Sicherheit vermitteln. Die Verbindung ist zwar verschlüsselt, doch die Authentifizierung kann weiterhin weitergeleitet werden, was eine kritische Sicherheitslücke darstellt. Ohne CBTs bleiben die Kerberos- und NTLM-Authentifizierung über TLS anfällig für Relay-Angriffe.
Im Gegensatz dazu ist WinRM über HTTP davon nicht in gleicher Weise betroffen, da der Datenverkehr durch WinRM mithilfe der Authentifizierungsdaten des Benutzers geschützt wird.
Glücklicherweise aktiviert Windows CBTs standardmäßig im „Relaxed“-Modus, was in den meisten Fällen Schutz bietet.
C:>winrm get winrm/config/service/auth
Auth
Basic = false
Kerberos = true
Negotiate = true
Certificate = false
CredSSP = false
CbtHardeningLevel = Relaxed
Es wird jedoch empfohlen, CBTs ausdrücklich auf „Strict“ zu setzen.
C:>winrm set winrm/config/service/auth @{CbtHardeningLevel="Strict"}
Dadurch wird sichergestellt, dass nur Authentifizierungsversuche akzeptiert werden, die ordnungsgemäß an den TLS-Kanal gebunden sind – wodurch die Angriffsfläche für Relay-Angriffe effektiv geschlossen wird.
Das Fazit: Entscheiden Sie sich bewusst für WinRM über HTTP
Sicherheitsentscheidungen sollten auf tatsächlichen Bedrohungsszenarien basieren und nicht auf reflexartigen Protokollpräferenzen.
In einer Domänenumgebung mit Kerberos ist WinRM über HTTP keine unüberlegte Konfiguration. HTTPS ist in nicht vertrauenswürdigen Netzwerken die bessere Wahl, jedoch nur, wenn Sie es korrekt konfigurieren. Eine HTTPS-Bereitstellung, bei der CBTs nicht mindestens auf die Standardeinstellung „Relaxed“ – oder idealerweise auf „Strict“ – gesetzt sind, ist wohl gefährlicher als HTTP, da sie ein falsches Vertrauen schafft und gleichzeitig einen kritischen Authentifizierungs-Relay-Vektor offen lässt.
Machen Sie sich mit der Funktionsweise Ihres Authentifizierungsprotokolls vertraut. Machen Sie sich mit der Vertrauensstruktur Ihres Netzwerks vertraut.
