Vergitterte Fenster, Teil 1

Seite 3: Ausgeladen

Inhaltsverzeichnis

Zum Schutz vor Angriffen kann sich Windows in den Shielded Mode schalten, bei dem die Firewall alle eingehenden Ports schließt und nur noch ausgehende Verbindungen des Clients erlaubt. XP aktiviert diesen Modus, wenn es eine Sicherheitsverletzung bei Serverdiensten entdeckt hat, um Würmer und Angreifer abzuwehren. In den normalen Modus kann XP nur durch einen manuellen Eingriff des Anwenders zurückkehren.

Um sich an verschiedene Schutzbedürfnisse anzupassen, unterstützt die Firewall unter XP Professional zukünftig zwei Einstellungen: Dömanenprofil und Mobilprofil. Beim Einsatz eines Laptops im Unternehmensnetzwerk sind beispielsweise die Anforderungen an die Sicherheit geringer, als bei der Einwahl in das Internet von unterwegs. Zwischen verschiedenen Schutzprofilen kann man aber nur dann wählen, wenn das Laptop Mitglied in einer Domäne ist. Computer die nur Mitglied in einer Workgroup sind, haben nur ein Profil, ebenso wie mit XP Home ausgestattete Rechner.

Im Zuge dieser Erweiterungen hat Microsoft auch gleich das Firewall-Objekt für Gruppenrichtlinien erweitert und verfeinert, um Administratoren in Netzwerken in die Lage zu versetzen, die Konfiguration der Firewall über Domänencontroller zu verteilen.

Mit Remote Procedure Calls (RPC) tauschen verschiedene Prozesse lokal und über das Netzwerk Daten aus. Auf geschützten Rechnern stellt die RPC-basierende Kommunikation bisher ein Problem dar, da zwar die Verbindung zum RPC Endpoint Mapper erlaubt sein kann (Port 135), die von ihm dynamisch zugewiesenen Server-Ports aber von der Firewall gesperrt sind. Die Firewall kann schließlich nicht voraussehen, welche Ports der Mapper wählt. In der Folge funktionieren etwa Dienste wie Netzwerk- und Druckerfreigabe, Fernadministration der Registry und Remote Windows Management Instrumentation (WMI) nicht mehr, da der Verbindungsaufbau fehlschlägt. Abhilfe würde der Eintrag des Prozesses svchost.exe in die Permission List schaffen. Da aber alle Windows-RPC-Server und andere Dienste diese Datei verwenden, würde die Firewall alle von svchost.exe angeforderten Ports automatisch öffnen, weshalb gleich eine ganze Reihe von Diensten eventuell ungewollt erreichbar wäre.

Deshalb geht man hier einen neuen Weg: Die RPC-Dienste selbst fordern die Firewall auf, einen Port freizuschalten. Diese öffnet den angeforderten Port, sofern der anfordernde Service im Sicherheitskontext des lokalen Systems, Netzwerkdienstes oder eines lokalen Dienstes arbeitet. Dabei lässt sich mit einem neuen Registry-Key PrivilegedRpcServerPermission noch einstellen, ob er im Subnetz oder global erreichbar ist. Etwas Aufmerksamkeit ist bei der Konfiguration erforderlich, da sich einige Einstellungen widersprechen können. Ist der Dienst in der Permission List als global verfügbar eingetragen, in der Registry aber nur "lokal", so ist der Service für alle Verbindungen offen.

Durch die Einführung des Registry-Schlüssels RestrictRemoteClients blockt XP mit Service Pack 2 standardmäßig die Verbindungsaufnahme eines Clients zum RPC-Server ohne vorherige Authentifizierung ab. Damit kann man die Kommunikation mit anonymen Clients verhindern. Der Registry-Key EnableAuthEpResolution auf XP-Clients erzwingt die Authentifizierung gegenüber dem RPC-Endpoint-Mapper mit dem NLTM-Verfahren. Alle weiteren Anfrage des Clients sind damit anschließend authentisiert. In Unternehmensnetz kann das aber unerwünscht sein, daher lässt sich die Zwangsauthentifizierung auch wieder abschalten. Alle Einstellungen lassen sich für jedes Netzwerkinterface einzeln vornehmen. Für RPC-Clients, die mit dem Server über Named Pipe Protocol Sequence (ncacn_np) kommunizieren, ändert sich nichts.

Auch das Distributed Component Object Model (DCOM) bleibt von Eingriffen nicht verschont. DCOM ist ein auf RPC aufbauendes Protokoll, mit dem verschiedene Softwarekomponenten lokal und über das Netzwerk Daten austauschen. Durch computerweite Restriktionen lassen sich die Zugriffsrechte von anderen Prozessen auf COM-Server sicherer definieren und kontrollieren. Dies ist wichtig, da COM-Server mit Prozessen auch über das Netzwerk kommunizieren können. Jeder Aufruf wird zukünftig erst anhand einer Access Control List (ACL) überprüft und gegebenenfalls blockiert. Microsoft implementiert dazu eine ACL für das Starten von DCOM-Servern sowie eine ACL für den Zugriff. Beide Listen lassen sich über eine Microsoft Management Console (MMC) verwalten. Standardmäßig werden lokale Aufrufe nicht eingeschränkt, auch darf jedermann ohne Authentifizierung über das Netzwerk auf DCOM zugreifen. Um DCOM-Server über das Netz zu aktivieren und zu starten muss man allerdings auf dem Zielsystem als Administrator angemeldet sein.

Die ursprüngliche Version von XP blockierte keinen Multicast- und Broadcast-Verkehr. Seit Service Pack 1 verwirft die Firewall standardmäßig solche Pakete. Nur durch das manuelle Öffnen eines Ports kann der Rechner beispielsweise die Antwort auf ein Broadcast-Paket empfangen. Allerdings ist dann der Port für jeglichen Verkehr wieder erreichbar. Microsoft hat die Unterstützung von Applikationen die Uni-, Multi- und Broadcast-Verbindungen einsetzen nun in Service Pack 2 verbessert. Sendet XP etwa ein Anfrage ins Netz, so öffnet die ICF drei Sekunden lang den sendenden Port für eingehende Unicast-Antwortpaket für alle Quelladressen. Ähnlich behandelt XP UDP-Verkehr, hier öffnet sich der Filter aber für 90 Sekunden.