Änderungen an der Funktionalität durch Microsoft Windows XP Service Pack 2

Es handelt sich bei diesem Dokument um Teil 2 von "Änderungen an der Funktionalität durch Microsoft Windows XP Service Pack 2". Dieser Teil enthält detaillierte Informationen zu den in Microsoft® Windows XP Service Pack 2 enthaltenen Technologien für den Netzwerkschutz.

Dieses Dokument gilt für Microsoft Windows® XP Service Pack 2 (SP2) für die 32-Bit-Versionen von Windows XP Professional und Windows XP Home Edition. Es werden nicht alle im Service Pack enthaltenen Änderungen beschrieben. Vielmehr werden diejenigen Änderungen hervorgehoben, die sich am stärksten auf die Verwendung von Windows XP SP2 auswirken. Zudem werden Referenzen für möglicherweise verfügbare zusätzliche Informationen bereitgestellt.

Auf dieser Seite

	Warn- und Nachrichtendienste
	Clientverwaltungsprogramme
	Verbesserungen bei der DCOM-Sicherheit
	TCP/IP
	RPC-Schnittstelleneinschränkung
	WebDAV-Redirector
	Windows-Firewall
	Windows Media Player
	Windows Messenger.
	Wireless Provisioning Services
	Drahtlosnetzwerkinstallations-Assistent

Warn- und Nachrichtendienste

Welche Aufgabe haben die Warn- und Nachrichtendienste?

Die Warn- und Nachrichtendienste sind Bestandteile von Windows, mit denen einfache Nachrichten zwischen Computern in einem Netzwerk übertragen werden können. Der Nachrichtendienst leitet Nachrichten von verschiedenen Anwendungen und Services weiter, während der Warndienst speziell für administrative Warnungen gedacht ist.

Für wen ist diese Funktion gedacht?

Administratoren, die mit ihren Benutzern kommunizieren, sollten die Änderungen an diesen Diensten kennen. Darüber hinaus sollten Entwickler, die mit diesen Diensten Benutzer über Ereignisse oder Broadcastmeldungen im Netzwerk informieren, diese Änderungen beachten. Diese Änderungen gelten zwar für alle Computer unter Microsoft Windows XP Service Pack 2, aber nur Computer in einem Netzwerk sind davon betroffen.

Welche vorhandenen Funktionen ändern sich in Windows XP Service Pack 2?

Warn- und Nachrichtendienste deaktiviert

Ausführliche Beschreibung

In früheren Windows-Versionen wurde der Nachrichtendienst automatisch und der Warndienst manuell gestartet. In Windows XP Service Pack 2 sind beide Dienste deaktiviert. Ansonsten gibt es keine Änderungen an diesen Diensten.

Warum ist diese Änderung wichtig? Zur Minderung welcher Probleme trägt dies bei?

Wenn die Dienste gestartet werden, sind eingehende Netzwerkverbindungen zulässig und stellen eine potenzielle Angriffsfläche dar. Dadurch erhöht sich das Sicherheitsrisiko. Außerdem werden diese Dienste in aktuellen Computerumgebungen selten verwendet. Aufgrund der zusätzlichen Angriffsfläche dieser Dienste und der seltenen allgemeinen Verwendung sind sie nun standardmäßig deaktiviert.

Was ist anders? Gibt es Abhängigkeiten?

Alle Anwendungen oder Dienste, die die Warn- oder Nachrichtendienste für die Kommunikation mit dem Benutzer verwenden, können standardmäßig nicht ausgeführt werden.

Wie kann ich diese Probleme beseitigen?

Es gibt zwei mögliche Lösungsansätze. Die empfohlene Vorgehensweise besteht darin, in der Software eine andere Methode für die Kommunikation mit dem Benutzer zu verwenden. Auf diese Weise können Sie mit dem Benutzer bei optimaler Sicherheit kommunizieren, ohne dass Sie den Warn- oder Nachrichtendienst verwenden müssen.

Bei der zweiten Methode startet die Anwendung den Warn- oder Nachrichtendienst, bevor diese Dienste verwendet werden. Informationen zum Starten von Diensten finden Sie in der Hilfe und im MSDN. Ein Beispiel finden Sie im Abschnitt zur Verwendung des Dienstverwaltungsprogramms zum Konfigurieren von Diensten auf der Microsoft-Website unter http://go.microsoft.com/fwlink/?LinkId=25974.

Muss ich den Code ändern, um mit Windows XP Service Pack 2 zu arbeiten?

Wenn im Code der Warn- oder Nachrichtendienst verwendet wird, ist möglicherweise eine Änderung erforderlich. Weitere Informationen hierzu finden Sie weiter oben unter "Wie kann ich diese Probleme beseitigen?".

Bluetooth

Welche Funktion hat Bluetooth?

Die drahtlose Bluetooth®-Technologie ist eine kostengünstige drahtlose Spezifikation für Kurzstrecken, um mobile Geräte miteinander zu verbinden. Sie kommt in vielen Geräten zum Einsatz. Windows XP Service Pack 2 unterstützt die drahtlose Bluetooth-Technologie. Zuvor wurde diese Technologie von Microsoft nicht direkt unterstützt. Die Kunden haben jedoch darum gebeten, sie in das Windows-Betriebssystem zu integrieren.

Die vorliegende Version ermöglicht Folgendes:

Wenn die entsprechenden Softwareprogramme von Microsoft oder anderen Herstellern in Windows XP installiert sind, können Sie mit Bluetooth-Geräten noch weiteres ausführen:

Diese Version unterstützt außerdem folgende Bluetooth-Profile:

Darüber hinaus gibt es die folgenden Bluetooth-Funktionen:

Wenn im System kein Bluetooth-Transceiver vorhanden ist, gibt es keine Änderung beim Systemverhalten. Wenn ein von Windows-Hardware Quality Labs (WHQL) zugelassenes Bluetooth-Gerät vorhanden ist, ist die Bluetooth-Unterstützung aktiviert.

Wenn die Bluetooth-Unterstützung aktiviert ist, gibt es in der Systemsteuerung unter Netzwerkverbindungen Änderungen. Außerdem wurde die neue Systemsteuerungsoption Bluetooth-Geräte hinzugefügt. Im Infobereich der Taskliste ist ein Bluetooth-Symbol vorhanden. Wenn Sie auf dieses Symbol klicken, wird ein Menü mit Bluetooth-Tasks angezeigt, die Sie ausführen können. Außerdem können Sie den neuen Dateiübertragungs-Assistenten für Bluetooth starten. Klicken Sie dazu im Startmenü auf Alle Programme, zeigen Sie auf Zubehör, zeigen Sie auf Kommunikation, und wählen Sie dann Dateiübertragungs-Assistent für Bluetooth aus.

Wenn ein anderer als ein Microsoft Bluetooth-Treiber installiert ist, wird durch das Update auf Windows XP Service Pack 2 der vorhandene Treiber nicht ersetzt. Er kann später manuell oder programmgesteuert ersetzt werden.

Ausführliche Informationen zu Bluetooth in Windows XP Service Pack 2 finden Sie in der Hilfe.

Zum Seitenanfang

Clientverwaltungsprogramme

Wozu dienen die Clientverwaltungsprogramme?

Die Clientverwaltungsprogramme setzen sich aus MMC-Snap-Ins (Microsoft Management Console) zusammen, mit denen Sie Benutzer, Computer, Dienste und sonstige Systemkomponenten auf lokalen Computern und Remotecomputern verwalten können. Diese Snap-Ins verwenden zwei vom System generierte Dialogfelder für die Verwaltung, nämlich das zum Auswählen von Benutzern, Computern oder Gruppen und das zum Suchen von Benutzern, Kontakten oder Gruppen. Das Dialogfeld zum Auswählen von Benutzern, Computern oder Gruppen verwenden Sie, um Zugriffssteuerungslisten (Access Control Lists, ACLs) in einem freigegebenen Ordner festzulegen, einen Remotecomputer für die Neuausrichtung eines Snap-Ins anzugeben oder aber lokale Benutzer und Gruppen zu verwalten. Das Dialogfeld zum Suchen von Benutzern, Kontakten oder Gruppen verwenden Sie, um Active Directory in Netzwerkumgebung zu durchsuchen, einen Drucker im Druckerinstallations-Assistenten zu suchen sowie Objekte im Verzeichnis des Snap-Ins Active Directory-Benutzer und -Computer zu suchen.

Mit beiden Dialogfeldern werden Objekte, wie z. B. Benutzer, Computer, Drucker und sonstige Sicherheitsprinzipale, auf dem lokalen Computer oder in Active Directory gesucht und ausgewählt. Andere Anwendungen können diese Dialogfelder zwar verwenden, aber in diesem Abschnitt werden nur die hier aufgeführten Änderungen an den Clientverwaltungsprogrammen behandelt.

Für wen sind diese Funktionen gedacht?

Diese Funktionen sind für Administratoren gedacht, die Windows XP von einem Remotestandort aus mithilfe der im folgenden aufgeführten betroffenen Verwaltungsprogramme verwalten müssen. Administratoren und Benutzer, die mit diesen Programmen den lokalen Computer verwalten, sind nicht davon betroffen.

Welche vorhandenen Funktionen ändern sich in Windows XP Service Pack 2?

Remotekonnektivität

Ausführliche Beschreibung

Zum Herstellen einer Verbindung mit einem Remotecomputer mithilfe der hier aufgeführten Verwaltungsprogramme muss der Remotecomputer eingehenden Netzwerkverkehr auf TCP-Port 445 zulassen. Die Standardkonfiguration des Windows-Firewalls in Windows XP Service Pack 2 blockiert eingehenden Netzwerkverkehr auf TCP-Port 445. Deshalb kann es sein, dass eine oder mehrere der folgenden Fehlermeldungen angezeigt werden. In diesem Fall wird der Text, der in den folgenden Beispielmeldungen kursiv formatiert ist, durch die entsprechende Systemvariable für den Fehlerzustand ersetzt:

Diese Fehler können auftreten, wenn eines der folgenden MMC-Snap-Ins für die Remoteverwaltung verwendet wird:

Neben den MMC-Snap-Ins sind folgende Dialogfelder und Verwaltungsprogramme betroffen:

Wie kann ich diese Probleme beseitigen?

Um mit diesen Programmen eine Remoteverbindung für einen Computer unter Windows XP bei aktiviertem Windows-Firewall herzustellen, müssen Sie TCP-Port 445 im Firewall auf dem Remotecomputer öffnen. Gehen Sie dabei folgendermaßen vor:

Zum Seitenanfang

Verbesserungen bei der DCOM-Sicherheit

Welche Funktion hat DCOM?

Microsoft Component Object Model (COM) ist ein plattformunabhängiges, verteiltes, objektorientiertes System zum Erstellen binärer Softwarekomponenten, die miteinander interagieren können. Mit Distributed Component Object Model (DCOM) können Anwendungen auf Standorte verteilt werden, die für Sie und die Anwendung am sinnvollsten sind. Das DCOM-Wire-Protokoll bietet die transparente Unterstützung einer zuverlässigen, sicheren und effizienten Kommunikation zwischen COM-Komponenten. Weitere Informationen finden Sie im Abschnitt zu COM auf der Microsoft Website unter  http://go.microsoft.com/fwlink/?LinkId=20922

Für wen ist diese Funktion gedacht?

Wenn Sie COM nur für In-Process-COM-Komponenten verwenden, betrifft Sie dieser Abschnitt nicht.

Diese Funktion ist für Sie relevant, wenn Sie eine COM-Serveranwendung verwenden, die eines der folgenden Kriterien erfüllt:

Welche neue Funktionalität wurde in Windows XP Service Pack 2 für diese Funktion hinzugefügt?

Computerweite Einschränkungen

Ausführliche Beschreibung

In COM wurde eine Änderung vorgenommen, um computerweite Zugriffssteuerungselemente zu ermöglichen, die den Zugriff auf alle Aufruf-, Aktivierungs- oder Startanforderungen auf dem Computer kontrollieren. Stellen Sie sich diese Zugriffssteuerungselemente einfach als zusätzlichen AccessCheck-Aufruf für eine computerweite Zugriffssteuerungsliste (Access Control List, ACL) bei jeder Aufruf-, Aktivierungs- oder Startanforderung eines COM-Servers auf dem Computer vor. Wenn AccessCheck einen Fehler meldet, wird die Aufruf-, Aktivierungs- oder Startanforderung abgelehnt. (Zusätzlich zu jedem AccessCheck-Aufruf, der für die serverspezifischen ACLs ausgeführt wird.) Dies bietet einen Mindestautorisierungsstandard, der für den Zugriff eines COM-Servers auf dem Computer eingehalten werden muss. Es gibt eine computerweite ACL für Startberechtigungen für Aktivierungs- und Startrechte und eine computerweite ACL für Zugriffsberechtigungen für Aufrufrechte. Die Konfiguration ist über die Komponentendienste-MMC (Component Services Microsoft Management Console) möglich.

Mit diesen computerweiten ACLs können niedrige Sicherheitseinstellungen außer Kraft gesetzt werden, die von einer bestimmten Anwendung über CoInitializeSecurity oder anwendungsspezifische Sicherheitseinstellungen definiert wurden. Dies stellt einen Mindestsicherheitsstandard dar, der ungeachtet der Einstellungen des betreffenden Servers eingehalten werden muss.

Diese ACLs werden beim Zugriff auf die RPCSS-Schnittstellen geprüft. Damit können Sie kontrollieren, wer Zugriff auf diesen Systemdienst hat.

Diese ACLs stellen einen zentralen Speicherort dar, in dem der Administrator allgemeine Autorisierungsrichtlinien festlegen kann, die für alle COM-Server auf dem Computer gelten.

Standardmäßig sind in Windows XP die folgenden Computereinschränkungseinstellungen vorhanden:

Warum ist diese Änderung wichtig? Zur Minderung welcher Probleme trägt dies bei?

Viele COM-Anwendungen enthalten sicherheitsspezifischen Code (z. B. zum Aufrufen von CoInitializeSecurity), verwenden jedoch schwache Einstellungen, die oft unberechtigte Zugriffe zulassen. Derzeit gibt es für den Administrator keine Möglichkeit, diese Einstellungen außer Kraft zu setzen, um in früheren Windows-Versionen die Sicherheit zu erhöhen.

Die COM-Infrastruktur enthält den Systemdienst RpcSs, der beim Systemstart gestartet und danach immer ausgeführt wird. Dieser Dienst verwaltet die Aktivierung von COM-Objekten und die Ausführung der Objekttabelle und stellt Hilfsdienste für DCOM-Remoting bereit. Er enthält RPC-Schnittstellen, die remote aufgerufen werden können. Manche COM-Server erlauben den nicht authentifizierten Remotezugriff (siehe vorherigen Abschnitt), weshalb diese Schnittstellen von jedem Benutzer aufgerufen werden können, auch von nicht authentifizierten Benutzern. Deshalb kann RpcSs von böswilligen Benutzern mithilfe von nicht authentifizierten Remotecomputern angegriffen werden.

