Vergitterte Fenster, Teil 1

Inhaltsverzeichnis

Netzwerkschutz, Speicherschutz, sichere E-Mail-Verarbeitung, sichereres Web-Browsing und verbesserte Pflege des Systems sollen helfen, die Gefahr aus dem Netz zu entschärfen. Das Dokument "Changes to Functionality in Microsoft Windows XP Service Pack 2" beschreibt detailliert, welche Änderungen Service Pack 2 mit sich bringt, welchen Einfluss dies auf vorhandene Applikationen hat und wie Entwickler oder Anwender bei Problemen Abhilfe schaffen können [1]. Anhand der Beta-Version des Service Packs 2 haben wir uns einen ersten Eindruck von der Umsetzung dieser Versprechungen verschafft.

Paradigmen..

Mit dem Service Pack 2 verschiebt Microsoft tatsächlich den Fokus vom Komfort hin zu mehr Sicherheit. Waren die alten Sicherheitseinstellungen wenig restriktiv und ließen eigentlich alles zu, sind die zukünftigen Standardeinstellungen derart streng, dass einige Programme ihren Dienst versagen können. Insbesondere die Voreinstellungen der eingebauten Windows Firewall und überhaupt zur Erreichbarkeit von Diensten können hier zu Umstellungsschwierigkeiten führen.

Die Änderungen und Neuerungen an der Netzwerksicherheit machen den Löwenanteil im Service Pack 2 aus. Unter anderem deaktiviert Microsoft den Windows Nachrichtendienst, um Privatanwender beim Surfen im Internet vor lästigen Nachrichtenfenstern mit dubiosen Meldungen zu schützen. Auch der Warndienst zur Benachrichtigung über Systemereignisse und Alarmen funktioniert auf die gleiche Weise und wird deshalb ebenfalls abgeschaltet. Allerdings ist dies nicht für alle Szenarien sinnvoll, etwa in Unternehmensnetzen, die den Nachrichten- und Warndienst immer noch zur Kommunikation einsetzen. Dort müssen die Dienste explizit wieder unter /Verwaltung/Dienste aktiviert werden.

..Wechsel

Der Windows Firewall - ehemals Internet Connection Firewall (ICF)- bürdet Microsoft zukünftig wesentlich mehr Aufgaben auf [3]. Standardmäßig wird sie von nun an für alle Netzwerkschnittstellen aktiviert -- bisher ist sie das nur für DFÜ-Adapter. Zudem schließt sie ein kleines Zeitfenster zwischen dem Aktivieren des Netzwerkstacks und dem Hochfahren der Firewall. Ein Angreifer könnte während des Boot-Vorganges versuchen, in das noch ungeschützte System einzudringen. Die dafür eingeführte statische Boot-Time-Policy lässt während des Starts jedoch nur einfache Netzwerkkommunikation wie DHCP und DNS zu. Sind alle Dienste geladen, aktiviert die Firewall die konfigurierbare Run-Time-Policy.

Die Änderung der Firewall-Konfiguration wirkt sich zukünftig nicht mehr nur für ein einzelnes Interface aus. Ändert der Anwender eine Einstellung oder Regel, so gilt diese für alle vorhanden Schnittstellen, ebenso wie für nächträglich zum System hinzugefügte. Allerdings besteht immer noch die Möglichkeit Regeln beispielsweise nur für eine Netzwerkkarte zu setzen.

Komm nicht näher!

Komm nicht näher!

Wenn man einen Port in der Firewall öffnet, können sich bisher beliebige PCs damit verbinden. Service Pack 2 ermöglicht die Freigabe eines Ports nur für Adressen aus dem lokalen IP-Subnetz, in dem der Rechner arbeitet. Gibt ein Anwender auf dem eigenen PC ein Laufwerk oder Drucker für das Netzwerk frei, so aktiviert Windows XP automatisch die Local-Subnet-Restriction (nur lokales Subnetz), um einen Zugriff aus fremden Netzen auf die Ports 137, 138, 139 und 445 zu verhindern. Allerdings ist dies nicht immer erwünscht, inbesondere in größeren Unternehmensnetzen kommunizieren Rechner über mehrere Subnetze hinweg. Diese Einschräkung könnte einigen Applikationen Schwierigkeiten bereiten. Auch Universal-Plug-and-Play (UPnP) funktioniert dann standardmäßig nur noch im lokalen Netz. Alle Ports lassen sich auf Wunsch aber auch global öffnen.

Auch Heim-Anwender deren Rechner direkt am Internet hängt, schützt die Local-Subnet-Restriction. Arbeitet der Provider mit korrekten Subnetz-Masken (255.255.255.255), können Angreifer aus dem Internet versehentlich offene Dienste wie Dateifreigaben nicht erreichen. Die bei manchen Anbietern übliche Class-A-Maske 255.0.0.0 hebelt diesen Schutz jedoch aus.

Mit dem Firewall-Netsh-Helper erhalten Administratoren ein Kommandozeilen-Tool, um die XP-Firewall ohne grafische Oberfläche zu konfigurieren. Damit lassen sich Firewall-Regeln in einem Login-Skript verarbeiten. Die frühere Version unterstützte nur IPv6, nun ist auch IPv4 implementiert. Leider laufen bisherige Skripte für IPv6 nicht mehr. Aufgrund der vielen hinzugekommenen Optionen haben die Redmonder das grafische Interface der Firewall überarbeitet, das nun auch direkt über die Eigenschaften der Netzwerkumgebung erreichbar ist. Will man IPv6-Verkehr filtern, muss man aber weiterhin auf den Netsh-Helper zurückgreifen.

Eingeladen

