7
WSUS - externe Veröffentlichung
Hallo,
folgender Sachverhalt:
Wir betreibenen einen WSUS-Server in unserer Zentrale und zwei weitere Downstreamserver innerhalb des LANs an Remote-Standorten, sowohl interne als auch via VPN angebundene Clients verbinden sich problemlos mit den WSUS-Servern. Zusätzlich zu den Microsoft-Updates verteilen wir mittels WSUS Package Publisher (WPP) Drittanbieter-Updates über den WSUS-Server, beispielsweise Adobe Reader, Firefox, Jave, etc.
Nun haben wir auch Clients, die keinen VPN-Zugang besitzen oder diesen nicht nutzen und die für längere Zeit nicht im Firmennetzwerk sind. Auch diese Clients sollen zentral Updates versorgt werden und dabei möglichst nicht ungesteuert über Microsoft, sondern auch über den WSUS-Server und inklusive der WPP-Updates (also nicht nur Berichterstattung und dann Download bei Microsoft).
Die naheliegendste Möglichkeit ist einen weiteren WSUS-Server als Downstream-Server in die DMZ zu stellen, dort SSL zu aktivieren (interne CA ist vorhanden) und den entsprechenden Port freizugeben. Hierzu stellen sich für mich folgende Fragen:
1. Wie kann ich verhindern, dass nicht jeder beliebige Client versucht zu mit dem WSUS-Server zu verbinden? Da WSUS ja grundsätzlich ohne Authentifizierung läuft, wäre der Server aus meiner theoretisch für jeden verfügbar. Oder gibt es da Einschränkungsmöglichkeiten?
2. Ist Split-Brain-DNS mittel der Wahl, oder kann gibt die Möglichkeit einen Failoverserver einzustellen? In den GPOs sehe ich da erstmal keine Möglichkeit, der alternative Downloadsrver ist meine Wissens für einen anderen Zweck.
3. Aktuell wird weder für die Client-Server- noch für die Replikat-Konfiguration SSL verwendet, ist das unabhängig voneinander?
Ich weiß, dass das Thema WSUS und externer Zugriff immer mal wieder thematisiert wird, ich hab jedoch auf meine konkreten Fragen keine Antworten gefunden.
Vielen Dank vorab!
folgender Sachverhalt:
Wir betreibenen einen WSUS-Server in unserer Zentrale und zwei weitere Downstreamserver innerhalb des LANs an Remote-Standorten, sowohl interne als auch via VPN angebundene Clients verbinden sich problemlos mit den WSUS-Servern. Zusätzlich zu den Microsoft-Updates verteilen wir mittels WSUS Package Publisher (WPP) Drittanbieter-Updates über den WSUS-Server, beispielsweise Adobe Reader, Firefox, Jave, etc.
Nun haben wir auch Clients, die keinen VPN-Zugang besitzen oder diesen nicht nutzen und die für längere Zeit nicht im Firmennetzwerk sind. Auch diese Clients sollen zentral Updates versorgt werden und dabei möglichst nicht ungesteuert über Microsoft, sondern auch über den WSUS-Server und inklusive der WPP-Updates (also nicht nur Berichterstattung und dann Download bei Microsoft).
Die naheliegendste Möglichkeit ist einen weiteren WSUS-Server als Downstream-Server in die DMZ zu stellen, dort SSL zu aktivieren (interne CA ist vorhanden) und den entsprechenden Port freizugeben. Hierzu stellen sich für mich folgende Fragen:
1. Wie kann ich verhindern, dass nicht jeder beliebige Client versucht zu mit dem WSUS-Server zu verbinden? Da WSUS ja grundsätzlich ohne Authentifizierung läuft, wäre der Server aus meiner theoretisch für jeden verfügbar. Oder gibt es da Einschränkungsmöglichkeiten?
2. Ist Split-Brain-DNS mittel der Wahl, oder kann gibt die Möglichkeit einen Failoverserver einzustellen? In den GPOs sehe ich da erstmal keine Möglichkeit, der alternative Downloadsrver ist meine Wissens für einen anderen Zweck.
3. Aktuell wird weder für die Client-Server- noch für die Replikat-Konfiguration SSL verwendet, ist das unabhängig voneinander?
Ich weiß, dass das Thema WSUS und externer Zugriff immer mal wieder thematisiert wird, ich hab jedoch auf meine konkreten Fragen keine Antworten gefunden.
Vielen Dank vorab!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 505347
Url: https://administrator.de/contentid/505347
Printed on: April 25, 2024 at 00:04 o'clock
7 Comments
Latest comment
Hi
Optionen > Update Files and Languages > Do not store update files locally
Dann holt der Client sich diese Updates vom MS Server
1. Wie kann ich verhindern, dass nicht jeder beliebige Client versucht zu mit dem WSUS-Server zu verbinden? Da WSUS ja grundsätzlich ohne Authentifizierung läuft, wäre der Server aus meiner theoretisch für jeden verfügbar. Oder gibt es da Einschränkungsmöglichkeiten?
Wenn ihr Client zertifikate ausgerollte habt, könnte man das damit machen.2. Ist Split-Brain-DNS mittel der Wahl
JaIn den GPOs sehe ich da erstmal keine Möglichkeit
Naja du kannst natürlich 2 GPOs machen die auf unterschiedliche OUs/Computergruppen zielen. Definiere interne und externe Geräte und gib denen unterschiedliche URLs mit. Aber SplitbrainDNS ist da natürlich einfacher.3. Aktuell wird weder für die Client-Server- noch für die Replikat-Konfiguration SSL verwendet, ist das unabhängig voneinander?
Technisch ja. Aber warum nicht? Das ist ein Haken und ein paar Sekunden editieren in der GPO ...Ich weiß, dass das Thema WSUS und externer Zugriff immer mal wieder thematisiert wird, ich hab jedoch auf meine konkreten Fragen keine Antworten gefunden.
Nur damit das nicht untergeht: Der externe WSUS kann so eingestellt werden, das er zwar die Updates authorisiert, aber keinen DL anbietet.Optionen > Update Files and Languages > Do not store update files locally
Dann holt der Client sich diese Updates vom MS Server
Hi!
Client-Zertifikate sind ausgerollt, da u.a. auch 802.1x für WLAN verwendet wird. Ist das dann eine reine IIS-Funktionalität, die unabhängig von WSUS eine Client-Authentifizierung mit Zertifikat am WSUS erfordert? Gibt es dazu ein Howto? Bisher bin ich davon ausgegangen, dass die Aktivierung von SSL beim WSUS nur dafür sorgt, dass die Kommunikation zwischen Client und Server verschlüsselt ist. Hierzu benötigt der Client ja naturgemäß kein eigenes Zertifiakt sondern muss nur der ausstellenden CA vertrauen.
Für uns ist in der Konstallation problematisch, dass wir die WSUS-Gruppenzuordnung manuell und nicht über clientseitige Zielzuordnung via GPO machen. Der Grund hierfür ist, dass wir WPP nutzen und verschiedenen WSUS-Gruppen benötigen (z.B. nur Windows Updates, Firefox, Adobe, Java, Flash, ...) und dies nur sehr schwer bis garnicht über Organisationseinheiten und den zugeordneten GPOs abbilden könnten. Wenn die Clients sich nun von Extern am DMZ-WSUS melden, dann sind diese nicht zugeordnet und müssten dann dort zusätzlich einsoritert werden. Soweit ich das sehe gibt es keinen Mechanismus, der die WSUS-Gruppenzugehörigkeit zu den Downstreamservern repliziert, oder? Bliebe ansonsten allerhöchstens noch die Sicherheitsfilterung und AD-Gruppen mit Computern, aber das erhöht auch nicht gerade die Übersicht...
Das würde jedoch nicht mit den WPP-Updates funktionieren, also bliebe die Drittanbieter-Software so weiter ungepatcht.
Client-Zertifikate sind ausgerollt, da u.a. auch 802.1x für WLAN verwendet wird. Ist das dann eine reine IIS-Funktionalität, die unabhängig von WSUS eine Client-Authentifizierung mit Zertifikat am WSUS erfordert? Gibt es dazu ein Howto? Bisher bin ich davon ausgegangen, dass die Aktivierung von SSL beim WSUS nur dafür sorgt, dass die Kommunikation zwischen Client und Server verschlüsselt ist. Hierzu benötigt der Client ja naturgemäß kein eigenes Zertifiakt sondern muss nur der ausstellenden CA vertrauen.
2. Ist Split-Brain-DNS mittel der Wahl
Naja du kannst natürlich 2 GPOs machen die auf unterschiedliche OUs/Computergruppen zielen. Definiere interne und externe Geräte und gib denen unterschiedliche URLs mit. Aber SplitbrainDNS ist da natürlich einfacher.Für uns ist in der Konstallation problematisch, dass wir die WSUS-Gruppenzuordnung manuell und nicht über clientseitige Zielzuordnung via GPO machen. Der Grund hierfür ist, dass wir WPP nutzen und verschiedenen WSUS-Gruppen benötigen (z.B. nur Windows Updates, Firefox, Adobe, Java, Flash, ...) und dies nur sehr schwer bis garnicht über Organisationseinheiten und den zugeordneten GPOs abbilden könnten. Wenn die Clients sich nun von Extern am DMZ-WSUS melden, dann sind diese nicht zugeordnet und müssten dann dort zusätzlich einsoritert werden. Soweit ich das sehe gibt es keinen Mechanismus, der die WSUS-Gruppenzugehörigkeit zu den Downstreamservern repliziert, oder? Bliebe ansonsten allerhöchstens noch die Sicherheitsfilterung und AD-Gruppen mit Computern, aber das erhöht auch nicht gerade die Übersicht...
Nur damit das nicht untergeht: Der externe WSUS kann so eingestellt werden, das er zwar die Updates authorisiert, aber keinen DL anbietet.
Optionen > Update Files and Languages > Do not store update files locally
Dann holt der Client sich diese Updates vom MS Server
Optionen > Update Files and Languages > Do not store update files locally
Dann holt der Client sich diese Updates vom MS Server
Das würde jedoch nicht mit den WPP-Updates funktionieren, also bliebe die Drittanbieter-Software so weiter ungepatcht.
Client-Zertifikate sind ausgerollt, da u.a. auch 802.1x für WLAN verwendet wird. Ist das dann eine reine IIS-Funktionalität, die unabhängig von WSUS eine Client-Authentifizierung mit Zertifikat am WSUS erfordert? Gibt es dazu ein Howto? Bisher bin ich davon ausgegangen, dass die Aktivierung von SSL beim WSUS nur dafür sorgt, dass die Kommunikation zwischen Client und Server verschlüsselt ist. Hierzu benötigt der Client ja naturgemäß kein eigenes Zertifiakt sondern muss nur der ausstellenden CA vertrauen.
Das eine ist HTTPS, also verschlüsselter Transport der Daten, das andere ist Authentifizierung. und letzteres kannst du mit IIS machen. Dazu braucht aber der Client ein von der CA ausgestelltes Zertifikat.Für uns ist in der Konstallation problematisch...
Dann mach SplitDNS. Halte ich eh für die bessere Variante, da ein Client seine Updates imemr bekommt. Intern oder Extern. Egal.Das würde jedoch nicht mit den WPP-Updates funktionieren, also bliebe die Drittanbieter-Software so weiter ungepatcht.
Uff. Ja vermutlich. Habe ich mich noch nie mit beschäftigt. Keine AhnungZitat von @SeaStorm:
Das eine ist HTTPS, also verschlüsselter Transport der Daten, das andere ist Authentifizierung. und letzteres kannst du mit IIS machen. Dazu braucht aber der Client ein von der CA ausgestelltes Zertifikat.
Das eine ist HTTPS, also verschlüsselter Transport der Daten, das andere ist Authentifizierung. und letzteres kannst du mit IIS machen. Dazu braucht aber der Client ein von der CA ausgestelltes Zertifikat.
Schon klar, Client-Zertifikate sind wie gesagt im Einsatz. Bin kein IIS-Experte, werde zur SSL-Authentifizierung mal recherchieren.
Dann mach SplitDNS. Halte ich eh für die bessere Variante, da ein Client seine Updates imemr bekommt. Intern oder Extern. Egal.
Ja sowieso, nur ist das halt problematisch wegen fehlender Gruppen-Sync zwischen Replikat und Hauptserver.Vielleicht ist unsere Anforderung auch etwas zu kompliziert oder im WSUS einfach nicht vorgesehen, ich habe nun aber zumindest erkannt wo die Stolpersteine sind und wie es gehen könnte.
Danke!
Moin,
wir betreiben mehrere WSUS Server im Internet, welche ausschließlich über SSL Authentifizierung nutzbar sind. Wichtig ist, dass eure PKI Infrastruktur und die Verteilung der Zertifikate reibungslos funktioniert. Ansonsten sind Probleme vorprogrammiert...
Gruß,
Dani
wir betreiben mehrere WSUS Server im Internet, welche ausschließlich über SSL Authentifizierung nutzbar sind. Wichtig ist, dass eure PKI Infrastruktur und die Verteilung der Zertifikate reibungslos funktioniert. Ansonsten sind Probleme vorprogrammiert...
Ja sowieso, nur ist das halt problematisch wegen fehlender Gruppen-Sync zwischen Replikat und Hauptserver.
Wieso? Das ist trotzdem möglich. Das Design der DNS-Namen muss halt stimmen. Gruß,
Dani
Zitat von @Dani:
wir betreiben mehrere WSUS Server im Internet, welche ausschließlich über SSL Authentifizierung nutzbar sind. Wichtig ist, dass eure PKI Infrastruktur und die Verteilung der Zertifikate reibungslos funktioniert. Ansonsten sind Probleme vorprogrammiert...
wir betreiben mehrere WSUS Server im Internet, welche ausschließlich über SSL Authentifizierung nutzbar sind. Wichtig ist, dass eure PKI Infrastruktur und die Verteilung der Zertifikate reibungslos funktioniert. Ansonsten sind Probleme vorprogrammiert...
Das ist gewährleistet und funktioniert einwandfrei.
Ja sowieso, nur ist das halt problematisch wegen fehlender Gruppen-Sync zwischen Replikat und Hauptserver.
Wieso? Das ist trotzdem möglich. Das Design der DNS-Namen muss halt stimmen. Jetzt bin ich neugierig, erläutere bitte mal!
Nach meinem Kenntnisstand, werden manuelle WSUS-Gruppenzugehörigkeiten immer nur an dem jeweils verwendeten WSUS-Server konfiguriert.
Beispiel:
Interner WSUS: wsus-int.firma.de
Externer WSUS in DMZ: wsus-dmz.firma.de
Interner DNS CNAME: wsus.firma.de -> wsus-int.firma.de
Externer A Record: wsus.firma.de -> ext. IP von wsus-dmz.firma.de
Die per GPO konfigurierten Clients würden sich intern wie extern über wsus.firma.de mit dem jeweils erreichbaren WSUS-Server verbinden, doch jeweils dort als neuer unzugeordneter Client erscheinen.
Oder sehe ich das falsch?
Moin,
Gruß,
Dani
Nach meinem Kenntnisstand, werden manuelle WSUS-Gruppenzugehörigkeiten immer nur an dem jeweils verwendeten WSUS-Server konfiguriert.
Korrekt. Das Verhalten ist standardmäßig immer noch so. Jetzt bin ich neugierig, erläutere bitte mal!
Ich habe nochmals intern nachgefragt. Grob gesagt nimmt ein Load Balancer/ReverseProxy im Internet die Anfragen entgegen und routet die Informationen je nach Anfrage (z.B Reports, oder Suche nach Updates) auf unsere WSUS im RZ. Downloads der Updates entsprechend auf unsere WSUS-Server im Internet.Gruß,
Dani