In früheren Windows-Versionen konnte der Administrator nicht feststellen, inwieweit die COM-Server auf einem Computer für Benutzer zugänglich sind. Der Administrator konnte zwar systematisch die konfigurierten Sicherheitseinstellungen für alle registrierten COM-Anwendungen auf dem Computer prüfen, aber angesichts der Tatsache, dass in einer Standardinstallation von Windows XP etwa 150 COM-Server vorhanden sind, war dies ein sehr mühsames Unterfangen. Es gab keine Möglichkeit, die Einstellungen für einen Server anzuzeigen, dessen Software Sicherheitseinstellungen aufweist, um sich auf diese Weise das Überprüfen des Quellcodes für die Software zu ersparen.

Die Lösung für diese drei Probleme sind computerweite DCOM-Einschränkungen. Auf diese Weise kann der Administrator außerdem eingehende DCOM-Aktivierungen, -Starts und -Aufrufe deaktivieren.

Was ist anders?

Standardmäßig werden der Gruppe Jeder die Berechtigungen Lokaler Start, Lokale Aktivierung und Lokaler Aufruf erteilt. Damit sollten alle lokalen Szenarien ohne Änderung der Software oder des Betriebssystems möglich sein.

Standardmäßig wird der Gruppe Jeder die Berechtigung Remoteaufruf erteilt. Dies passt für die meisten COM-Clientszenarien, einschließlich des Normalfalls, bei dem ein COM-Client einen lokalen Verweis an einen Remoteserver übergibt und damit der Client zu einem Server wird. Szenarien, die nicht authentifizierte Remoteaufrufe erfordern, sind damit u. U. nicht möglich.

Außerdem werden standardmäßig nur Mitgliedern der Gruppe Administratoren die Berechtigungen für die Remoteaktivierung und das Starten erteilt. Remoteaktivierungen durch Nicht-Administratoren auf installierten COM-Servern sind dann nicht möglich.

Wie kann ich diese Probleme beseitigen?

Angenommen, Sie implementieren einen COM-Server und werden voraussichtlich die Remoteaktivierung durch einen nicht administrativen COM-Client oder nicht authentifizierte Remoteaufrufe unterstützen. In diesem Fall sollten Sie abwägen, ob das durch die Aktivierung verbundene Risiko akzeptabel ist oder ob Sie die Implementierung ändern sollten, damit die Remoteaktivierung durch einen nicht administrativen COM-Client oder nicht authentifizierte Remoteaufrufe nicht erforderlich sind.

Wenn das Risiko akzeptabel ist und Sie die Remoteaktivierung durch einen nicht administrativen COM-Client oder nicht authentifizierte Remoteaufrufe aktivieren möchten, müssen Sie die Standardkonfiguration für diese Funktion ändern.

Die Konfigurationseinstellungen können Sie mithilfe der Komponentendienste-MMC oder der Windows-Registrierung ändern.

Falls Sie das Komponentendienste-MMC-Snap-In verwenden, können diese Einstellungen auf der Registerkarte COM-Sicherheit des Eigenschaftendialogfeldes für den verwalteten Computer geändert werden. Der Bereich Zugriffsberechtigungen wurde geändert, damit Sie neben den Standardeinstellungen für COM-Server computerweite Limits festlegen können. Darüber hinaus sind für Limits und Standardwerte separate ACL-Einstellungen für den lokalen Zugriff und den Remotezugriff möglich.

Im Bereich Start- und Aktivierungsberechtigungen können Sie Berechtigungen für die lokale Aktivierung und die Remoteaktivierung sowie die computerweiten Limits und Standardwerte festlegen. Im Bereich Sicherheitseinstellungen können Sie separate Berechtigungen für die lokale Aktivierung und die Remoteaktivierung sowie Startberechtigungen angeben.

Alternativ können diese ACL-Einstellungen auch in der Registrierung konfiguriert werden.

Diese ACLs sind in der Registrierung in folgenden Registrierungsschlüsseln gespeichert:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole
\MachineAccessRestriction= ACL

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole
\MachineLaunchRestriction= ACL

Dies ist ein benannter Wert, für den ein REG_BINARY-Typ festgelegt ist, der Daten zur Beschreibung der ACL der Prinzipale enthält, die Zugriff auf alle COM-Klassen oder COM-Objekte auf dem Computer haben. In der ACL gibt es folgende Zugriffsrechte:

COM_RIGHTS_EXECUTE 1

COM_RIGHTS_EXECUTE_LOCAL 2

COM_RIGHTS_EXECUTE_REMOTE 4

COM_RIGHTS_ACTIVATE_LOCAL 8

COM_RIGHTS_ACTIVATE_REMOTE 16

Diese ACLs können mithilfe normaler Sicherheitsfunktionen erstellt werden. Beachten Sie, dass COM_RIGHTS_EXECUTE-Rechte immer vorhanden sein müssen, weil sonst eine ungültige Sicherheitsbeschreibung erstellt wird.

Nur Benutzer mit Administratorrechten können diese Einstellungen ändern.

Welche vorhandenen Funktionen ändern sich in Windows XP Service Pack 2?

RPCSS wird als Netzwerkdienst ausgeführt

Ausführliche Beschreibung

In Windows XP SP2 ist RPCSS ein Schlüsseldienst für die RPC-Endpunktzuordnung und die DCOM-Infrastruktur. Dieser Dienst wurde in früheren Windows-Versionen unter dem lokalen Systemkonto ausgeführt. Um die Angriffsfläche von Windows zu reduzieren und einen umfassenden Schutz zu bieten, wurde der RPCSS-Dienst in zwei Dienste aufgeteilt. Der RPCSS-Dienst mit allen ursprünglichen Funktionen, die nicht unter dem lokalen Systemkonto ausgeführt werden mussten, wird nun unter dem Netzwerkdienstkonto ausgeführt. Ein neuer DCOMLaunch-Dienst mit Funktionen, die lokale Systemberechtigungen erfordern, wird unter dem lokalen Systemkonto ausgeführt.

Warum ist diese Änderung wichtig?

Diese Änderung reduziert die Angriffsfläche und bietet einen umfassenden Schutz für den RPCSS-Dienst. Denn die Anhebung der Berechtigung für den RPCSS-Dienst ist nun auf die Netzwerkdienstberechtigung beschränkt.

Was ist anders?

Diese Änderung sollte für die Benutzer nachvollziehbar sein, da die Kombination der RPCSS- und DCOMLaunch-Dienste in Windows XP Service Pack 2 nicht vom vorherigen RPCSS-Dienst aus früheren Windows-Versionen abweicht.

Spezifischere COM-Berechtigungen

Ausführliche Beschreibung

Für COM-Serveranwendungen gibt es zwei Arten von Berechtigungen: Startberechtigungen und Zugriffsberechtigungen. Startberechtigungen bestimmen, wer einen COM-Server während der COM-Aktivierung starten darf, falls der Server noch nicht ausgeführt wird. Diese Berechtigungen sind als Sicherheitsbeschreibungen definiert, die mithilfe von Registrierungseinstellungen angegeben werden. Zugriffsberechtigungen bestimmen, wer einen laufenden COM-Server aufrufen darf. Diese Berechtigungen sind als Sicherheitsbeschreibungen definiert und werden mithilfe der CoInitializeSecurity-API oder mithilfe von Registrierungseinstellungen an die COM-Infrastruktur weitergegeben. Mit Start- und Zugriffsberechtigungen wird der Zugriff anhand von Prinzipalen erteilt oder verweigert. Dabei wird nicht unterschieden, ob es sich um einen lokalen Aufruf oder einen Remoteaufruf handelt.

Eine weitere Änderung unterscheidet die COM-Zugriffsrechte basierend auf der Distanz. Definiert sind die beiden Distanzen als lokale Distanz und als Remotedistanz. Eine lokale COM-Nachricht wird mithilfe des LRPC-Protokolls (Local Remote Procedure Call) empfangen, während eine Remote-COM-Nachricht mithilfe eines RPC-Hostprotokolls (Remote Procedure Call, Remoteprozeduraufruf) wie z. B. TCP (Transmission Control Protocol) empfangen wird.

Bei der COM-Aktivierung wird eine Verbindung mit einem COM-Schnittstellenproxy auf einem Client hergestellt, indem CoCreateInstance oder eine der entsprechenden Varianten aufgerufen wird. Als Nebeneffekt dieses Aktivierungsvorgangs muss manchmal ein COM-Server gestartet werden, um die Anforderung des Clients zu erfüllen. Eine Startberechtigungs-ACL wertet aus, wer einen COM-Server starten darf. Eine Zugriffsberechtigungs-ACL wertet aus, wer ein COM-Objekt aktivieren oder dieses Objekt aufrufen darf, wenn der COM-Server bereits ausgeführt wird.

Eine weitere Änderung ist, dass die Aufruf- und Aktivierungsrechte getrennt wurden. Dies sind nun zwei unterschiedliche Vorgänge, und das Aktivierungsrecht wurde von der Zugriffsberechtigungs-ACL in die Startberechtigungs-ACL verschoben. Da das Aktivieren und Starten in Verbindung mit dem Abrufen eines Schnittstellenzeigers steht, sollten logischerweise die Aktivierungs- und Startzugriffsrechte in einer einzigen ACL vorhanden sein. Und da Sie Startberechtigungen immer durch Konfigurieren festlegen (Zugriffsberechtigungen dagegen oft programmgesteuert), kann der Administrator durch Hinzufügen der Aktivierungsrechte zur Startberechtigungs-ACL die Aktivierung kontrollieren.

Die Startberechtigungs-ACEs (Zugriffssteuerungseintrag, Access Control Entry) sind in vier Zugriffsrechte unterteilt:

Die Sicherheitsbeschreibung für die Zugriffsberechtigungen ist in zwei Zugriffsrechte unterteilt:

Mit dieser COM-Sicherheit kann der Administrator sehr spezifische Sicherheitskonfigurationen anwenden. Beispielsweise können Sie einen COM-Server so konfigurieren, dass er lokale Aufrufe von jedem Benutzer akzeptiert, Remoteaufrufe jedoch nur von Administratoren. Diese Unterscheidungen sind mithilfe von Änderungen an den Sicherheitsbeschreibungen für die COM-Berechtigungen möglich.

Warum ist diese Änderung wichtig? Zur Minderung welcher Probleme trägt dies bei?

In früheren Versionen der COM-Serveranwendung konnte nicht festgelegt werden, dass eine Anwendung nur lokal verwendet wird, nicht aber mithilfe von DCOM im Netzwerk. Ein Benutzer mit Zugriff auf eine COM-Serveranwendung kann diese lokal und remote verwenden.

Eine COM-Serveranwendung sollte ggf. für nicht authentifizierte Benutzer zum Implementieren eines COM-Rückrufszenarios angezeigt werden. In diesem Fall muss auch die Aktivierung der Anwendung für nicht authentifizierte Benutzer verfügbar sein. Dies ist u. U. nicht wünschenswert, weil sich böswillige Benutzer dadurch unbefugten Zugriff auf den Server verschaffen könnten.

Präzise COM-Berechtigungen bieten dem Administrator die Flexibilität, die COM-Berechtigungsrichtlinien eines Computers zu kontrollieren. Diese Berechtigungen ermöglichen Sicherheit für die beschriebenen Szenarien.

Was ist anders? Gibt es Abhängigkeiten?

Für die Abwärtskompatibilität werden vorhandene COM-Sicherheitsbeschreibungen so interpretiert, dass gleichzeitig der lokale Zugriff und der Remotezugriff zugelassen oder abgelehnt wird. Das heißt, mit einem Zugriffssteuerungseintrag (ACE) wird entweder sowohl der lokale Zugriff als auch der Remotezugriff zugelassen oder abgelehnt.

Für Aufruf- oder Startrechte gibt es keine Probleme mit der Abwärtskompatibilität. Es gibt jedoch ein Kompatibilitätsproblem bei den Aktivierungsrechten. Falls in den vorhandenen Sicherheitsbeschreibungen für einen COM-Server die konfigurierten Startberechtigungen restriktiver sind als die Zugriffsberechtigungen und als die Mindestrechte, die für Clientaktivierungsszenarien erforderlich sind, muss die Startberechtigungs-ACL geändert werden, um den autorisierten Clients die entsprechenden Berechtigungen zu erteilen.

Für COM-Anwendungen, die die Standardsicherheitseinstellungen verwenden, gibt es keine Kompatibilitätsprobleme. Für Anwendungen, die dynamisch mit der COM-Aktivierung gestartet werden, gibt es im Normalfall keine Kompatibilitätsprobleme, weil die Startberechtigungen bereits jeden Benutzer einschließen müssen, der ein Objekt aktivieren kann. Falls diese Berechtigungen nicht ordnungsgemäß konfiguriert sind, können willkürliche Aktivierungsfehler auftreten, wenn Aufrufer ohne Startberechtigung versuchen, ein Objekt zu aktivieren, während der COM-Server noch nicht ausgeführt wird.

Die Anwendungen, die die meisten Kompatibilitätsprobleme verursachen, sind COM-Anwendungen, die bereits mit anderen Methoden gestartet wurden, wie z. B. Windows-Explorer oder Dienststeuerungs-Manager. Sie können diese Anwendungen auch mithilfe einer vorherigen COM-Aktivierung starten, die die standardmäßigen Zugriffs- und Startberechtigungen außer Kraft setzt und Startberechtigungen konfiguriert, die restriktiver als die Aufrufberechtigungen sind. Weitere Informationen zum Beheben dieses Kompatibilitätsproblems finden Sie unter "Wie kann ich diese Probleme beseitigen?" im nächsten Abschnitt.

Wenn ein System, das auf Windows XP Service Pack 2 aktualisiert wurde, auf eine frühere Service Pack-Version zurückgesetzt wird, werden alle Zugriffssteuerungseinträge, die bearbeitet wurden, um den lokalen Zugriff und/oder den Remotezugriff zuzulassen, so interpretiert, dass sowohl der lokale Zugriff als auch der Remotezugriff zulässig ist. Jeder ACE, der bearbeitet wurde, um den lokalen Zugriff und/oder den Remotezugriff zu verweigern, wird so interpretiert, dass der lokale Zugriff und der Remotezugriff verweigert wird. Wenn Sie ein Service Pack deinstallieren, sollten Sie überprüfen, ob durch neu konfigurierte ACEs Anwendungen nicht mehr ausgeführt werden.

Wie kann ich diese Probleme beseitigen?

Wenn Sie einen COM-Server implementieren und die Standardsicherheitseinstellungen außer Kraft setzen, sollten Sie bestätigen, dass die anwendungsspezifische Startberechtigungs-ACL den entsprechenden Benutzern die Aktivierungsberechtigung erteilt. Andernfalls müssen Sie die anwendungsspezifische Startberechtigungs-ACL ändern und den entsprechenden Benutzern die Aktivierungsrechte erteilen, damit bei Anwendungen und Windows-Komponenten, die DCOM verwenden, keine Fehler auftreten. Diese anwendungsspezifischen Startberechtigungen werden in der Registrierung gespeichert. Weitere Informationen zu Startberechtigungen finden Sie im Abschnitt zu den Startberechtigungen auf der MSDN-Website unter http://go.microsoft.com/fwlink/?LinkId=20924.

Diese COM-ACLs können mithilfe normaler Sicherheitsfunktionen erstellt oder geändert werden.

Welche Einstellungen wurden in Windows XP Service Pack 2 hinzugefügt oder geändert?

