[English]Mit dem kumulativen Update vom September 2020 für Windows 10 hat Microsoft Änderungen eingeführt, die die Sicherheit von Clients verbessern, die Windows Server Update Services (WSUS) auf Updates scannen. Hier eine kurze Übersicht zu diesem Thema.
Anzeige
Ich bin über diesen Tweet auf das Thema aufmerksam geworden – Microsoft hat diesen Techcommunity-Artikel zu diesem Thema veröffentlicht.
Standardmäßig sicher: TLS-Protokoll/HTTPS Pflicht
Ab dem kumulativen September 2020 Update werden HTTP-basierte Intranet-Server standardmäßig sicher sein. Um sicherzustellen, dass Clients inhärent sicher bleiben, erlaubt Microsoft nun HTTP-basierten Intranet-Servern nicht mehr, standardmäßig Benutzer-Proxys zur Erkennung von Aktualisierungen zu nutzen.
In einer WSUS-Umgebung, die nicht mit dem TLS-Protokoll/HTTPS gesichert ist, und in der ein Gerät einen Proxy benötigt, um erfolgreich eine Verbindung zu Intranet-WSUS-Servern herzustellen – und dieser Proxy ist nur für Benutzer (nicht für Geräte) konfiguriert – dann werden alle WSUS Scans auf Updates ab dem kumulativen Update vom September 2020 fehlschlagen.
Anzeige
Empfehlungen für mehr Sicherheit
Um die Sicherheit der WSUS-Infrastruktur zu gewährleisten, empfiehlt Microsoft die Verwendung des TLS/SSL-Protokolls zwischen den Geräten und den WSUS-Servern. Das Microsoft Update-System (einschließlich WSUS) stützt sich auf zwei Arten von Inhalten: Update-Nutzdaten und Update-Metadaten.
Update-Payloads sind die Datendateien, die die Software-Update-Komponenten enthalten, aus denen das Update besteht. Update-Metadaten sind alle Informationen, die das Microsoft Update-System über die Updates wissen muss, einschließlich der Informationen, welche Updates verfügbar sind, auf welche Geräte jedes Update angewendet werden kann und wo die Payloads für jedes Update abgerufen werden können. Beide Arten von Inhalten sind von entscheidender Bedeutung, und beide müssen geschützt werden, damit Ihre Computer sicher und auf dem neuesten Stand bleiben.
Update-Nutzdaten werden durch verschiedene Mittel vor Änderungen geschützt, einschließlich der Überprüfung digitaler Signaturen und kryptografischer Hash-Verifizierungen. HTTPS bietet eine ordnungsgemäße Chain of Custody, mit der der Kunde nachweisen kann, dass die Daten vertrauenswürdig sind.
Wenn ein Gerät Updates direkt von Microsoft Update erhält, erhält dieses Gerät Update-Metadaten direkt von Microsoft-Servern. Diese Metadaten werden immer über HTTPS übertragen, um Manipulationen zu verhindern. Wenn Sie WSUS oder Configuration Manager zur Verwaltung der Updates Ihrer Organisation verwenden, werden die Update-Metadaten über eine Kette von Verbindungen von Microsoft-Servern zu Geräten übertragen. Jede dieser Verbindungen muss vor böswilligen Angriffen geschützt werden.
Ein WSUS-Server verbindet sich mit Windows Update-Servern und empfängt Update-Metadaten. Diese Verbindung verwendet immer HTTPS, und die HTTPS-Sicherheitsfunktionen schützen die Metadaten vor Manipulationen. Sind mehrere WSUS-Server in einer Hierarchie angeordnet, erhalten die nachgeschalteten Server Metadaten von den vorgeschalteten Servern.
Hier besteht die Wahl: Es können für diese Metadatenverbindungen HTTP oder HTTPS verwendet werden. Die Verwendung von HTTP unterbricht jedoch die Vertrauenskette und macht das Ganze anfällig für Angriffe. Durch die Verwendung von HTTPS kann der WSUS-Server beweisen, dass er den Metadaten vertraut, die er vom vorgeschalteten WSUS-Server erhält.
Um die Vertrauenskette aufrechtzuerhalten und Angriffe auf Ihre Client-Computer zu verhindern, müssen Administratoren sicherstellen, dass alle Metadatenverbindungen innerhalb ihrer Organisationen – die Verbindungen zwischen den vor- und nachgeschalteten WSUS-Servern und die Verbindungen zwischen den WSUS-Servern und Ihren Client-Computern – gegen Angriffe verteidigt werden. Zu diesem Zweck empfieht Microsoft dringend, das WSUS-Netzwerk so zu konfigurieren, dass diese Verbindungen über HTTPS geschützt sind.
Weitere Informationen finden Sie in Michael Curetons Post Security Best Practices für Windows Server Update Services (WSUS). In Techcommunity-Artikel gibt Microsoft weitere Hilfestellungen zur Konfigurierung des Update-Scans.
Ergänzung: Es kam die Frage auf, für welche Windows-Versionen das obige gilt. Die Antwort findet sich im Beitrag Windows 7-10: WSUS muss demnächst https unterstützen.
Anzeige
siehe auch:
https://support.microsoft.com/en-us/help/4569557/windows-update-sha-1-based-endpoints-discontinued
Danke an Andrei!
Nachtrag: das in der Microsoft PKI hinterlegte Webserver Template ist nicht sicher.
BSI empfiehlt die Nutzung von KSP ECDH_256 und einem Hash von 512 bit, Signatur SHA-2(56)
Default ist KSP RSA 2048 Schlüssellänge 256 bit Signatur SHA-2(56). Auf alten PKIs sogar noch CSP statt KSP.
https://devblogs.microsoft.com/scripting/migrate-windows-ca-from-csp-to-ksp-and-from-sha-1-to-sha-256-part-1/
Ebenfalls kann das alte Template kein Auto-Rollout / Renewal und auch der notwendige SAN Name (DNS) fehlt, um von Browsern akzeptiert zu werden.
Schade, dass Microsoft dies alles verrotten lässt und die Templates noch auf 2000/2003 ausgelegt sind.
Leider funktioniert Citrix nicht mit ECDH Schlüsseln, WSUS / supportete Windows Clients schon.
Was genau funktioniert bei Citrix nicht mit ECDH? Welche Dienste o.ä.?
Habe ich das richtig verstanden: solange ich im Intranet zwischen Client und WSUS keinen Proxy einsetze braucht mich das nicht zu interessieren?
Ja genau.
Es betritt nur WSUS Server die mit HTTP laufen und zwischen Client und Server einen Proxy benutzen.
und der WSUS sollte sowieso nur mit TLS verwendet werden.
Die Info gibt es schon seit Jahren
https://www.heise.de/newsticker/meldung/Black-Hat-Schadsoftware-per-Windows-Update-mit-WSUS-2775156.html
oh, danke, das ist an mir vorbeigegangen. Ich dachte immer, dass die Sicherheit durch signierte Pakete ausreiche.
Hab's gerade eingestellt. Ein Rechner lädt darüber – mal sehen, ob die anderen auch klappen.