Windows: Zugang zum WSUS über WAN reglementieren

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

stunnel: Authentication

Microsoft – MSDN – Configure Automatic Updates using Registry Editor

WSUS.DE – HowTo > AU-Client Registry Key

Windowspage – Tipps – Windows-Update – Keine Verbindung zu Update-Internetdiensten bei Intranetserver erlauben

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.