Vorsicht  Die falsche Verwendung dieser Einstellungen kann bei Anwendungen und Windows-Komponenten, die DCOM verwenden, zu Fehlern führen.

In der folgenden Tabelle werden diese Abkürzungen verwendet:

LL – Local Launch (Lokaler Start)

LA – Local Activation (Lokale Aktivierung)

RL – Remote Launch (Remotestart)

RA – Remote Activation (Remoteaktivierung)

LC – Local Control (Lokale Überwachung)

RC – Remote Control (Remoteüberwachung)

Zum Seitenanfang

TCP/IP

Welche Funktion hat TCP/IP?

TCP/IP (Transmission Control Protocol/Internet Protocol) besteht aus Standardprotokollen zum Verbinden von Computern in Netzwerken. Mit TCP/IP werden Windows-basierte Computer miteinander verbunden und können Informationen mit anderen Systemen von Microsoft oder anderen Herstellern gemeinsam nutzen.

Für wen ist diese Funktion gedacht?

Alle Benutzer, die mit TCP/IP eine Verbindung herstellen und Informationen in einem Netzwerk austauschen, sollten die Änderungen in Windows XP Service Pack 2 beachten.

Welche neue Funktionalität wurde in Windows XP Service Pack 2 für diese Funktion hinzugefügt?

Eingeschränkter Datenverkehr über Ursprungssockets

Ausführliche Beschreibung

Einige wenige Windows-Anwendungen verwenden IP-Ursprungssockets. Sie stellen für Anwendungen einen Industriestandard dar, um TCP/IP-Pakete mit weniger Integritäts- und Sicherheitsprüfungen durch den TCP/IP-Stapel zu erstellen. Die Windows-Implementierung von TCP/IP unterstützt weiterhin den Empfang von Datenverkehr auf IP-Ursprungssockets. Die Möglichkeit zum Senden von Datenverkehr über Ursprungssockets wurde jedoch in zweierlei Hinsicht eingeschränkt:

Warum ist diese Änderung wichtig? Zur Minderung welcher Probleme trägt dies bei?

Diese Änderung reduziert die Möglichkeit, dass bösartiger Code verteilte Dienstverweigerungsangriffe generiert und dass manipulierte Pakete gesendet werden, bei denen es sich um TCP/IP-Pakete mit einer gefälschten IP-Quelladresse handelt.

Beschränkte Anzahl gleichzeitiger unvollständiger ausgehender TCP-Verbindungsversuche

Ausführliche Beschreibung

Der TCP/IP-Stapel beschränkt nun die Anzahl gleichzeitiger unvollständiger ausgehender TCP-Verbindungsversuche. Wenn das Limit erreicht wird, werden nachfolgende Verbindungsversuche einer Warteschlange hinzugefügt und in einem bestimmten Zeitraum erneut ausgeführt. Wenn im Normalbetrieb Anwendungen eine Verbindung mit verfügbaren Hosts an gültigen IP-Adressen herstellen, erfolgt keine Beschränkung der Verbindungsrate. Wenn dies dennoch passiert, wird im Ereignisprotokoll des Systems ein neues Ereignis mit der ID 4226 angezeigt.

Warum ist diese Änderung wichtig? Zur Minderung welcher Probleme trägt dies bei?

Mit dieser Änderung wird die Geschwindigkeit reduziert, mit der sich bösartige Programme, wie z. B. Viren und Würmer, auf nicht infizierten Computern verbreiten. Bösartige Programme versuchen oft, nicht infizierte Computer zu erreichen, indem gleichzeitige Verbindungen zu zufälligen IP-Adressen geöffnet werden. Die meisten dieser zufälligen Adressen ergeben einen Verbindungsfehler. Viele derartige Aktivitäten auf einem Computer sind deshalb ein Zeichen dafür, dass er mit einem bösartigen Programm infiziert sein könnte.

Was ist anders?

Diese Änderung kann bewirken, dass bestimmte Sicherheitsprogramme wie z. B. Portscanner langsamer ausgeführt werden.

Wie kann ich diese Probleme beseitigen?

Beenden Sie die Anwendung, die für die fehlerhaften Verbindungsversuche verantwortlich ist.

Winsock-Selbstreparatur

Ausführliche Beschreibung

Winsock, die Netzwerksocketfunktion von Windows für Anwendungen, kann durch einen Mechanismus, der als Mehrschicht-Dienstanbieter (Layered Service Provider, LSP) bezeichnet wird, erweitert werden. Winsock-LSPs haben viele hilfreiche Funktionen, wie z. B. Internetzugangssteuerung und Webinhaltsfilterung. In früheren Windows XP-Versionen konnte das Entfernen eines fehlerhaften LSPs zur Beschädigung des Winsock-Katalogs in der Registrierung und möglicherweise zum Verlust der gesamten Netzwerkkonnektivität führen. Winsock kann sich nun selbst reparieren, nachdem ein Benutzer einen solchen LSP deinstalliert hat.

Warum ist diese Änderung wichtig? Zur Minderung welcher Probleme trägt dies bei?

Die Kunden müssen in der Lage sein, fehlerhaft implementierte LSPs von ihren Systemen zu entfernen, ohne dass es zu Beeinträchtigungen der Sicherheit kommt.

Neue Winsock-Netsh-Befehle

Ausführliche Beschreibung

In Windows XP Service Pack 2 gibt es zwei neue Netsh-Befehle.

Warum ist diese Änderung wichtig? Zur Minderung welcher Probleme trägt dies bei?

Diese Befehle bieten zusätzliche Verwaltungsmöglichkeiten für die Wartung und Problembehandlung von Winsock-LSPs und können in einem Skript für die Wiederherstellung bei vielen installierten fehlerhaften LSPs verwendet werden.

Zum Seitenanfang

RPC-Schnittstelleneinschränkung

Welche Funktion hat die RPC-Schnittstelleneinschränkung?

Beim RPC-Dienst (Remote Procedure Call) für Windows XP Service Pack 2 gibt es eine Reihe von Änderungen, die standardmäßig die Sicherheit von RPC-Schnittstellen garantieren und die Angriffsfläche von Windows XP reduzieren. Die wichtigste Änderung ist der neue RestrictRemoteClients-Registrierungsschlüssel. Dieser Schlüssel ändert das Verhalten aller RPC-Schnittstellen im System und eliminiert abgesehen von ein paar Ausnahmen standardmäßig den anonymen Remotezugriff auf RPC-Schnittstellen im System. Weitere Änderungen sind der EnableAuthEpResolution-Registrierungsschlüssel und drei neue Schnittstellenregistrierungsflags.

Für wen ist diese Funktion gedacht?

Diese Funktion betrifft RPC-Anwendungsentwickler. Systemadministratoren sollten ebenfalls mit dieser RPC-Änderung vertraut sein.

Welche neue Funktionalität wurde in Windows XP Service Pack 2 für diese Funktion hinzugefügt?

RestrictRemoteClients-Registrierungsschlüssel

Ausführliche Beschreibung

Wenn eine Schnittstelle mithilfe von RpcServerRegisterIf registriert wird, kann die Serveranwendung mit RPC den Zugriff auf die Schnittstelle einschränken, und zwar gewöhnlich über einen Sicherheitsrückruf. Der RestrictRemoteClients-Registrierungsschlüssel zwingt RPC zum Ausführen zusätzlicher Sicherheitsprüfungen für alle Schnittstellen, selbst wenn die Schnittstelle keinen registrierten Sicherheitsrückruf aufweist.

RPC-Clients, die die Named Pipe-Protokollsequenz (ncacn_np) verwenden, sind von allen in diesem Abschnitt behandelten Einschränkungen ausgenommen. Die Named Pipe-Protokollsequenz kann aufgrund mehrerer wichtiger Abwärtskompatibilitätsprobleme nicht standardmäßig eingeschränkt werden.

Für den RestrictRemoteClients-Registrierungsschlüssel gibt es drei mögliche DWORD-Werte, die auch programmgesteuert in rpcdce.h gesteuert werden können. Wenn dieser Schlüssel nicht vorhanden ist, entspricht dies der Einstellung DWORD=1 (RPC_RESTRICT_REMOTE_CLIENT_DEFAULT).

Schlüsselinformationen

Schlüsselname: RestrictRemoteClients

Typ: DWORD

Konfigurierbar über Benutzeroberfläche: Ja. Dieser Schlüssel kann mit dem Gruppenrichtlinienobjekt-Editor konfiguriert werden.

Standardwert: 1

Bedeutung: Dies ist der Standardwert in Windows XP Service Pack 2. Er schränkt den Zugriff auf alle RPC-Schnittstellen ein. Alle anonymen Remoteaufrufe werden von der RPC-Laufzeit zurückgewiesen. Dies entspricht dem Wert RPC_RESTRICT_REMOTE_CLIENT_DEFAULT in rpcdce.h. Wenn eine Schnittstelle einen Sicherheitsrückruf registriert und das RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH-Flag übergibt, gilt die Einschränkung nicht für diese Schnittstelle.

Wert: 0

Bedeutung: Hiermit umgeht das System die RPC-Schnittstelleneinschränkung. Dies entspricht dem Wert RPC_RESTRICT_REMOTE_CLIENT_NONE in rpcdce.h. Die Serveranwendung ist allein dafür verantwortlich, dass entsprechende RPC-Einschränkungen auferlegt werden. Diese Einstellung entspricht dem Verhalten in früheren Windows-Versionen.

Wert: 2

Bedeutung: Alle anonymen Remoteaufrufe werden von der RPC-Laufzeit ausnahmslos zurückgewiesen. Dies entspricht dem Wert RPC_RESTRICT_REMOTE_CLIENT_HIGH in rpcdce.h. Wenn dieser Wert festgelegt ist, können mit RPC keine anonymen Remoteaufrufe empfangen werden.

Warum ist diese Änderung wichtig? Zur Minderung welcher Probleme trägt dies bei?

Es ist viel schwieriger, eine Schnittstelle anzugreifen, wenn Aufrufe für die Authentifizierung erforderlich sind, und sei es nur eine relativ niedrige Authentifizierungsebene. Dies ist eine besonders hilfreiche Abwehrmaßnahme gegen Würmer, die auf manipulierbare Pufferüberläufe angewiesen sind, die remote über anonyme Verbindungen gestartet werden können.

Was ist anders?

Wenn Ihre RPC-Anwendung Aufrufe von anonymen Remote RPC-Clients erwartet, wird die Anwendung aufgrund dieser Änderung möglicherweise nicht ordnungsgemäß ausgeführt. Anwendungen, die DCOM verwenden, werden deshalb nicht fehlerfrei ausgeführt, wenn dieser Wert festgelegt ist.

Sichere RPC-Aufrufe über verbindungslose Protokolle wie UDP und IPX (ncadg_ip_udp und ncadg_ipx) verwenden eine niedrigere Sicherheitsstufe als Aufrufe über verbindungsorientierte Protokolle. Deshalb werden diese Aufrufe für diese Richtlinien stets als nicht sicher behandelt. Demzufolge schlagen RPC-Aufrufe über verbindungslose Protokolle in Windows XP SP2 standardmäßig fehl.

Um RPC-Clientaufrufe mit verbindungslosen Protokollen zuzulassen, legen Sie für den RestrictRemoteClients-Schlüssel den Wert 0 fest (RPC_RESTRICT_REMOTE_CLIENT_NONE).

Wie kann ich diese Probleme beseitigen?

Es gibt drei Möglichkeiten, diese Probleme zu beseitigen. Die Möglichkeiten sind nach der Priorität angeordnet.

EnableAuthEpResolution-Registrierungsschlüssel

Ausführliche Beschreibung

Eine RPC-Schnittstelle, die remote und anonym zugänglich ist und standardmäßig in Windows XP registriert wird, stellt eine erhebliche Angriffsfläche dar. RPC selbst muss eine solche Schnittstelle registrieren, um die Endpunktauflösung für Aufrufe mit dynamischen Endpunkten zu ermöglichen.

Durch das standardmäßige Hinzufügen des RestrictRemoteClients-Flags ist der anonyme Zugriff auf die RP-Endpunktzuordnung nicht möglich. Dies ist eine erhebliche Optimierung der Sicherheit, ändert jedoch die Vorgehensweise beim Auflösen eines Endpunktes. Wenn gegenwärtig ein RPC-Client versucht, einen Aufruf mit einem dynamischen Endpunkt durchzuführen, fragt er zuerst die RPC-Endpunktzuordnung auf dem Server ab, um den Endpunkt zu ermitteln, mit dem die Verbindung hergestellt werden soll. Diese Abfrage erfolgt anonym, auch wenn der RPC-Clientaufruf selbst mit RPC-Sicherheit ausgeführt wird.

Anonyme Aufrufe der RPC-Endpunktzuordnung schlagen unter Windows XP Service Pack 2 wegen dem Standardwert für den neuen RestrictRemoteClients-Schlüssel standardmäßig fehl. Deshalb muss die RPC-Clientlaufzeit geändert werden, um eine authentifizierte Abfrage der Endpunktzuordnung auszuführen. Wenn der EnableAuthEpResolution-Schlüssel festgelegt ist, verwendet die RPC-Clientlaufzeit NTLM zum Authentifizieren der Endpunktzuordnung. Diese authentifizierte Abfrage findet nur statt, wenn der eigentliche RPC-Clientaufruf die RPC-Authentifizierung verwendet.

Warum ist diese Änderung wichtig?

Diese Änderung ist erforderlich, damit ein RPC-Client einen RPC-Server aufrufen kann, der einen dynamischen Endpunkt auf einem System unter Windows XP Service Pack 2 registriert hat. Der Clientcomputer muss diesen Registrierungsschlüssel festlegen, damit eine authentifizierte Abfrage der RPC-Endpunktzuordnung ausgeführt wird.

Was ist anders?

Dieser Registrierungsschlüssel ermöglicht das im vorherigen Abschnitt beschriebene Szenario. Wenn dieser Schlüssel aktiviert ist, erfolgen alle Abfragen der RPC-Endpunktzuordnung, die im Auftrag authentifizierter Aufrufe ausgeführt werden, mit der NTLM-Authentifizierung.

Diese Einstellung kann auch mit dem Gruppenrichtlinienobjekt-Editor angegeben werden, um das Gruppenrichtlinienobjekt in Computerkonfiguration \Administrative Vorlagen \System\Remoteprozeduraufruf\RPC-Endpunktzuordnungs-Clientauthentifizierung zu konfigurieren.

Neue Registrierungsflags für die RPC-Schnittstelle

Ausführliche Beschreibung

Es gibt drei neue Registrierungsflags für die RPC-Schnittstelle, mit denen ein Anwendungsentwickler leichter für die Sicherheit einer RPC-Schnittstelle sorgen kann.

Warum ist diese Änderung wichtig?

Diese Änderung liefert RPC-Anwendungsentwicklern zusätzliche Sicherheitsprogramme für die Optimierung der Sicherheit ihrer RPC-Schnittstelle.

Was ist anders?

Durch diese Flags werden keine bestehenden Windows XP-Anwendungen geändert oder fehlerhaft ausgeführt. Es liegt in der Entscheidung des Anwendungsentwicklers, ob er diese neuen Flags verwenden möchte.

Welche Einstellungen wurden in Windows XP Service Pack 2 hinzugefügt oder geändert?

