Die Windows Server Update Services (WSUS) bieten im Microsoft-Netzwerk eine recht bequeme und zuverlässige Möglichkeit, Aktualisierungen für die Produkte aus Redmond zu verteilen. Grundsätzlich lässt sich dieser Dienst auch zum WAN hin betreiben um z.B. Außendienst-Mitarbeiter anzubinden.
Leider unterstützt der Windows Update-Client keine Authentifizierung, so das seitens der verwendeten Internet Information Services (IIS) theoretisch die Möglichkeiten über die Computeranmeldung oder Client-seitige Zertifikate bliebe. Erstgenanntes funktioniert nur in der Domäne, letztgenanntes setzt eine Zertifizierungstelle (CA) und die Verteilung von Zertifikaten voraus.
Microsoft TechNet – Secure WSUS 3.0 Deployment
Liest man zur Nutzung der Zertifikate allerdings das Kommentar von Lawrence Garvin kommen einem schnell Zweifel, ob das funktioniert:
"At a minimum you'd need to use some form of reverse-proxy with authentication, or client-side SSL certificates -- the WUAgent in combination wiht WinHTTP does support authenticated proxy connectivity. The SSL certs scenario is a theoretical solution, I've not actually heard of anybody who has successfully implemented client-side SSL certificates in a WSUS environment."
Quelle: Microsoft TechNet Forum – WSUS updates for external users
Wie Lawrence schreibt, könnte auch ein Reverse Proxy mit Authentifizierung verwendet werden. Leider habe ich dazu keine detailierten Informationen gefunden und ob es überhaupt auf die Dauer stabil läuft. Der Lesart über verschiedene Treffer via Suchmaschine nach scheint es da gerne Schwierigkeiten zu geben.
Ein weiterer Ansatz kann sein, den Zugang über VPN zu realisieren. Das setzt wiederum neben der nötigen Infrastruktur voraus, dass regelmässig oder automatisch eine VPN-Verbindung hergestellt wird und es zu keinen Konflikt mit den verwendeten IP-Netzen kommt. Noch eine Möglichkeit, und das ist sozusagen des Pudels Kern dieses Beitrags, bietet stunnel an. Dies geht zum einen mittels Zertifikaten oder schneller und einfacher ab Version 5.09 mit Pre-Shared Key (PSK).
stunnel-Server einrichten
Die Server-seite von stunnel kann, muss aber nicht auf dem gleichen System wie der WSUS laufen. Für diesen Beitrag wurde stunnel auf dem gleichen System installiert.
Zunächst die Installationsdatei herunterladen, diese Ausführen und dem Assistenten folgen. Da es gerne zu Schwierigkeiten kommen kann, wenn nach “C:\Program Files (x86)” installiert wird, sollte dies zu “C:\stunnel” geändert werden. Beim Erstellen des Zertifikats kann irgendetwas eingetragen werden, dieses wird im weiteren Verlauf nicht verwendet.
Direkt nach der Installation wird stunnel als Anwendung gestartet und kann durch einen Rechtsklick auf das Infobereichssymbol und “Exit” beendet werden. Die Desktop-Verknüpfung “stunnel AllUsers” startet dieses wieder als Anwendung und sollte im weiteren Verlauf nicht verwendet bzw. besser entfernt werden.
Bevor mit der eigentlichen Konfiguration begonnen wird, kann man den Stand nach der Installation zunächst sichern. Dazu einfach den Ordner “C:\stunnel\config” kopieren. Man könnte nun die vorhandene “stunnel.conf” anpassen. Einfacher und übersichtlicher ist es, eine eigene “stunnel.conf” zu erstellen:
; *** Logging *** debug = info output = stunnel.log ; *** Services *** [WSUS-http] accept = 8532 connect = 127.0.0.1:8530 ciphers = PSK PSKsecrets = secrets.txt [WSUS-https] accept = 8533 connect = 127.0.0.1:8531 ciphers = PSK PSKsecrets = secrets.txt
PSK erzeugen
Den Pre-Shared Key kann man manuell oder per Befehl bzw. Skript erzeugen. stunnel bringt für letzteres alles benötigte mit, so das sich mit einem kleinen Skript dies einfach handhaben lässt:
@echo off set openssl_conf=C:\stunnel\config\openssl.cnf set RANDFILE=C:\stunnel\config\.rnd echo. C:\stunnel\bin\openssl.exe rand -hex 32 echo. pause
Der PSK kann zusammen mit einem Benutzernamen dann bequem in die “secrets.txt” eingefügt werden:
BENUTZERNAME:PSK
Auf der Server-seite befinden sich alle Benutzernamen samt PSK in dieser Datei, auf der Client-seite nur der jeweilige Benutzer mit seinem PSK. Damit der neue oder geänderte Benutzer übernommen wird, entweder einmal die Konfigurationsdatei neu laden (entweder um das Startmenü oder “stunnel.exe -reload”) oder den Dienst “stunnel TLS wrapper” (Dienstname “stunnel”) neustarten.
Dienst installieren und starten
Aus dem Startmenü “stunnel Service install” anklicken um den Dienst einzurichten. Über “stunnel Service start” kann der Dienst gestartet werden.
In einer Eingabeaufforderung geht dies mittels
stunnel.exe -install stunnel.exe -start
Firewall konfigurieren
Je nach Konfiguation bzw. Anspruch benötigt der WSUS per Vorgabe die Ports 8530/tcp für http und 8531/tcp für https (sofern konfiguriert). Entsprechend der Konfiguration bei stunnel müssen die entsprechenden Ports, 8532/tcp für http bzw. 8533/tcp für https, oder schlicht die “stunnel.exe” in der Firewall freigeschaltet bzw. weitergeleitet werden.
In der Windows-Firewall werden automatisch bei der Installation des WSUS die Standard-Ports eingerichtet. Soll dieser nun nur noch via stunnel erreicht werden können, sollte man die entsprechenden Regeln deaktivieren. Parallel dazu kann man im IIS einstellen, das z.B. nur auf “localhost” (“127.0.0.1” bzw. “::1”) gelauscht wird.
stunnel-Client einrichten
Die stunnel.conf auf der Client-Seite kann z.B. so aussehen:
; *** Services *** [WSUS-http] client = yes accept = 127.0.0.1:8530 connect = <Server/IP>:8532 ciphers = PSK PSKsecrets = secrets.txt [WSUS-https] client = yes accept = 127.0.0.1:8531 connect = <Server/IP>:8533 ciphers = PSK PSKsecrets = secrets.txt
Der Client liese sich ebenso einrichten, wie der Server, d.h. Setup herunterladen, ausführen usw. Praktischer kann sein, alle benötigte Dateien zusammenzustellen und ggf. per Skript zu verteilen bzw. zu installieren.
Windows Update auf dem Client konfigurieren
Die notwendigen Einstellungen lassen sich per lokale oder domänen-weite Gruppenrichtlinie oder in der Registry vornehmen. Anbei die minimalsten Änderungen für die Registry:
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate] "WUServer"="http://127.0.0.1:8530" "WUStatusServer"="http://127.0.0.1:8530" "TargetGroupEnabled"=dword:00000001 "TargetGroup"="TEST" "DoNotConnectToWindowsUpdateInternetLocations"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU] "UseWUServer"=dword:00000001
Dem Client wird so mitgeteilt, das der WSUS als Updatequelle dient, die restlichen Einstellungen entsprechen den Vorgaben von Microsoft. Einzige Abweichungen sind:
"TargetGroup"="TEST"
Die Client-seitigen Zuordnung des Clients zu einer Gruppe im WSUS, sofern dies auf dem Server aktiviert ist. Ansonsten kann man diese Zeile weg lassen und schiebt den Computer per Hand in die passende Gruppe.
"DoNotConnectToWindowsUpdateInternetLocations"=dword:00000001
Seit Windows 8.x kann man damit regeln, ob jenseits vom WSUS auch direkt bei Microsoft nach Updates gesucht wird. Ein Equivalent zu anderen Windows-Versionen existiert ebenfalls, siehe dazu das MSDN-Link in den Quellen.
Quellen
Microsoft – MSDN – Configure Automatic Updates using Registry Editor
WSUS.DE – HowTo > AU-Client Registry Key
Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.
Artikel (RSS)
XING
Schreibe einen Kommentar