Eine hochinteressante Statistik hat Microsoft im Web veröffentlicht. Aus dieser geht hervor, dass Patches in der Regel bereits lange vor dem Auftreten von Würmern verfügbar sind. So lagen selbst bei Code Red, dem Beispiel mit der kürzesten genannten Zeitspanne zwischen der Bereitstellung des Patch und der eigentlichen Attacke immerhin 28 Tage. Bei Nimda, einem sehr schwerwiegenden Angriff, waren es gar 336 Tage.
Nun sollte man zwar nur selbst gefälschten Statistiken glauben. Aber auch der Blaster-Wurm, der vor nicht allzu langer Zeit wütete und der in der Microsoft-Tabelle noch nicht zu finden ist, nutzte eine schon längst bekannte Schwachstelle, für die es schon seit geraumer Zeit einen Patch gab.
Damit Würmer und Viren sich schnell und weit verbreiten können, müssen drei Voraussetzungen erfüllt sein:
• Es muss einen Bug oder eine Schwachstelle in der Konfiguration geben, die ausgenutzt werden kann.
• Es muss Leute geben, die ein Interesse daran haben, den Code für die Angriffe zu schreiben.
• Und es muss Administratoren geben, die Bugs nicht adressieren und Schwachstellen nicht beseitigen.
Bei den ersten beiden Punkten ist man machtlos. Microsoft wird genauso wie jeder andere Anbieter von Software munter weiter Bugs produzieren - gemäss einem bereits in den 60er Jahren geführten Beweis, dass es ab einer gewissen Komplexität schlicht keine fehlerfreie Software geben kann. Und Microsoft hat ausreichend Feinde, die das Unternehmen angreifen möchten, so dass auch die zweite Voraussetzung erfüllt ist. Der dritte Aspekt lässt sich aber adressieren - und das seit mittlerweile gut zwei Jahren auch auf einfache Weise und ohne immensen Aufwand für die Verteilung aktualisierter Softwareversionen treiben zu müssen. Denn die Microsoft SUS (Software Update Services) für das Patch-Management gibt es schon seit einiger Zeit.
Die SUS sind eigentlich nichts Neues, sondern nur eine Variante des Windows Updates, das ab Windows 2000 Teil des Betriebssystems ist. Windows Update ist bei Administratoren aber zu Recht nicht sehr beliebt, denn wenn jeder Client selbst die Updates durchführt, entsteht eine immense Netz-Last beim Download der Aktualisierungen und der Patch-Status der Clients ist kaum noch kontrollierbar. Die SUS dagegen bestehen aus einer Server-Komponente und einer Erweiterung des Windows-Update-Clients, die ab dem Service Pack 2 für Windows 2000 und bei allen neueren Systemversionen ohnehin integriert ist. Die Server-Komponente basiert auf der Technologie, die Microsoft für die Windows-Update-Website einsetzt.
Der Unterschied zum Windows Update liegt darin, dass der gesamte Patch-Prozess nun mit wenig Aufwand im Unternehmen zentralisiert werden kann. Die verfügbaren Updates werden einmalig von Microsofts Windows-Update-Website auf einen SUS-Server geladen und von dort auf weitere SUS-Server im Unternehmen verteilt oder direkt von den Clients abgerufen. Die Patches lassen sich vor der Freigabe testen, und die Steuerung der Updates auf den Clients wird vollständig über die Gruppenrichtlinien vorgenommen. Damit werden Patches nur noch einmalig von Microsofts Website geladen, können im Unternehmen gezielt auf verschiedene Server - beispielsweise an unterschiedlichen Standorten - verteilt und in kontrollierter Weise auf die Clients geladen werden.
Das Konzept ist einfach und effizient. Damit stellt sich durchaus die Frage, warum es immer noch so viele Netzwerke gibt, in denen das Patch-Management nicht funktioniert. Denn schon mit der Beseitigung der Schäden nach einem Angriff durch Viren wie Code Red, Nimda, Melissa oder Blaster entsteht ein Aufwand, der viel höher als die Implementierung der SUS ist.
Wie bereits erwähnt kann mit einem oder mehreren SUS-Servern gearbeitet werden. Ein Server stellt dabei immer die Schnittstelle zu Microsofts Windows-Update-Website dar. Das ist nicht nur effizient in Bezug auf die aus dem Internet geladene Datenmenge, sondern auch vorteilhaft für die Firewall-Konfiguration, weil nur genau eine eindeutig definierte Schnittstelle geschaffen werden muss.
Nach dem Download der Software von Microsofts Website erfolgt die Installation in wenigen Minuten. Voraussetzung ist ein Windows 2000 Server oder Windows Server 2003 mit installiertem IIS. Bei der Installation kann ausgewählt werden, ob der Server die Updates von Microsoft oder von einem bereits vorhandenen SUS-Server beziehen soll, was für die Einrichtung verteilter Strukturen mit mehreren SUS-Servern wichtig ist. Ausserdem lässt sich hier konfigurieren, ob alle Patches explizit freigeben werden oder ob diese automatisch für Clients zur Verfügung stehen sollen. Diese Einstellungen können auch später noch verändert werden.
Nach der Installation wird der Server über http://Servername/SUSAdmin konfiguriert. Der erste Schritt ist die Synchronisation der Informationen von der Windows-Update-Website, die mit Synchronize Server gesteuert wird. Dabei kann sowohl mit einer manuellen Synchronisation gearbeitet als auch ein Zeitplan für den Download der Updates konfiguriert werden. Synchronize Now macht für den Anfang Sinn, ist aber auch nützlich, wenn ein kritisches Update bekannt wird und schnell geladen werden soll. Ansonsten ist eine tägliche Aktualisierung zu nächtlicher Stunde sinnvoll. Nur der erste Download ist wirklich aufwendig, weil dabei alle verfügbaren Patches und damit etliche GB an Daten geladen werden müssen.
Nachdem die vollständige Aktualisierungen auf das System geladen sind, lässt sich mit Approve Updates steuern, welche Patches auch für Clients bereitgestellt werden sollen. In grösseren Umgebungen ist es dabei sinnvoll, einen speziellen SUS-Server nur für die Testumgebung zu konfigurieren, der mit kurzen Synchronisationsintervallen alle Updates vom zentralen SUS-Server lädt - auf diesem System werden dann zunächst die Updates freigegeben und getestet, bevor sie auch auf den SUS-Servern für die Produktivsysteme zur Verfügung gestellt werden.
Die SUS-Client-Funktionalität lässt sich vollständig über die Gruppenrichtlinien steuern. Wenn dort im Bereich Computerkonfiguration/Administrative Vorlagen/Windows-Komponenten/Windows Update Einstellungen getroffen werden, überschreiben diese zwangsläufig immer die lokale Konfiguration, die über die Systemsteuerung durchgeführt werden kann. Mit Automatische Updates konfigurieren wird festgelegt, in welcher Form die Updates geladen werden sollen. Dabei kann eine Client-Bestätigung über Autom. Downloaden, aber vor Installation benachrichtigen angefordert oder die Installation zeitgesteuert mit Autom. Downloaden und laut Zeitplan installieren durchgeführt werden. Letzteres ist sinnvoll, wenn die Aktualisierung möglichst transparent erfolgen soll.
Die Richtlinie Internen Pfad für den Microsoft Updatedienst angeben dient dazu, auf den SUS-Server zu verweisen. Ausserdem kann mit den beiden letzten Richtlinien gesteuert werden, wie nach der Durchführung geplanter Installationen verfahren werden soll: Damit lassen sich automatische Neustarts verhindern, und es kann sichergestellt werden, dass eine einmal abgebrochene Installation von Updates nach einem Neustart garantiert durchgeführt wird.
Bei der Nutzung der SUS sollte man nicht vergessen, auch die Gruppenrichtlinien für Server anzupassen - denn auch diese sind gefährdet. Wenn man die Server automatisch über die SUS aktualisieren lassen will, sollte man das allerdings auch bereits in der Testumgebung berücksichtigen und die Patches entsprechend auch auf Server-Systemen testen.
Wenn man mit der Bestätigung von Updates arbeitet, müssen ausserdem organisatorische Regeln definiert werden: Es muss sichergestellt sein, dass regelmässig überprüft wird, ob neue Updates bereitstehen, dass diese heruntergeladen und getestet und schliesslich auf die Clients verteilt werden. Übrigens gibt es auch ein Add-On für den Microsoft Systems Management Server (SMS) 2000 und eine Integration der Funktionalität in die neue Version 2003 des SMS. Patch-Management in Windows-Umgebungen ist einfach - so einfach, dass es schon fast fahrlässig ist, die Funktionen des SUS nicht zu nutzen.