Muss ich den Code ändern, um mit Windows XP Service Pack 2 zu arbeiten?

Möglicherweise müssen Sie den Code für Windows XP Service Pack 2 ändern. Weitere Informationen zu Anwendungsänderungen finden Sie in den vorherigen Abschnitten zu RestrictRemoteClients und EnableAuthEpResolution.

Zum Seitenanfang

WebDAV-Redirector

Welche Funktion hat der WebDAV-Redirector?

Der WebDAV-Redirector (DAVRdr) ermöglicht Computern unter Windows XP die Verwendung von WebDAV-Servern (Web-based Distributed Authoring and Versioning), wie z. B. Windows SharePoint Services und MSN Communities, so als ob es sich um Standarddateiserver handelte. Er besteht aus einer Kernelkomponente, die eine Verbindung zum Remote-Dateisystemstapel von Windows NT herstellt, und einer Benutzerebenenkomponente (Webclientdienst), die Dateisystemanforderungen in WebDAV-Anforderungen übersetzt.

Für wen ist diese Funktion gedacht?

Diese Funktion wird von Benutzern verwendet, die über das Remotedateisystem auf WebDAV-Server zugreifen. Der WebDAV-Redirector ist im Remote-Dateisystemstapel implementiert. Clientadministratoren und Benutzer, die um die Sicherheit ihrer Computeranmeldeinformationen besorgt sind, müssen beachten, dass jeder Zugriff auf Remotedateien auf einem WebDAV-Server durch UNC (Universal Naming Convention) (z. B. \\Servername\Freigabename\Datei.txt) vom WebDAV-Redirector verarbeitet wird.

Welche neue Funktionalität wurde in Windows XP Service Pack 2 für diese Funktion hinzugefügt?

Standardauthentifizierung über einen unverschlüsselten Kanal deaktivieren

Ausführliche Beschreibung

WebDAV ist eine Erweiterung von HTTP (Hypertext Transfer Protocol) und beinhaltet die Verwendung der Standardauthentifizierung (BasicAuth). BasicAuth ist eine Form der Benutzerauthentifizierung bzw. eine Methode, mit der ein Benutzer auf sichere Weise für den Server identifiziert wird. Mit BasicAuth überträgt der Client die Anmeldeinformationen des Benutzers (Benutzername und Kennwort) an den Server. Wenn der Kanal unverschlüsselt ist, wie das bei regulärem HTTP-Datenverkehr der Fall ist, sieht jeder Computer im Netzwerk den Benutzernamen und das Kennwort des Benutzers und kann diese Identität annehmen. Der DAVRdr unterstützt keinen verschlüsselten HTTP-Datenverkehr (HTTPS oder SSL) und überträgt die Anmeldeinformationen des Benutzers unverschlüsselt, wenn der Server die Standardauthentifizierung unterstützt. Höchstwahrscheinlich ist für einen Server nicht die Standardauthentifizierung konfiguriert, aber es wäre möglich, dies für den Server einzurichten, um Anmeldeinformationen von Benutzern abzurufen.

Deshalb kann in Windows XP Service Pack 2 (SP) die Verwendung von BasicAuth durch den DAVRdr aktiviert bzw. deaktiviert werden. Standardmäßig ist die Verwendung von BasicAuth in SP2 deaktiviert. Wenn BasicAuth deaktiviert ist, verwendet der Client entweder eine andere Authentifizierungsmethode (soweit vom Server unterstützt), oder die Anforderung schlägt fehl.

Warum ist diese Änderung wichtig?

Benutzer können sich an WebDAV-Servern für den Remotedateizugriff anmelden, ohne befürchten zu müssen, dass ihr Kennwort unverschlüsselt übertragen wird.

Zur Minderung welcher Probleme trägt dies bei?

Angenommen, ein Benutzer bei Contoso Corporation greift routinemäßig auf die Dateifreigabe \\Contoso_Server\Sales außerhalb des Unternehmens in einem öffentlichen Netzwerk zu und verwendet eine Anwendung, die im Rahmen der normalen Hintergrundaktivität auf diese Freigabe zuzugreifen versucht. Da sich der tragbare Computer des Benutzers außerhalb des Firmennetzwerks befindet, sollte die Anforderung fehlschlagen. Der DAVRdr überträgt jedoch eine Anforderung, um festzustellen, ob ein DAV-Server namens Contoso_Server vorhanden ist, obwohl der aktuelle Server, auf den der tragbare Computer zuzugreifen versucht, ein SMB-Server ist.

Ein Hacker kann in demselben öffentlichen Netzwerk einen Computer verwenden, der WINS-Anforderungen abfängt und als Antwort auf WINS-Anforderungen einen Zeiger auf sich selbst zurückgibt. Der tragbare Computer wird dann versuchen, auf eine DAV-Freigabe auf diesen nicht autorisierten Server zuzugreifen. Antwortet der nicht autorisierte Server mit BasicAuth als Authentifizierungsmethode, wird ein Dialogfeld angezeigt, in dem zur Eingabe der Anmeldeinformationen des Benutzers aufgefordert wird. Im Dialogfeld wird der Server als Contoso_Server identifiziert, wodurch der Benutzer zur Annahme verleitet wird, dass es sich um eine rechtmäßige Anforderung handelt. Wenn der Benutzer seinen Benutzernamen und sein Kennwort eingibt, überträgt der Client diese Informationen unverschlüsselt, und der Hacker verschafft sich auf diese Weise Zugriff auf die Anmeldeinformationen des Benutzers. Für den Benutzer gibt es kein Indiz, dass der Kanal nicht sicher ist, dass die Anforderung vom DAVRdr verarbeitet wird oder dass der tragbare Computer den Benutzernamen und das Kennwort unverschlüsselt übertragen wird. Beachten Sie, dass mit den aktuellen standardmäßigen Windows-Authentifizierungsmethoden das Kennwort eines Benutzers niemals unverschlüsselt übertragen wird.

Was ist anders?

Die Änderung des Standardverhaltens betrifft nur den DAVRdr. Deshalb treten nur bei Szenarien, für die die Standardauthentifizierung erforderlich ist und die den DAVRdr verwenden, Fehler auf. Ein Beispiel hierfür ist der Zugriff mit Notepad.exe auf eine Website, die nur BasicAuth zulässt. Dieses Szenario ist nicht mehr möglich. Außerdem können, selbst wenn für den Server nur die Standardauthentifizierung konfiguriert wurde, andere Anwendungen wie Microsoft Office weiterhin verwendet werden, da sie einen anderen DAV-Client verwenden.

Wie kann ich diese Probleme beseitigen?

Zum Aktivieren von BasicAuth können Sie den folgenden Registrierungsschlüssel hinzufügen und auf einen Wert ungleich Null festlegen:

HKEY_LOCAL_MACHINE\SYSTEM
\CurrentControlSet\Services \WebClient\Parameters\UseBasicAuth (DWORD)

Wenn Sie den Registrierungsschlüssel löschen oder auf 0 zurücksetzen, wird das Standardverhalten wiederhergestellt, also die Verwendung von BasicAuth deaktiviert.

WININET: Standardauthentifizierung über einen unverschlüsselten Kanal deaktivieren

Ausführliche Beschreibung

DAVRdr ist Teil des Remote-Dateisystemstapels, weshalb ein Computer Angriffen ausgesetzt ist, sobald versucht wird, per Remotezugriff auf Dateien zuzugreifen. Die Bedrohung für andere Anwendungen, die die Internet-APIs verwenden, ist zwar im Vergleich zum DAVRdr geringer, aber ein ähnlicher Angriff ist möglich, wenn eine Anwendung (oder der Benutzer) auf einen URL zugreift. Aus diesem Grund gibt es in WinInet den Mechanismus, mit dem der DAVRdr BasicAuth für andere Benutzer der Internet-APIs deaktiviert.

In Windows XP Service Pack 2 gibt es zwei Methoden, um die Verwendung der Standardauthentifizierung über unverschlüsselte Kanäle zu blockieren:

Warum ist diese Änderung wichtig?

Benutzer können sich an WebDAV-Servern für den Remotedateizugriff anmelden, ohne befürchten zu müssen, dass ihr Kennwort unverschlüsselt übertragen wird.

Zur Minderung welcher Probleme trägt dies bei?

Angenommen, ein Firmenbenutzer greift routinemäßig auf die Website http://www.contoso.com/sales zu. Wenn sich der Benutzer außerhalb des Unternehmens in einem öffentlichen Netzwerk befindet, versucht er mit Internet Explorer diese Site zu öffnen. Da sich der Laptop außerhalb des Unternehmens befindet, sollte die Anforderung mit der Fehlermeldung "Server nicht gefunden" fehlschlagen. Ein Hacker kann in demselben öffentlichen Netzwerk einen Computer verwenden, der WINS-Anforderungen abfängt und als Antwort auf WINS-Lookups einen Zeiger auf sich selbst zurückgibt. Der Laptop versucht dann, die HTTP-Anforderung zu senden, um die Seite von dem nicht autorisierten Server zu laden. Antwortet der nicht autorisierte Server mit BasicAuth als Authentifizierungsmethode, wird der Benutzer vom Laptop zur Eingabe seiner Anmeldeinformationen aufgefordert. Die Site http://www.contoso.com/sales wird identifiziert, wodurch der Benutzer zur Annahme verleitet wird, dass es sich um eine rechtmäßige Anforderung handelt. Wenn der Benutzer seinen Benutzernamen und sein Kennwort eingibt, überträgt der Client diese Informationen unverschlüsselt, und der Hacker verschafft sich auf diese Weise Zugriff auf die Anmeldeinformationen des Benutzers. Für den Benutzer gibt es kein Indiz, dass der Kanal nicht sicher ist, oder dass der Laptop den Benutzernamen und das Kennwort unverschlüsselt übertragen wird.

Was ist anders?

Standardmäßig gibt es für WININET-Anwendungen keine Änderung des Verhaltens (außer wie oben beschrieben für den DAVRdr). Wenn diese Einstellung deaktiviert ist, kann der Benutzer keine Verbindung mit HTTP-Servern herstellen, die nur die Standardauthentifizierung unterstützen.

Welche Einstellungen wurden in Windows XP Service Pack 2 hinzugefügt oder geändert?

Muss ich den Code ändern, um mit Windows XP Service Pack 2 zu arbeiten?

Es sind keine Änderungen erforderlich. Wenn Entwickler Anwendungen erstellen, die die Internet-APIs verwenden, und BasicAuth deaktivieren möchten, wie z. B. DAVRdr, können sie einen Aufruf von InternetSetOptions() hinzufügen.

Zum Seitenanfang

Windows-Firewall

Welche Funktion hat der Windows-Firewall?

Der Windows-Firewall (früher Internetverbindungsfirewall oder Internet Connection Firewall [ICF]) ist ein softwarebasierter und statusbehafteter Filterfirewall für Microsoft Windows XP. Der Windows-Firewall bietet Schutz für Computer, die mit einem Netzwerk verbunden sind, indem nicht angeforderter eingehender Datenverkehr über IPv4 (TCP/IP, Version 4) und Ipv6 (TCP/IP, Version 6) verhindert wird. Es gibt die folgenden Konfigurationsoptionen:

Für wen ist diese Funktion gedacht?

Diese Funktion ist gedacht für:

Welche neue Funktionalität wurde in Windows XP Service Pack 2 für diese Funktion hinzugefügt?

Standardmäßig aktiviert

Ausführliche Beschreibung

Der Windows-Firewall wird standardmäßig für alle Netzwerkschnittstellen aktiviert. Dies bietet standardmäßig einen besseren Netzwerkschutz für Windows XP bei Neuinstallationen und Updates. Zudem werden auch neue Netzwerkverbindungen geschützt, die dem System hinzugefügt werden. Dies gilt für IPv4- und IPv6-Datenverkehr, und der Windows-Firewall ist sogar aktiviert, wenn bereits ein anderer Firewall im System vorhanden ist.

Warum ist diese Änderung wichtig? Zur Minderung welcher Probleme trägt dies bei?

Vor Windows XP Service Pack 2 wurde Windows XP standardmäßig mit deaktiviertem Internetverbindungsfirewall ausgeliefert. Der Benutzer musste entweder einen Assistenten ausführen oder den Ordner Netzwerkverbindungen durchsuchen, um den Windows-Firewall manuell zu aktivieren. Dies erwies sich für viele Benutzer als zu schwierig, weshalb auf vielen Computern kein Firewallschutz vorhanden war.

Durch die standardmäßige Aktivierung des Windows-Firewalls ist der Computer besser vor vielen netzwerkbasierten Angriffen geschützt. Der jüngste MSBlaster-Angriff hätte vermutlich viel weniger Schaden angerichtet, wenn der Windows-Firewall standardmäßig aktiviert gewesen wäre, und zwar unabhängig davon, ob die aktuellen Patches installiert gewesen wären.

Was ist anders?

Nach dem Installieren von Windows XP Service Pack 2 ist der Windows-Firewall standardmäßig aktiviert. Es kann deshalb sein, dass eine Anwendung inkompatibel ist, wenn sie standardmäßig nicht mit der statusbehafteten Filterung verwendet werden kann.

Wie kann ich diese Probleme beseitigen?

Wie Sie eine Anwendung für die Verwendung mit dem Windows-Firewall ändern, wird weiter unten in diesem Dokument ausführlich unter "Muss ich den Code ändern, um mit Windows XP Service Pack 2 zu arbeiten?" beschrieben.

Sicherheit beim Systemstart

Ausführliche Beschreibung

In Windows-Versionen verstrich eine gewisse Zeit zwischen der Aktivierung des Netzwerks und dem Schutz durch den Internetverbindungsfirewall. Deshalb konnte ein Paket nicht empfangen und an einen Dienst übermittelt werden, ohne dass der Internetverbindungsfirewall die Filterung ermöglichte. Der Computer war dabei Sicherheitsrisiken ausgesetzt. Denn der Firewalltreiber führte die Filterung erst aus, wenn der Firewall-Benutzermodusdienst geladen war und entsprechende Richtlinien angewandt hatte. Der Firewalldienst weist eine Reihe von Abhängigkeiten auf. Der Dienst wartet deshalb, bis diese Abhängigkeiten beseitigt sind, bevor die Richtlinien an den Treiber weitergegeben werden. Dieser Zeitraum hängt von der Geschwindigkeit des Computers ab.

In Windows XP Service Pack 2 weisen die IPv4- und IPv6-Firewalltreiber eine statische Regel für die statusbehaftete Filterung auf. Diese statische Regel wird als Startzeitrichtlinie bezeichnet. Hiermit kann der Computer grundlegende Netzwerktasks ausführen, wie z. B. DNS und DHCP, und mit einem Domänencontroller kommunizieren, um die Richtlinien abzurufen. Wenn der Windows-Firewalldienst ausgeführt wird, lädt er die Laufzeitrichtlinien und wendet sie an und entfernt die Startzeitfilter. Die Startzeitrichtlinien können nicht konfiguriert werden.

Beim Systemstart gibt es keine Sicherheit, wenn der Windows-Firewalldenst (der im Dienststeuerungs-Manager als Windows-Firewall/Gemeinsame Nutzung der Internetverbindung aufgeführt ist) beendet und auf Manuell oder Deaktiviert festgelegt wird.