Um auf XP Server-Applikationen zu betreiben, müssen die benötigten Ports für eingehenden Verkehr von außen erreichbar sein. Anwendungen vor Service Pack 2 riefen dazu die Firewall-API auf, um selbsttätig Ports zu öffnen und beim Beenden wieder zu schließen. Stürzt die Anwendung aber während des Betriebs ab, so bleibt der Port offen. Da zum Freischalten nur der lokale Administrator berechtigt ist, muss die Anwendung in dessen Kontext laufen. Das ist aus Sicherheitsgründen unerwünscht, da eine Serveranwendung nur die zum Betrieb notwendigen minimalen Rechte erhalten sollte. Mit den neuen Permission Lists/Application White Lists (Zugelassene Programme) können Server mit den Rechten eines nicht-privilegierten Anwenders laufen. Die Firewall öffnet den Port nur dann, wenn die Serveranwendung in die Liste eingetragen ist und nur solange wie sie auf einem oder mehreren Ports auf eingehende Verbindungen horcht. Das Öffnen beliebiger unbenutzter Ports durch die Applikation ist damit nicht mehr möglich.

Eine Applikation fügt man der White List durch Angabe des Pfades und Programmnamens hinzu, etwa "Programme/NetMeeting/conf.exe" für NetMeeting. Allerdings lässt sich die dahintersteckende Applikation leicht austauschen: Nachdem wir die NeetMeeting-Originaldatei durch einen in "conf.exe" umbenannten Telnet-Server im gleichen Verzeichnis ersetzt hatten, gelang uns von außen der Zugriff auf eine Telnet-Shell. Auf die gleiche Weise könnten Trojaner - ohne Eintrag in die Permission List - einen Server-Port nach außen öffnen. Da die viele Anwender aber als Administrator auf ihren Rechnern arbeiten, können sich eingeschleppte Trojaner diesen Umweg jedoch sparen und sich auch gleich selbst in die Liste eintragen.

Ausgeladen

Ausgeladen

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.

Ruf mich an

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.

Wer da?

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.

Rundfunk

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.

Befehlsverweigerung

Befehlsverweigerung

Die Execution Protection (NX, no execute) soll die Auswirkungen von Angriffen über Buffer Overflows, Integer Overflows, Heap Overflows, Format-String-Schwächen und anderen Fehlern minimieren. Ziel solcher Angriffe ist es, eigenen Code in das System einzuschleusen und auszuführen [3]. Üblicherweise überschreibt man dazu Bereiche in denen Daten abgelegt werden, etwa Stacks und Heaps, mit Code und springt ihn durch Manipulation des Instruction Pointers an. NX verhindert das Ausführen von Code, der in Datenbereichen abgelegt ist, sofern die als "nicht ausführbar" gekennzeichnet sind. Ein Angriff des Wurms Lovsan/MSBlaster hätte mit dieser Funktion auf Windows XP allenfalls den RPC-Dienst zum Absturz gebracht - den Rechner hätte er nicht infizieren können. NX ist standardmäßig aktiviert und markiert Datenbereiche wie Stacks und Heaps als nicht-ausführbar.

Um Execution Protection zu implementieren, greift Microsoft auf die Fähigkeiten moderner 64-Bit-Prozesoren zurück, die Funktionen zur NX-Kennzeichnung von Speicherbereichen mitbringen. Derzeit stehen dafür der Athlon64 von AMD und der Itanium von Intel zur Verfügung. Bislang kann nur der Athlon64 mit dem 32-bittigen Windows XP zuammenarbeiten und dies auch nur im PAE-Mode (Physical Address Extension). Einige Treiber könnten hier zukünftig ihren Dienst versagen, da PAE einen 64-Bit-Adressraum benutzt, den 32-Bit-Adapter nicht adressieren können. Microsoft hat deshalb auch den Hardware Abstraction Layer (HAL) und den Memory Manager modifiziert, um weitestgehende Kompatibilität zu älteren 32-Bit-Treibern zu erhalten.

Ruft eine Applikation eine als NX markierte Speicherseite auf, löst der Prozessor eine Exception (STATUS_ACCESS-VIOLATION im User Mode) aus, die in den meisten Fällen unbehandelt bleibt und zur Terminierung des auslösenden Prozesses führt. Greift der Kernel auf einen geschützten Speicherbereich zu, stürzt Windows ab (ATTEMPTED_EXECUTE_OF_NONEXECUTE_MEMORY). Leider schützt Execution Protection den Kernel Mode im 32-Bit-Windows-XP nur halb: Einzig der Stack wird als NX markiert. Anders beim 64-Bit-Windows-XP: Außer dem Stack sind auch die Heaps geschützt.

Einige Applikationen, die etwa zur Laufzeit neuen Programmcode generieren und ausführen wollen, dürften nach der Installation des Service Packs nicht mehr funktionieren. Über spezielle Funktionen können neue Anwendungen ausführbaren Speicher anfordern, ältere Programme müssen dazu überarbeitet werden.

In den Schutz von NX kommen bis auf weiteres nur Besitzer aktueller 64-Bit-CPUs. Damit hat Microsoft den Abstand zur Konkurrenz zwar verkürzt -- aber noch nicht ganz aufgeholt. OpenBSD und Linux mit der Erweiterung PaX bieten ähnliche Schutzmechanismen bereits auf gewöhnlichen x86-Systemen [4].

Der zweite und letzte Teil dieses Artikels beleuchtet unter anderem die Verbesserungen durch Service Pack 2 bei Internet Explorer, Outlook Express und Patch Management.

Literatur

[1] Changes to Functionality in Service Pack 2 for Microsoft Windows XP

[2] Deploying Internet Connection Firewall Settings for Windows XP with Service Pack 2

[3] Buffer-Overflows und andere Sollbruchstellen

[4] Speicherschutz mit PaX (dab)