Warum ist diese Änderung wichtig? Zur Minderung welcher Probleme trägt dies bei?

Durch diese Änderung ist der Computer beim Starten und Herunterfahren weniger Angriffen ausgesetzt.

Was ist anders?

Wenn der Windows-Firewalldienst nicht gestartet werden kann, ist die Sicherheit beim Systemstart weiterhin gegeben. Dies bedeutet, dass alle eingehenden Verbindungen blockiert werden. In diesem Fall kann ein Administrator keine Problembehandlung per Remotezugriff vornehmen, weil alle Ports blockiert werden, einschließlich des von Remotedesktop verwendeten Ports.

Wie kann ich diese Probleme beseitigen?

Um die Sicherheit beim Systemstart zu deaktivieren, beenden Sie den Dienst Windows-Firewall/Gemeinsame Nutzung der Internetverbindung, und legen Sie als Starttyp Manuell oder Deaktiviert fest.

Wenn sich der Computer im Startsicherheitsmodus befindet, weil der Firewalldienst nicht gestartet wurde, muss sich ein Administrator an der Konsole anmelden, die Fehlerursache beseitigen und dann den Firewalldienst manuell starten.

Globale Konfiguration

Ausführliche Beschreibung

In früheren Windows-Versionen wurde der Windows-Firewall pro Schnittstelle konfiguriert. Dies bedeutet, dass es für jede Netzwerkverbindung eigene Firewalleinstellungen gab, z. B. bestimmte Einstellungen für drahtlose Verbindungen und andere für Ethernet-Verbindungen. Dies erschwerte die Synchronisierung von Firewalleinstellungen für verschiedene Verbindungen. Außerdem wiesen neue Verbindungen nicht die Konfigurationsänderungen auf, die an vorhandenen Verbindungen vorgenommen wurden. Nicht standardmäßige Netzwerkverbindungen, wie z. B. von proprietären Wählhilfen erstellte (z. B. vom ISP konfigurierte DFÜ-Netzwerkverbindungen), konnten nicht geschützt werden.

Wenn bei der globalen Konfiguration eine Konfigurationsänderung vorgenommen wird, wird diese automatisch für alle Netzwerkverbindungen im Ordner Netzwerkverbindungen übernommen, einschließlich Wählhilfen, die nicht von Microsoft stammen. Für neu erstellte Verbindungen wird die Konfiguration ebenfalls übernommen. Die Konfiguration ist weiterhin pro Schnittstelle möglich. Für nicht standardmäßige Netzwerkverbindungen gibt es nur die globale Konfiguration. Konfigurationsänderungen gelten auch für IPv4 und IPv6.

Warum ist diese Änderung wichtig?

Globale Richtlinien vereinfachen für den Benutzer die Verwaltung der Firewallrichtlinien für alle Netzwerkverbindungen und ermöglichen die Konfiguration mithilfe der Gruppenrichtlinien. Außerdem können mithilfe einer einzigen Konfigurationsoption Anwendungen für jede Schnittstelle aktiviert werden.

Was ist anders?

In früheren Windows-Versionen erfolgte die Firewallkonfiguration pro Schnittstelle. In Windows XP Service Pack 2 erfolgt die Konfiguration global und gilt für IPv4 und IPv6.

Wie kann ich diese Probleme beseitigen?

Wenn Ihre Anwendung oder Ihr Dienst statisch geöffnet werden muss, sollten Sie die Ports global öffnen. Weitere Informationen hierzu finden Sie weiter unten unter "Muss ich den Code ändern, um mit Windows XP Service Pack 2 zu arbeiten?".

Datenverkehrsbereich für Ausnahmen

Ausführliche Beschreibung

ICF erlaubte erwarteten Datenverkehr von jeder beliebigen IPv4-Adresse. Mit dem Windows-Firewall in Windows XP Service Pack 2 können Sie auch eine Ausnahme konfigurieren, um nur eingehenden Datenverkehr von Adressen zuzulassen, die direkt erreichbar sind (Bereichsoption Nur für eigenes Netzwerk (Subnetz); basierend auf den Einträgen in den IPv4- und IPv6-Routingtabellen), oder von bestimmten IPv4-Adressen und bestimmten IPv4-Adressbereichen (Bereichsoption Benutzerdefinierte Liste).

Wenn die integrierte Ausnahme für die Datei- und Druckerfreigabe mit der NetShare-API, dem Netzwerkinstallations-Assistenten oder über die Windows-Firewall-Benutzeroberfläche aktiviert wird, können eingehende Verbindungsanforderungen für die Datei- und Druckerfreigabe standardmäßig nur von direkt erreichbaren Adressen stammen.

Für Computer in einer Arbeitsgruppe sind bestimmte Ausnahmen standardmäßig auf lokal erreichbare Adressen beschränkt. Diese Ausnahmen werden für die Datei- und Druckerfreigabe und das UPnP™-Framework (Universal Plug and Play, universelles Plug und Play) benötigt. Wenn diese Ausnahmen außerdem für lokale erreichbare Adressen auf einem Host für die gemeinsame Nutzung der Internetverbindung geöffnet werden, werden die Ausnahmen nicht in der öffentlichen ICS-Schnittstelle geöffnet. Wenn Sie diese Ausnahmen für alle möglichen Adressen aktivieren, werden sie in der öffentlichen ICS-Schnittstelle geöffnet, was nicht empfehlenswert ist.

Es wird empfohlen, die Einschränkung auf lokal erreichbare Adressen auf jede Ausnahme anzuwenden, die für die Kommunikation im lokalen Netzwerk verwendet wird. Dies ist programmgesteuert, über das Netsh-Hilfsprogramm des Windows-Firewalls oder über die Benutzeroberfläche des Windows-Firewalls möglich.

Warum ist diese Änderung wichtig? Zur Minderung welcher Probleme trägt dies bei?

Manche Anwendungen müssen nur mit anderen Hosts im lokalen Netzwerk kommunizieren, jedoch nicht mit Hosts im Internet. Wenn Sie den Windows-Firewall so konfigurieren, dass nur Datenverkehr von lokal erreichbaren Adressen oder von bestimmten Adressbereichen, die lokal verbundenen Subnetzen entsprechen, zulässig ist, wird nicht angeforderter eingehender Datenverkehr nur von bestimmten Adressen akzeptiert. Dadurch werden mögliche Angriffe im Zusammenhang mit aktivierten Ausnahmen zwar reduziert, aber nicht eliminiert.

Was ist anders?

Wenn die integrierte Ausnahme für die Datei- und Druckerfreigabe auf einem Computer aktiviert ist, der zu einer Arbeitsgruppe gehört, sind vier Ports besonders von der Einschränkung auf lokal erreichbare Adressen betroffen. Die folgenden Ports empfangen nur Datenverkehr von lokal erreichbaren Adressen:

Wenn eine Anwendung oder ein Dienst diese Ports verwendet, ist nur die Kommunikation mit anderen Knoten möglich, denen lokal erreichbare Adressen zugewiesen sind.

Wenn das UPnP-Framework aktiviert ist, sind zwei Ports besonders von der Einschränkung auf lokal erreichbare Adressen betroffen und empfangen nur Datenverkehr von lokal erreichbaren Adressen:

Wie kann ich diese Probleme beseitigen?

Wenn Ihre Anwendung oder Ihr Dienst mit dieser Einschränkung nicht kompatibel ist, sollten Sie den Port für globale Verbindungen öffnen. Weitere Informationen hierzu finden Sie weiter unten in diesem Dokument unter "Muss ich den Code ändern, um mit Windows XP Service Pack 2 zu arbeiten?".

Befehlszeilenunterstützung

Ausführliche Beschreibung

Das Netsh-Hilfsprogramm des Windows-Firewalls wurde Windows XP im Advanced Networking Pack hinzugefügt. Dieses Hilfsprogramm betraf nur den IPv6-Windows-Firewall. Mit Windows XP Service Pack 2 ändert sich der Aufbau und die Syntax des Hilfsprogramms. Außerdem wird nun auch das Konfigurieren von IPv4 unterstützt. Mit dem Netsh-Hilfsprogramm können Sie den Windows-Firewall vollständig konfigurieren:

Warum ist diese Änderung wichtig?

Durch die Bereitstellung einer Befehlszeilenschnittstelle können Administratoren den Windows-Firewall ohne die grafische Benutzeroberfläche konfigurieren. Die Befehlszeilenschnittstelle kann in Anmeldeskripts und für die Remoteverwaltung verwendet werden.

Was ist anders?

Jedes Skript, das mit dem Netsh-Hilfsprogramm des Advanced Networking Packs für Windows XP erstellt wurde, kann nicht mehr verwendet werden und muss aktualisiert werden.

Betriebsmodus "Aktiv ohne Ausnahmen"

Ausführliche Beschreibung

Für den Windows-Firewall können Ausnahmen so konfiguriert werden, dass bestimmter nicht angeforderter eingehender Datenverkehr während des normalen Betriebs zulässig ist. Denn normalerweise müssen wichtige Szenarien, wie z. B. die Datei- und Druckerfreigabe, aktiviert werden. Falls in einem oder mehreren Überwachungsdiensten oder Anwendungen, die auf dem Computer ausgeführt werden, ein Sicherheitsproblem gefunden wird, muss der Computer möglicherweise auf einen Nur-Client-Modus umstellen, der als Aktiv ohne Ausnahmen bezeichnet wird. Beim Umschalten in diesen Nur-Client-Modus wird der Windows-Firewall so konfiguriert, dass der gesamte nicht angeforderte eingehende Datenverkehr abgelehnt wird, ohne dass der Firewall neu konfiguriert werden muss.

In diesem Modus werden alle Ausnahmen vorübergehend deaktiviert und alle bestehenden Verbindungen getrennt. Alle API-Aufrufe des Windows-Firewalls zum Erstellen einer Ausnahme sind zulässig, und die angeforderte Firewallkonfiguration wird gespeichert, aber erst aktiviert, wenn wieder auf den normalen Betriebsmodus zurückgestellt wird. Alle Überwachungsanforderungen durch Anwendungen werden ebenfalls ignoriert.

Warum ist diese Änderung wichtig? Zur Minderung welcher Probleme trägt dies bei?

Viren, Würmer und Angreifer suchen nach Sicherheitslücken in Diensten. In diesem Betriebsmodus trägt der Windows-Firewall zur Verhinderung dieser Art von Angriffen bei.

Was ist anders?

In diesem Betriebsmodus kann der Computer keine Anforderungen aus dem Netzwerk überwachen. Alle bestehenden eingehenden Verbindungen werden beendet. Nur ausgehende Verbindungen sind zulässig.

Wie kann ich diese Probleme beseitigen?

In diesem Betriebsmodus werden voraussichtlich einige Funktionen wegen der konfigurierten hohen Netzwerksicherheit fehlschlagen. Sie können Funktionalität wiederherstellen, indem Sie wieder auf den Standardbetriebsmodus Ein umstellen. Dies sollte erst ausgeführt werden, nachdem die Bedrohung identifiziert und beseitigt wurde, weil durch diese Maßnahme die Sicherheit des Computers reduziert wird.

Programmbasierte Ausnahmen

Ausführliche Beschreibung

Manche Programme (Anwendungen oder Dienste) dienen gleichzeitig als Netzwerkclients und als Netzwerkserver. Wenn sie als Server verwendet werden, müssen sie nicht angeforderten eingehenden Datenverkehr zulassen, weil sie nicht im Voraus den Peer kennen.

In früheren Windows-Versionen musste ein Programm die Firewall-APIs aufrufen, damit die erforderlichen Überwachungsports geöffnet werden. Dies erwies sich bei Peer-zu-Peer-Situationen als schwierig, wenn der Port nicht im Voraus bekannt war. Das Programm musste den Port nach Abschluss der Kommunikation schließen. Andernfalls gab es unnötige Lücken im Firewall, falls das Programm unerwartet beendet wurde.

Darüber hinaus konnten diese Ports nur geöffnet werden, wenn Programme im Sicherheitskontext eines lokalen Administrators ausgeführt wurden. Dies widersprach dem Prinzip der geringsten Berechtigungen, weil die Programme nicht mit möglichst geringen Berechtigungen, sondern unter einem Administratorkonto ausgeführt werden mussten.

In Windows XP Service Pack 2 kann ein Programm, das das Netzwerk überwachen muss, der Windows-Firewall-Ausnahmenliste hinzugefügt werden. Falls ein Programm in der Windows-Firewall-Ausnahmenliste vorhanden ist, öffnet und schließt Windows die erforderlichen Überwachungsports automatisch, unabhängig vom Sicherheitskontext des Programms. Weitere Informationen zum Hinzufügen von Programmen zur Windows-Firewall-Ausnahmenliste finden Sie unter "Wie kann ich diese Probleme beseitigen?" weiter unten in diesem Dokument.

Hinweis  Programme, die die statusbehaftete Filterung verwenden, müssen nicht der Windows-Firewall-Ausnahmenliste hinzugefügt werden. Nur Administratoren können der Windows-Firewall-Ausnahmenliste ein Programm hinzufügen.

Warum ist diese Änderung wichtig? Zur Minderung welcher Probleme trägt dies bei?

Wenn ein Programm in der Windows-Firewall-Ausnahmenliste aufgeführt ist, werden nur die erforderlichen Ports geöffnet. Und sie sind nur so lange geöffnet, wie das Programm diese Ports überwacht. Ein Programm kann keinen Port öffnen, den es nicht verwendet, wodurch absichtlich oder versehentlich ein anderes Programm oder ein anderer Dienst für Netzwerkverkehr von diesem Port zugänglich wäre.

Dadurch können auch Programme, die das Netzwerk überwachen, unter einem Konto mit geringeren Berechtigungen ausgeführt werden. In früheren Windows-Versionen musste der Benutzer diese Programme mit Administratorrechten ausführen.

Was ist anders?

Falls ein Programm das Netzwerk überwachen muss, muss es in der Windows-Firewall-Ausnahmenliste aufgeführt werden. Andernfalls werden die erforderlichen Ports im Windows-Firewall nicht geöffnet, und das Programm kann angeforderten eingehenden Datenverkehr nicht empfangen.

Wie kann ich diese Probleme beseitigen?

Es gibt fünf Möglichkeiten, um ein Programm der Windows-Firewall-Ausnahmenliste hinzuzufügen:

Mehrfachprofile

Ausführliche Beschreibung

Durch die Unterstützung mehrerer Profile im Windows-Firewall können Sie zwei Firewallrichtlinien erstellen, nämlich eine für den Fall, dass der Computer mit einem verwalteten Netzwerk verbunden ist, und eine zweite für den Fall, dass der Computer nicht verbunden ist. Wenn der Computer mit dem Firmennetzwerk verbunden ist, können Sie weniger strikte Einstellungen definieren, damit die Geschäftsanwendungen ordnungsgemäß ausgeführt werden. Sie können auch aggressivere Sicherheitsrichtlinien für den Fall verwenden, dass sich der Computer außerhalb des verwalteten Netzwerks befindet, wodurch mobile Benutzer geschützt werden.

HInweis  Mehrfachprofile für den Windows-Firewall betreffen nur Computer, die einer Domäne angehören. Computer in einer Arbeitsgruppe haben nur ein Profil.

Warum ist diese Änderung wichtig? Zur Minderung welcher Probleme trägt dies bei?

Für einen mobilen Computer sollte möglichst mehr als eine Firewallkonfiguration vorhanden sein. Oft ist eine in einem Firmennetzwerk sichere Konfiguration anfällig für Angriffe aus dem Internet. Deshalb spielt die Möglichkeit, Ports im Firmennetzwerk, aber nicht in anderen Netzwerken zu öffnen, eine wichtige Rolle. Denn dadurch kann sichergestellt werden, dass immer nur die erforderlichen Ports geöffnet sind.

Was ist anders?

Wenn eine Anwendung in der Windows-Firewall-Ausnahmenliste aufgeführt sein muss, damit sie ordnungsgemäß ausgeführt wird, kann sie möglicherweise nicht in beiden Netzwerken verwendet werden, da die beiden Profile nicht dieselben Richtlinien aufweisen. Um eine Anwendung in allen Netzwerken verwenden zu können, muss sie in beiden Profilen aufgeführt sein. (Weitere Informationen zur Windows-Firewall-Ausnahmenliste finden Sie weiter oben.)

Wie kann ich diese Probleme beseitigen?

Wenn der Computer einer Domäne hinzugefügt wird, müssen Sie darauf achten, dass die Anwendung in beiden Firewallkonfigurationen aufgeführt ist.

RPC-Unterstützung für Systemdienste

Ausführliche Beschreibung

In früheren Windows-Versionen blockierte der Internetverbindungsfirewall die RPC-Kommunikation (Remote Procedure Call, Remoteprozeduraufruf). Der Internetverbindungsfirewall konnte zwar so konfiguriert werden, dass Netzwerkverkehr zur RPC-Endpunktzuordnung zulässig war, aber der von RPC verwendete Port war unbekannt, und bei der Ausführung der Anwendung wurde dennoch ein Fehler gemeldet.

Bei vielen Unternehmensanwendungen und -komponenten tritt ein Fehler auf, wenn RPC nicht im Netzwerk kommunizieren darf. Einige Beispiele hierfür:

RPC öffnet mehrere Ports und macht viele unterschiedliche Server an diesen Ports zugänglich. Da in Windows XP so viele RPC-Server vorhanden sind, geht der Windows-Firewall für Systemdienste, die RPC verwenden, einen anderen Weg. Der Windows-Firewall akzeptiert diese Anforderung nur, wenn der Aufruf im Sicherheitskontext Lokales System, Netzwerkdienst oder Lokaler Dienst ausgeführt wird.

Warum ist diese Änderung wichtig? Zur Minderung welcher Probleme trägt dies bei?

Um Szenarien für die Remoteverwaltung zu ermöglichen, müssen bei vielen unternehmensweiten Bereitstellungen die Systemdienste, die RPC verwenden, standardmäßig mit dem Windows Firewall verwendet werden. Mit einer höheren Präzision können Sie bestimmen, welche RPC-Dienste im Netzwerk verfügbar sind.

Was ist anders?

Standardmäßig kann RPC nicht über einen Windows-Firewall verwendet werden. Alle Systemdienste, die RPC verwenden, sind davon betroffen. Der Windows-Firewall kann jedoch so konfiguriert werden, dass RPC für diese Dienste verwendet werden kann.

Wie kann ich diese Probleme beseitigen?

Weitere Informationen finden Sie unter "Muss ich den Code ändern, um mit Windows XP Service Pack 2 zu arbeiten?" weiter unten in diesem Dokument

Wiederherstellen der Standardeinstellungen

Ausführliche Beschreibung

Früher gab es für Benutzer keine Möglichkeit, die Konfiguration des Windows-Firewalls zurückzusetzen. Im Laufe der Zeit kann es passieren, dass die Konfiguration des Windows-Firewalls nicht angeforderten eingehenden Datenverkehr zulässt, indem der Windows-Firewall-Ausnahmenliste Anwendungen oder Ports hinzugefügt werden. Dies erschwert es dem Benutzer, auf einfache und schnelle Weise eine Standardkonfiguration wiederherzustellen.

Mit dieser Option kann der Benutzer die ursprünglichen Standardeinstellungen des Windows-Firewalls wiederherstellen. Darüber hinaus können die Windows-Firewall-Standardeinstellungen von Originalcomputerherstellern (Original Equipment Manufacturer, OEM) und Unternehmen geändert werden, um benutzerdefinierte Standardkonfigurationsoptionen zu ermöglichen.

Warum ist diese Änderung wichtig?

Mit dieser Option können Endbenutzer die ursprünglichen Standardeinstellungen des Windows-Firewalls wiederherstellen.

Was ist anders?

Hierdurch ergeben sich im Windows-Firewall keine Änderungen bei der Funktionalität. Durch die Verwendung dieser Funktion werden jedoch die gemeinsame Nutzung der Internetverbindung und die Netzwerkbrücke deaktiviert.

Unterstützung der unbeaufsichtigten Installation

Ausführliche Beschreibung

In früheren Windows-Versionen konnte der Internetverbindungsfirewall nicht während der Installation konfiguriert werden. Dies erschwerte Originalcomputerherstellern (OEMs) und Unternehmen das Vorkonfigurieren des Internetverbindungsfirewalls vor der Weitergabe des Computers an die Endbenutzer. In Windows XP Service Pack 2 können Sie die folgenden Optionen des Windows-Firewalls über die unbeaufsichtigte Installation konfigurieren:

Warum ist diese Änderung wichtig?

Eine Methode zum Vorkonfigurieren des Windows-Firewalls ermöglicht Windows-Händlern und Großunternehmen mehr Flexibilität und Anpassungsmöglichkeiten für den Windows-Firewall.

Was ist anders?

Diese Funktion bietet mehr Flexibilität bei der Konfiguration des Windows-Firewalls. Hierdurch ergeben sich im Windows-Firewall keine Änderungen bei der Funktionalität.

Welche vorhandenen Funktionen ändern sich in Windows XP Service Pack 2?

Verbesserte Multicast- und Broadcastunterstützung

Ausführliche Beschreibung

Multicast- und Broadcastnetzwerkverkehr unterscheidet sich von Unicastdatenverkehr, weil die Antwort von einem unbekannten Host stammt. In diesem Zusammenhang verhindert die statusbehaftete Filterung, dass die Antwort akzeptiert wird. Eine Reihe von Szenarien sind deshalb nicht möglich, die von Streaming Media bis hin zur Ermittlung reichen.

Um diese Szenarien zu ermöglichen, lässt der Windows-Firewall eine Unicastantwort 3 Sekunden lang von jeder Quelladresse an dem Port zu, von dem der Multicast- oder Broadcastdatenverkehr stammt.

Warum ist diese Änderung wichtig? Zur Minderung welcher Probleme trägt dies bei?

Auf diese Weise können Anwendungen und Dienste Multicast und Broadcast für die Kommunikation verwenden, ohne dass der Benutzer oder die Anwendung bzw. der Dienst die Firewallrichtlinien ändern muss. Dies ist z. B. wichtig für NETBIOS über TCP/IP, damit wichtige Ports wie etwa der Port 135 nicht zugänglich sind.

Was ist anders? Gibt es Abhängigkeiten?

In früheren Windows-Versionen führte der Internetverbindungsfirewall keine Multicast- oder Broadcastfilterung aus. In Windows XP Service Pack 1 führte der Internetverbindungsfirewall eine statusbehaftete Filterung des Multicast- und Broadcastdatenverkehrs durch. Dabei musste der Benutzer zum Empfangen der Antwort den Port manuell öffnen. In Service Pack 2 akzeptiert der Windows-Firewall die Antwort auf den Multicast- oder Broadcastdatenverkehr ohne zusätzliche Konfiguration.

Integration von Internetverbindungsfirewall und IPv6-Windows-Firewall

Ausführliche Beschreibung

Die in Windows XP eingeführte Version des Internetverbindungsfirewalls filterte nur IPv4-Datenverkehr. Der IPv6-Internetverbindungsfirewall war neu im Advanced Networking Pack für Windows XP. Damals waren diese beiden Firewalls getrennt, und für jeden Firewall wurden eigene Konfigurationsoptionen verwendet. In Windows XP Service Pack 2 sind der Internetverbindungsfirewall und der IPv6-Internetverbindungsfirewall zu einer einzigen Komponente mit der Bezeichnung Windows-Firewall zusammengefasst.

Durch diese Änderung betreffen jegliche Konfigurationsänderungen sowohl den IPv4- als auch den IPv6-Datenverkehr. Wenn z. B. ein statischer Port geöffnet wird, wird dieser sowohl für IPv4- als auch für IPv6-Datenverkehr geöffnet.

Warum ist diese Änderung wichtig?

Dies ermöglicht eine einfachere Konfigurationsverwaltung und Anwendungskompatibilität.

Was ist anders?

Der separate IPv6-Firewalldienst ist nicht mehr vorhanden und wurde durch den Windows-Firewalldienst ersetzt, der sowohl IPv4- als auch IPv6-Datenverkehr filtert. Alle APIs, die mit dem Advanced Networking Pack für Windows XP eingeführt wurden, werden durch die mit Windows XP Service Pack 2 eingeführten neuen APIs ersetzt.

Wie kann ich diese Probleme beseitigen?

Weitere Informationen finden Sie unter "Muss ich den Code ändern, um mit Windows XP Service Pack 2 zu arbeiten?" weiter unten in diesem Dokument

Aktualisiertes Netsh-Hilfsprogramm

Ausführliche Beschreibung

Der Firewallkontext des Netsh-Hilfsprogramms war neu im Advanced Networking Pack für Windows XP. Dies betraf nur den IPv6-Windows-Firewall. Durch die Integration von Windows-Firewall und IPv6-Windows-Firewall hat der Firewallkontext des Netsh-Hilfsprogramms keinen IPv6-Kontext mehr.

Warum ist diese Änderung wichtig?

Diese Änderung berücksichtigt die Änderungen am Windows-Firewall und die Integration von IPv4-Filterungskonfigurationsoptionen in den bestehenden Firewallkontext des Netsh-Hilfsprogramms.

Was ist anders?

Alle vorhandenen Skripts, die den Firewallkontext aus dem Advanced Networking Pack verwenden, werden nicht mehr ausgeführt.

Wie kann ich diese Probleme beseitigen?

Aktualisieren Sie alle vorhandenen Skripts, damit sie den neuen Firewallkontext und die neue Syntax aufweisen.

Aktualisierte Benutzeroberfläche

Ausführliche Beschreibung

Die Benutzeroberfläche des Windows-Firewalls wurde in Windows XP Service Pack 2 aktualisiert, damit die neuen Konfigurationsoptionen und die Integration des IPv6-Internetverbindungsfirewalls berücksichtigt werden. Der Benutzer kann den Betriebsstatus, die globale Konfiguration, Protokollierungsoptionen und ICMP-Optionen ändern.

Der primäre Zugriff auf die Benutzeroberfläche wurde vom Eigenschaftendialogfeld der Verbindung in ein Systemsteuerungssymbol verschoben. Ein Link vom alten Speicherort ist weiterhin vorhanden. Darüber hinaus erstellt Windows XP Service Pack 2 einen Link vom Ordner Netzwerkverbindungen.

Warum ist diese Änderung wichtig?

Die zusätzliche Funktionalität in Windows XP Service Pack 2 erforderte Updates an der Benutzeroberfläche.

Was ist anders?

Der Zugriff auf die Benutzeroberfläche wurde von der Registerkarte Erweitert im Dialogfeld Eigenschaften der Netzwerkverbindung in ein spezielles Windows-Firewallsymbol in der Systemsteuerung verschoben.

Unterstützung neuer Gruppenrichtlinien

Ausführliche Beschreibung

In früheren Windows-Versionen wies der Internetverbindungsfirewall ein einziges Gruppenrichtlinienobjekt (Group Policy Object, GPO) auf: Verwendung des Internetverbindungsfirewalls im eigenen DNS-Domänennetzwerk nicht zulassen. In Windows XP Service Pack 2 kann jede Konfigurationsoption über Gruppenrichtlinien festgelegt werden. Beispiele für die neuen Konfigurationsoptionen:

Jedes dieser Objekte kann sowohl für das Firmen- als auch das Standardprofil festgelegt werden. Eine vollständige Aufstellung der Gruppenrichtlinienoptionen finden Sie im Abschnitt zum Bereitstellen von Einstellungen für den Internetverbindungsfirewall für Microsoft Windows XP mit Service Pack 2 im Microsoft Download Center unter http://go.microsoft.com/fwlink/?linkid=23277.

Warum ist diese Änderung wichtig?

Administratoren müssen unbedingt Windows-Firewallrichtlinien verwalten, damit Anwendungen und Szenarien in der Unternehmensumgebung verwendet werden können.

Was ist anders?

Der IT-Administrator kann nun die Windows-Firewall-Standardrichtlinien festlegen. Dadurch können Anwendungen und Szenarien ermöglicht oder unterbunden werden. Dies ermöglicht eine präzisere Kontrolle, aber durch die Richtlinien ändert sich die zugrunde liegende Funktionalität des Windows-Firewalls nicht.

Welche Einstellungen wurden in Windows XP Service Pack 2 hinzugefügt oder geändert?

Muss ich den Code ändern, um mit Windows XP Service Pack 2 zu arbeiten?

Ausgehende Verbindungen

Beschreibung

Für typische Benutzer- und Bürocomputer ist der Computer ein Client im Netzwerk. Software auf dem Computer stellt eine Verbindung mit einem Server her (ausgehende Verbindung) und erhält Antworten vom Server. Der Windows-Firewall erlaubt ausgehende Verbindungen, wendet jedoch Regeln auf die eingehenden Kommunikationsarten an, die auf dem Computer zulässig sind. Weitere Informationen, welchen Netzwerkverkehr der Windows-Firewall bei ausgehenden TCP- und UDP-Verbindungen zulässt, finden Sie weiter unten unter "Hinweise".

Erforderliche Maßnahmen

Keine. Der Windows-Firewall lässt automatisch alle ausgehenden Verbindungen zu, unabhängig vom Programm und vom Benutzerkontext.

Hinweise

Beispiele

Nicht angeforderte eingehende Verbindungen für Anwendungen

Beschreibung

Dieses Szenario bezieht sich auf eine Anwendung, die die Überwachung eines TCP-Sockets abschließt oder über Winsock eine erfolgreiche Bindung zu einem bestimmten UDP-Socket herstellt. Für dieses Szenario kann der Windows-Firewall in Abhängigkeit von den Anforderungen der Anwendung Ports automatisch öffnen und schließen.

Erforderliche Maßnahmen

Wenn eine Anwendung, die einen oder mehrere Ports überwachen muss, von einem Administrator installiert wird, müssen die Benutzer festlegen, ob die Anwendung Ports im Firewall öffnen darf.

Wenn Sie die INetFwAuthorizedApplication-API verwenden, um eine Anwendung der AuthorizedApplications-Sammlung hinzuzufügen, sind die folgenden Werte erforderlich:

Weitere Informationen zur INetFwAuthorizedApplication-API finden Sie unter "INetFwAuthorizedApplication" im Microsoft Platform Software Development Kit (SDK) auf der Website http://go.microsoft.com/fwlink/?LinkId=32000.

Der Windows-Firewall überwacht Winsock, um festzustellen, wann Anwendungen die Überwachung von Ports beginnen und beenden. Deshalb werden Ports für Anwendungen automatisch geöffnet und geschlossen, sobald die entsprechenden Einträge in der Windows-Firewall-Ausnahmenliste aktiviert wurden. Dies bedeutet, dass keine Maßnahmen seitens Winsock-Anwendungen erforderlich sind, um Ports zu öffnen und zu schließen.

Hinweise

Beispiele

Es folgen einige Beispiele für Aufgaben mit Microsoft-Anwendungen, die unterschiedlich gehandhabt werden:

Eingehende Verbindungen für Dienste

Beschreibung

Während Entwickler die AuthorizedApplication-APIs für alle Szenarien verwenden sollten, empfiehlt sich die Verwendung globaler Port-APIs im Windows-Firewall für Dienste, die festgelegte Ports überwachen. Da diese Ports immer geöffnet sind, bietet das dynamische Öffnen der Ports minimale Vorteile. Stattdessen haben die Benutzer die Möglichkeit, die Firewalleinstellungen für diese festgelegten Ports anzupassen, wenn die globalen Port-APIs verwendet werden.

Erforderliche Maßnahmen

Wenn ein Dienst einen festgelegten Port überwachen muss, muss der Benutzer gefragt werden, ob der Dienst Ports im Firewall öffnen darf. Dies sollte im Idealfall beim Installieren des Dienstes erfolgen.

Falls der Benutzer dem zustimmt, sollte der Dienst mit der INetFwOpenPort-API dem Windows-Firewall Regeln hinzufügen, damit die von diesem Dienst benötigten festgelegten Ports geöffnet werden. Diese Regeln sollten aktiviert werden.

Falls der Benutzer dies ablehnt, sollte der Dienst dennoch mit der INetFwOpenPort-API dem Windows-Firewall Regeln hinzufügen, damit die von diesem Dienst benötigten festgelegten Ports geöffnet werden. Diese Regeln sollten jedoch nicht aktiviert werden.

Wenn Sie die INetFwOpenPort-API verwenden, um das Öffnen eines Ports dem Windows-Firewall hinzuzufügen, sind die folgenden Werte erforderlich:

Weitere Informationen zur INetFwAuthorizedApplication-API finden Sie unter "InetFwAuthorizedApplication" im Platform Software Development Kit (SDK) auf der MSDN-Website unter http://go.microsoft.com/fwlink/?linkid=32000.

Wenn ein Dienst deaktiviert ist, sollte er wiederum mithilfe der INetFwOpenPort-API nach Möglichkeit die zuvor geöffneten statischen Ports schließen. Dies ist kein Problem, wenn es sich nur um einen Dienst handelt, der die Ports verwendet. Falls der Dienst jedoch möglicherweise die Ports gemeinsam mit anderen Diensten nutzt, sollte der Dienst die Ports nur schließen, wenn sich feststellen lässt, dass keiner der anderen Dienste die Ports verwendet.

Eine Anwendung muss unter einem Konto mit Administratorrechten ausgeführt werden, um Ports statisch im Windows-Firewall zu öffnen.

Hinweise

Beispiele

Beispiele für Dienste, die eingehende Verbindungen benötigen:

Eingehende Verbindungen an RPC- und DCOM-Ports für Systemdienste

Beschreibung

Manche Systemdienste erfordern für eingehende Verbindungen die Verwendung von RPC-Ports, entweder über DCOM oder direkt über RPC. Wegen der erheblichen Sicherheitsrisiken beim Öffnen von RPC-Ports werden diese Ports als Sonderfall behandelt. Entwickler sollten RPC für Systemdienste nur über den Windows-Firewall aktivieren, wenn dies unbedingt erforderlich ist.

Erforderliche Maßnahmen

Der Windows-Firewall kann so konfiguriert werden, dass RPC- und DCOM-Ports für Systemdienste automatisch geöffnet und geschlossen werden. Standardmäßig wird jedoch RPC vom Windows-Firewall blockiert. Dies bedeutet, dass Anwendungen, die die RPC-Ports zum Übertragen von Daten an Systemdienste verwenden, den Windows-Firewall entsprechend konfigurieren müssen. Wenn eine Anwendung diese Funktion aktivieren muss, muss der Benutzer gefragt werden, ob die Dienste Ports im Firewall öffnen dürfen. Dies sollte im Idealfall beim Installieren erfolgen.

Falls der Benutzer dem zustimmt, sollte der Dienst mit der INetFwRemoteAdminSettings-API die von diesem Dienst benötigten Ports öffnen.

Falls der Benutzer dies ablehnt, sollte die Anwendung oder der Dienst für den Windows-Firewall nicht konfigurieren, dass RPC-Ports geöffnet werden dürfen.

Weitere Informationen zur INetFwRemoteAdminSettings-API finden Sie unter "INetFwAuthorizedApplication" auf der MSDN-Website unter http://go.microsoft.com/fwlink/?linkid=32000. Klicken Sie im Inhaltsverzeichnis auf "RemoteAddresses Property of InetFwAuthorizedApplication".

Hinweise

Zum Seitenanfang

Windows Media Player

Welche Funktion hat Windows Media Player?

Windows Media Player ist eine Anwendung, die Medieninhalte bereitstellt, Mediendateien wiedergibt und die gespeicherten Mediendateien anordnet.

Für wen ist diese Funktion gedacht?

Alle Benutzer, die Windows Media Player verwenden, sollten die Änderungen in Windows XP Service Pack 2 kennen.

Welche neue Funktionalität wurde in Windows XP Service Pack 2 für diese Funktion hinzugefügt?

Windows Media Player 9-Reihe

Ausführliche Beschreibung

Die Windows Media Player 9-Reihe wird zusammen mit Windows XP Service Pack 2 installiert. Diese Version von Windows Media Player enthält Sicherheitspatches und neue Funktionalität.

Wenn Sie während der Installation von Windows XP Service Pack 2 die Option zum Archivieren von Dateien auswählen, können Sie die Windows Media Player 9-Reihe später entfernen. Zu diesem Zweck entfernen Sie das Service Pack mithilfe der Option Software in der Systemsteuerung. Die Windows Media Player 9-Reihe wird zusammen mit dem Service Pack entfernt, und sowohl die vorherige Version von Windows Media Player als auch die vorherige Betriebssystemversion werden wiederhergestellt.

Wenn Sie eine Neuinstallation von Windows XP einschließlich Service Pack 2 auf einem Computer unter einer früheren Windows-Version ausführen, wird das Betriebssystem ersetzt, und die Windows Media Player 9-Reihe kann nicht entfernt werden. Weitere Informationen finden Sie im Windows Media 9-Reihe Knowledge Center unter http://go.microsoft.com/fwlink/?LinkId=32062.

Warum ist diese Änderung wichtig? Zur Minderung welcher Probleme trägt dies bei?

Frühere Versionen von Windows Media Player wiesen Sicherheitsrisiken auf. Diese wurden zwar mit Softwareupdates behoben, aber das Update früherer Versionen auf die Windows Media Player 9-Reihe ist eine gründlichere Lösung. Die Windows Media Player 9-Reihe wurde außerdem gründlich getestet und aktualisiert, um die Kompatibilität mit den anderen Verbesserungen im Bereich Sicherheit in Windows XP Service Pack 2 sicherzustellen.

Was ist anders?

Wenn Sie Windows XP Service Pack 2 deinstallieren, müssen Sie sich möglicherweise einige Lizenzen zur Wiedergabe zuvor lizenzierter Inhalte erneut beschaffen. Dies ist der Fall, wenn Sie Ihren Computer von Windows 2000 oder Windows XP auf Windows XP Service Pack 2 aktualisiert haben, weil die Windows Media Player 9-Reihe Lizenzen für digitale Inhalte anders verwaltet als frühere Versionen.

Wie kann ich diese Probleme beseitigen?

Gehen Sie folgendermaßen vor, um sicherzustellen, dass Ihre vorhandenen lizenzierten Inhalte nach der Deinstallation von Windows XP Service Pack 2 weiterhin für Windows Media Player verfügbar sind:

Zum Seitenanfang

Windows Messenger.

Welche Funktion hat Windows Messenger?

Windows Messenger ist ein Instant Messaging-Programm, mit dem Sie in Echtzeit mit anderen Personen kommunizieren können, die Windows Messenger oder MSN Messenger verwenden.

Windows Messenger ermöglicht Folgendes:

Für wen ist diese Funktion gedacht?

Alle Benutzer von Windows Messenger sollten die Änderungen an dieser Funktion in Windows XP Service Pack 2 kennen.

Welche neue Funktionalität wurde in Windows XP Service Pack 2 für diese Funktion hinzugefügt?

Die folgenden Funktionen wurden Windows Messenger in Windows XP Service Pack 2 hinzugefügt:

Sperren unsicherer Dateiübertragungen

Ausführliche Beschreibung

Die Übertragung von Dateien wird gesperrt, wenn mit deren Inhalt auf Ihrem Computer Schaden angerichtet werden könnte. Wenn jemand versucht, Ihnen eine Datei zu senden, wird von Windows Messenger zunächst überprüft, ob der Absender auf Ihrer Kontaktliste aufgeführt ist. Anschließend wird die Datei einer Sicherheitsprüfung unterzogen.

Dateien werden gesperrt, wenn die folgenden beiden Punkte zutreffen:

Dateien mit den Erweiterungen JPG, TXT und GIF werden i. A. als sicher betrachtet und können von Benutzern empfangen werden, die nicht in Ihrer Kontaktliste vorhanden sind.

Bestimmte Dateitypen sollten mit Vorsicht geöffnet werden, selbst wenn Sie den Sender kennen, weil sie möglicherweise ausführbaren Code enthalten. Wenn Sie einen bestimmten Dateityp von jemandem in Ihrer Kontaktliste erhalten, werden Sie gefragt, wie Sie mit der Datei verfahren möchten. Sie sollten die Datei nur dann annehmen, wenn Sie sie auf der Festplatte des Computers speichern und vor dem Öffnen mit einem Antivirusprogramm überprüfen können.

Sie werden vor dem Öffnen der folgenden Dateitypen gefragt:

Eine Aufstellung der Dateien, die i. A. als unsicher betrachtet werden, finden Sie im Abschnitt mit den Informationen zur Liste der unsicheren Dateien in Internet Explorer 6 auf der Microsoft-Website unter http://go.microsoft.com/fwlink/?LinkId=25999.

Warum ist diese Änderung wichtig? Zur Minderung welcher Probleme trägt dies bei?

Die Übertragung von Dateien wird gesperrt, wenn mit deren Inhalt auf Ihrem Computer Schaden angerichtet werden könnte.

Was ist anders?

Manche Dateiübertragungen werden gesperrt.

Wie kann ich diese Probleme beseitigen?

Dateien werden nur gesperrt, wenn die folgenden beiden Punkte zutreffen:

Wenn Sie wissen, dass die Datei sicher ist, können Sie den Benutzer Ihrer Kontaktliste hinzufügen. Danach können Sie alle Dateiübertragungen von diesem Benutzer problemlos empfangen.

Benutzeranzeigename erforderlich

Ausführliche Beschreibung

In Windows Messenger ist nun ein Benutzeranzeigename erforderlich, der von der E-Mail-Adresse des Benutzers abweicht.

Dies ist erforderlich, wenn sich der Benutzer bei Windows Messenger anmeldet und wenn er seinen Anzeigenamen im Dialogfeld Optionen aktualisiert.

Wenn sich Benutzer bei Windows Messenger anmelden, werden sie aufgefordert, vorher einen Benutzeranmeldenamen einzugeben. Andernfalls ist die Anmeldung nicht möglich.

Wenn Benutzer ihren Anzeigenamen im Dialogfeld Optionen aktualisieren, überprüft Windows Messenger, ob die Anzeigenamen mit der E-Mail-Adresse übereinstimmen.

Warum ist diese Änderung wichtig? Zur Minderung welcher Probleme trägt dies bei?

Wenn Instant Messaging-Konversationen mit dem Befehl Speichern unter im Menü Datei für später gespeichert werden, wird der Anzeigename des Benutzers zusammen mit zugehörigen Textnachrichten in einer Textdatei gespeichert. Antivirusanwendungen können die E-Mail-Adresse in der Textdatei ermitteln und an die Kontakte des Benutzers über diese Instant Messaging-Konversationen weitergeben.

Was ist anders?

Benutzer können sich erst anmelden, wenn sie einen Benutzeranzeigenamen eingegeben haben.

Wie kann ich diese Probleme beseitigen?

Der Benutzer muss einen Benutzeranzeigenamen eingeben, wenn er bei der Anmeldung dazu aufgefordert wird.

Windows Messenger und Windows-Firewall

Ausführliche Beschreibung

Windows Messenger benötigt die Berechtigung zum Herstellen einer Internetverbindung über den Windows-Firewall.

Um Windows Messenger diese Berechtigung zu erteilen, klicken Sie im Startmenü auf Systemsteuerung, klicken Sie auf Sicherheitsoptionen, und klicken Sie dann auf Windows-Firewall. Klicken Sie auf Ausnahmen, und klicken Sie dann in Programme und Dienste auf Windows Messenger.

Warum ist diese Änderung wichtig? Zur Minderung welcher Probleme trägt dies bei?

Der Windows-Firewall ist standardmäßig aktiviert, um den Computer des Benutzers zu schützen.

Was ist anders?

Windows Messenger wird nicht ausgeführt.

Wie kann ich diese Probleme beseitigen?

Fügen Sie Windows Messenger zur Windows-Firewall-Ausnahmenliste hinzu.

Zum Seitenanfang

Wireless Provisioning Services

Welche Funktion hat Wireless Provisioning Services?

Immer mehr Benutzer greifen über eine wachsende Zahl von öffentlichen drahtlosen Netzwerken oder Wi-Fi®-Hotspots auf das Internet zu. Durch die Verwendung von Wireless Provisioning Services (WPS) in Windows XP Service Pack 2 mit Windows Server 2003 Service Pack 1 haben Benutzer mit einer drahtlosen Verbindung durch die automatische Bereitstellung des Clients und integriertes Roaming stets Zugriff auf öffentliche Wi-Fi-Hotspots. Mit WPS können Wireless Internet Service Providers (WISPs) mithilfe einer auf Standards basierenden und integrierten Plattform Wi-Fi-Hotspots mit verbesserter Sicherheit anbieten, die einfach zu verwenden und zu verwalten sind. Darüber hinaus können Unternehmen mithilfe von WPS auf einfache Weise den Gastzugriff mit verbesserter Sicherheit für private drahtlose Netzwerke anbieten.

Mit WPS können WISPs und Unternehmen Bereitstellungs- und Konfigurationsinformationen an mobile Clients senden, wenn sie eine Verbindung zum Internet oder zum Firmennetzwerk herstellen. Dies wiederum erlaubt die integrierte, automatische und sichere Konfiguration von mobilen Clients und ermöglicht eine einheitliche Anmeldung im Unternehmen und bei verschiedenen öffentlichen Netzwerkanbietern und Hotspotstandorten.

Hinweis  Für diese Funktion ist Service Pack 1 für Windows Server 2003 erforderlich, um die in diesem Abschnitt beschriebenen Szenarien zu ermöglichen. Windows Server 2003 Service Pack 1 ist noch nicht erhältlich.

Für wen ist diese Funktion gedacht?

Wireless Provisioning Service wurde für drei Arten von Organisationen entwickelt:

Welche neue Funktionalität wurde in Windows XP Service Pack 2 für diese Funktion hinzugefügt?

Wireless Provisioning Services

Ausführliche Beschreibung

Wireless Provisioning Services ist eine Erweiterung der bestehenden Drahtlosnetzwerkdienste und Benutzeroberflächen in Windows XP und Windows Server 2003. Die Anwendung basiert auf den bereits in Windows vorhandenen Drahtlosfunktionen, wie z. B. Wireless AutoConfiguration, und den Drahtlossicherheitsfunktionen, wie z. B. Protected Extensible Authentication (PEAP) und Wi-Fi Protected Access (WPA). WPS weist außerdem Änderungen an Windows Server 2003 auf. Der Internetauthentifizierungsdienst (Internet Authentication Service, IAS) von Windows 2003 wurde geändert und beinhaltet nun die Gastauthentifizierung der Clients bei der Bereitstellung.

WPS enthält eine Bereitstellungsdienstkomponente, mit der WISPs und Unternehmen Bereitstellungs- und Konfigurationsinformationen an einen mobilen Client senden können, der eine Verbindung mit dem Internet oder dem Firmennetzwerk herzustellen versucht. Mit Wireless Provisioning Services können WISPs Dienste an mehreren Netzwerkstandorten bereitstellen und mehrere Netzwerknamen (SSIDs oder Service Set Identifiers) verwenden. Nachdem sich die Benutzer bei einem WISP an einem Ort angemeldet haben oder vorab die Bereitstellungsinformationen gedownloadet haben, können sie später automatisch eine Verbindung mit dem Internet herstellen, indem sie das vom WISP angebotene Netzwerk an verschiedenen Hotspotstandorten verwenden. Der automatische Drahtloskonfigurationsdienst wählt anhand der gelieferten Bereitstellungsdateien automatisch das richtige Netzwerk für den WISP aus. WSP ermöglicht außerdem das automatische und integrierte Roaming zwischen verschiedenen Anbietern.

Wenn WPS verwendet wird, speichert darüber hinaus der Clientcomputer automatisch die bisherigen Bereitstellungsinformationen auf dem Clientcomputer. Auf diese Weise kann der Anbieter die Netzwerkeinstellungen ändern, neue Standorte hinzufügen usw., ohne dass der Service unterbrochen wird oder die Benutzer ihre Systeme neu konfigurieren müssen.

Wenn ein Benutzer seinen Computer zum ersten Mal mit einem WISP verbindet und ein Konto einrichtet, werden die folgenden vier Phasen durchlaufen:

Diese Phasen werden im folgenden Szenario ausführlich behandelt:

Ein Benutzer befindet sich in der Nähe eines Wi-Fi-Hotspots und verwendet einen tragbaren Computer, auf dem Windows XP SP2 und Wireless Provisioning Services installiert sind. Wenn der Computer in Reichweite des WISP-Zugriffspunktsignals kommt, passiert Folgendes:

Wenn das Gastkonto vom Wi-Fi-Netzwerk authentifiziert wird, passiert Folgendes:

Wenn der Client bereitgestellt wird und der Benutzer ein Konto einrichtet, passiert Folgendes:

Wenn der Benutzer mit den neuen Kontoanmeldeinformationen authentifiziert und die Internetverbindung hergestellt wurde, passiert Folgendes:

Zur Minderung welcher Probleme trägt dies bei? Warum ist diese Änderung wichtig?

Wireless Provisioning Services vereinfacht die Verwendung von drahtlosen Hotspots, ohne dass dadurch die Sicherheit beeinträchtigt wird. Mit WPS, mit Windows Server 2003 Service Pack 1, und Microsoft IAS (wird auch als RADIUS-Server bezeichnet) vereinfacht sich für Benutzercomputer die Ermittlung, die Verbindung und das Roaming zwischen drahtlosen Hotspots, wobei die Sicherheit verbessert wird.

Drahtlosnetzwerkregistrierungs-Assistent

Ausführliche Beschreibung

Der Drahtlosnetzwerkregistrierungs-Assistent bietet die Benutzeroberfläche zum Anmelden für einen drahtlosen Hotspot und führt den Benutzer schrittweise durch den Bereitstellungsvorgang. Dieser Assistent erstellt Inhalte von Bereitstellungsinformationen (XML-Dateien), die vom WISP geliefert werden. Die Bereitstellungsinformationen können dynamisch gedownloadet oder auf dem Clientsystem vorinstalliert werden. Die Vorinstallation ist möglich durch einen OEM für neue Systeme, durch die IT-Abteilung innerhalb eines Unternehmens oder über eine WISP-Website. Der WISP besitzt und erstellt die Bereitstellungsinformationen und steuert die Anmeldung und Bereitstellung für den Benutzer. Das folgende Beispiel stellt ein einfaches Szenario mit dem Drahtlosnetzwerkregistrierungs-Assistenten und vorab bezahltem Code dar. Das XML-Schema und der Assistent sind flexibel und ermöglichen komplexere Anmeldeszenarien.

Zum einen kann der Benutzer entweder mit der rechten Maustaste auf das Drahtlosnetzwerksymbol im Infobereich klicken und dann auf Verfügbare drahtlose Netzwerke anzeigen klicken. Oder der Benutzer beantwortet die Benachrichtigungsmeldung im Infobereich, die auf die Verfügbarkeit eines neuen Drahtlosnetzwerks innerhalb der Reichweite hinweist. Wenn Drahtlosnetzwerk auswählen angezeigt wird, wählt der Benutzer ein neues Drahtlosnetzwerk aus und fügt es der Liste bevorzugter Netzwerke hinzu.

Anschließend wählt der Benutzer einen Netzwerknamen aus (eine SSID) und klickt auf Verbinden, um eine Verbindung mit dem Drahtlosnetzwerk herzustellen. Mit einem WPS-basierten Wi-Fi-Hotspot erkennt der Client, dass weitere Bereitstellungsinformationen in Form von XML-Dateien über das Netzwerk und den Anbieter vorhanden sind. Anschließend muss der Benutzer bestätigen, ob die Bereitstellungsinformationen gedownloadet werden sollen. Mit einem anderen als einem WPS-Netzwerk wäre die Vorgehensweise identisch wie heute bei Windows XP: entweder wird der Benutzer bei der Verbindung mit einem sicheren Netzwerk zur Eingabe eines Sicherheitsschlüssels aufgefordert, oder der Benutzer wird gewarnt, dass das Netzwerk, mit dem eine Verbindung hergestellt werden soll, nicht sicher ist. Er muss dann bestätigen, dass die Verbindung dennoch hergestellt werden soll.

Nach Abschluss des Downloads wird automatisch der Drahtlosnetzwerkregistrierungs-Assistent gestartet, der den Benutzer schrittweise durch den Anmeldevorgang führt. Der erste Bildschirm enthält ein angepasstes Logo (oder Banner) und Inhalte des Anbieters.

In den nachfolgenden Bildschirmen muss der Benutzer möglicherweise einen Abonnementplan auswählen, Kreditkarteninformationen und persönliche Informationen eingeben usw. In diesem Beispiel gibt es nur einen Abonnementplan, und der Benutzer wird aufgefordert, für den Zugriff auf das Netzwerk seinen Pre-paid- oder Angebotscode einzugeben. Im nächsten Schritt zeigt der Assistent für drahtlose Netzwerkverbindung Informationen zum ausgewählten Abonnementplan an, wie z. B. Bestimmungen des Servicevertrags und der Datenschutzrichtlinie.

Im letzten Bildschirm wird der Benutzer vom Assistenten zur Eingabe von Voreinstellungen für diese Verbindung aufgefordert. Diese Standardvoreinstellungen können vom Anbieter festgelegt sein, aber vom Benutzer überschrieben werden. Wenn z. B. der Benutzer ein monatliches Abonnement mit unbeschränkter Datenmenge auswählt, möchte er wahrscheinlich immer automatisch eine Verbindung mit dem Netzwerk herstellen, wenn er sich in dessen Reichweite befindet. Wenn der Benutzer ein Abonnement mit Bezahlung pro Nutzung auswählt, möchte er wahrscheinlich bestimmen, wann eine Verbindung hergestellt werden soll und die manuelle Verbindung als Voreinstellung auswählen.

Die zweite Option bestimmt, ob der Client die Bereitstellungsinformationen automatisch aktualisiert. Wenn z. B. der Anbieter neue Netzwerknamen bzw. neue Standorte hinzufügt oder die Netzwerk- oder Sicherheitseinstellungen ändert, kann der Client automatisch die Informationen aktualisieren, ohne dass der Benutzer bei der Verbindung mit dem Netzwerk bestimmte Schritte ausführen muss.

Bei nachfolgenden Besuchen von Hotspots an denselben oder anderen Standorten des Anbieters oder dessen Roamingpartnern müssen die Benutzer, falls die automatische Verbindungsherstellung ausgewählt ist, lediglich ihren mobilen Computer wieder einschalten oder aus dem Standbymodus wieder in den Betriebsmodus wechseln, damit automatisch eine Verbindung hergestellt wird. Während der Verbindung werden statt eines verschlüsselten Netzwerknamens oder einer SSID im Dialogfeld Drahtlosnetzwerk auswählen (das im Benachrichtigungsfenster Verfügbare Drahtlosnetzwerke geöffnet wird) der Anzeigename und das Logo des Anbieters angezeigt.

In diesem Dialogfeld können die Benutzer auch nach verfügbaren Hotspotstandorten suchen oder die Hilfe und Supportinformationen des WISP anzeigen. Sowohl die Hilfe als auch die Hotspotstandortinformationen werden im Rahmen der Bereitstellungsinformationen gedownloadet. Die Standortinformationen können online oder offline durchsucht und angezeigt werden.

Welche vorhandenen Funktionen ändern sich in Windows XP Service Pack 2?

Die Drahtlosbenutzeroberfläche hat sich geändert. Es gibt nun ein neues Dialogfeld Verfügbare drahtlose Netzwerke anzeigen.

Muss ich den Code ändern, um mit Windows XP Service Pack 2 zu arbeiten?

Wireless Provisioning Service erfordert keine Änderungen an vorhandenen Anwendungen. Es gibt zwei neue APIs in WPS. Eine der neuen APIs ermöglicht das Hinzufügen und führt Abfragen über die XML-Daten auf dem Computer aus. Mit dieser API kann der Client über die WISP-Website vom Benutzer (mithilfe einer eigenständigen Anwendung), von OEMs oder IT-Abteilungen vorab bereitgestellt werden.

Zum Seitenanfang

Drahtlosnetzwerkinstallations-Assistent

Welche Funktion hat der Drahtlosnetzwerkinstallations-Assistent?

Mit dem Drahtlosnetzwerkinstallations-Assistenten können Benutzer für ein Drahtlosnetzwerk eine verbesserte Sicherheit konfigurieren. Der Assistent vereinfacht außerdem das Konfigurieren von drahtlosen Netzwerkverbindungen auf Computern und sonstigen Geräten. Der Assistent speichert die Drahtlosnetzwerkeinstellungen einschließlich der Konfiguration und des Sicherheitsschlüssels auf Wechselmedien wie z. B. einem USB-Flashlaufwerk, das auf anderen Geräten und Computern Ihres Drahtlosnetzwerks verwendet werden kann. Dieser Assistent stellt außerdem eine einfache Möglichkeit zum Drucken der Konfigurationsinformationen dar, damit sie manuell auf Geräten eingegeben werden können, die Informationen von Wechselmedien nicht lesen können.

Für wen ist diese Funktion gedacht?

Benutzer, die Computer mit folgenden Hardwarekomponenten verwenden:

Welche neue Funktionalität wurde in Windows XP Service Pack 2 für diese Funktion hinzugefügt?

Drahtlosnetzwerkinstallations-Assistent

Ausführliche Beschreibung

Durch die zunehmende Beliebtheit von Drahtlosnetzwerken richten immer mehr Benutzer zu Hause Drahtlosnetzwerke, Netzwerkcomputer und sonstige Geräte ein, die Drahtlosnetzwerke unterstützen. Vor Windows XP Service Pack 2 war das Erstellen eines sicheren Drahtlosnetzwerks und das Weitergeben der Drahtlosnetzwerkeinstellungen an Drahtlosclients und zusätzliche Zugriffspunkte sehr schwierig. Der Drahtlosnetzwerkinstallations-Assistent wurde als Antwort auf den wachsenden Bedarf an einer einfachen und zugleich sicheren Methode zum Konfigurieren und Neustarten von Drahtlosnetzwerkhardware (auch als Drahtloszugriffspunkte (Wireless Access Points, WAPs) bezeichnet) und Drahtlosclients (einschließlich Computern und sonstigen Geräten) entwickelt.  

Mit dem Drahtlosnetzwerkinstallations-Assistent kann der Windows-Benutzer auf einfache Weise Netzwerkeinstellungen mit einem XML-Schema (Extensible Markup Language) und Wechselmedien erstellen und weitergeben. In Zukunft können mit diesem XML-Schema auch Einstellungen für WANs, LANs sowie WLANs übertragen werden. Mit den vom Drahtlosnetzwerkinstallations-Assistenten für Windows XP SP2 erstellten XML-Dateien werden jedoch nur Konfigurationseinstellungen für WLANs übertragen.

Warum ist diese Änderung wichtig?

Viele Heimdrahtlosnetzwerke werden ohne Sicherheitsoptionen bereitgestellt, weil es kompliziert ist, allen vernetzten Komponenten Sicherheitsbezeichner hinzuzufügen. Mit diesem Assistenten kann der Benutzer auf einfache Weise ein Drahtlosnetzwerk mit erweiterter Sicherheit erstellen. Da immer mehr Computer und Geräte mit Drahtloshardwareunterstützung produziert werden, hat der Bedarf an einer einfachen Methode zum Konfigurieren und Implementieren dieser Funktion zugenommen. In vielen Fällen weisen die Geräte keine Methode zum Eingeben von Drahtlosnetzwerkeinstellungen mit erweiterter Sicherheit auf. Dieser Assistent vereinfacht die Konfiguration solcher Geräte, sodass ein Drahtlosnetzwerk mit erweiterter Sicherheit nun problemlos bereitgestellt werden kann. Die folgende Liste enthält Beispiele der Geräte, die mit dem Drahtlosnetzwerkinstallations-Assistenten konfiguriert werden können:

Zur Minderung welcher Probleme trägt dies bei?

Drahtlosnetzwerke, die ohne Sicherheitsoptionen bereitgestellt werden. Drahtlosnetzwerke ohne Sicherheit bieten böswilligen Benutzern Zugriff auf digitale Informationen und sonstige Komponenten des Netzwerks.

Was ist anders?

Dieser neue Assistent bietet eine neue Methode zum Konfigurieren eines Drahtlosnetzwerks. Der Assistent ist zum Konfigurieren von Computern und Geräten hilfreich, selbst wenn sie diese Architektur nicht direkt unterstützen. (Sie können ein Drahtlosnetzwerk einrichten und die Einstellungen drucken, um sie manuell für Drahtlosgeräte und Computer einzugeben.)

Zum Seitenanfang

2 von 8