The Cable Guy – Dezember 2004
Die neuen Netzwerkfeatures von Microsoft Windows Server 2003 Service Pack 1
Von The Cable Guy
Alle auf Deutsch verfügbaren Cable Guy-Kolumnen finden Sie hier.
Auf dieser Seite
 | Einführung |
| Unterschiedliche Verhaltensweisen der Windows Firewall |
| Serverseitige Unterstützung von WPS |
| Rqs.exe und Rqc.exe für die Netzwerkquarantäne |
| TCP/IP-Erweiterungen |
| Zusätzliche Informationen |
Einführung
Das Microsoft® Windows Server™ 2003 Service Pack 1 (SP1), das sich derzeit im Betatest befindet, enthält viele der neuen Netzwerkfeatures aus Windows® XP Service Pack 2 (SP2). Außerdem stellt es zusätzliche Features und Erweiterungen im Bezug auf Serverdienste und den Serverbetrieb zur Verfügung.
Windows Server 2003 SP1 umfasst alle Netzwerkverbesserungen von Windows XP SP2:
| • | Windows Firewall |
| • | Windows Peer-to-Peer Networking |
| • | Clientseitige Unterstützung von WPS (Wireless Provisioning Services) |
| • | IPv6-Aktualisierung (Internet Protocol version 6) |
| • | Die neue Netstat-Option -b |
| • | Erweiterungen im Bezug auf WLAN-Netzwerke |
Diese Verbesserungen werden in den Cable Guy-Artikeln vom Januar 2004 ( Die neuen Netzwerkfeatures von Service Pack 2 für Microsoft Windows XP ) und vom August 2004 ( WLAN-Verbesserungen in Windows XP Service Pack 2 ) detailliert beschrieben.
Zusätzlich bringt Windows Server 2003 SP1 die folgenden Features mit sich:
| • | Unterschiedliche Verhaltensweisen der Windows Firewall |
| • | Serverseitige Unterstützung von WPS |
| • | Rqs.exe und Rqc.exe für die Netzwerkquarantäne |
| • | TCP/IP-Erweiterungen (Transmission Control Protocol/Internet Protocol) |
Unterschiedliche Verhaltensweisen der Windows Firewall
Die Windows Firewall von Windows Server 2003 SP1 arbeitet auf die gleiche Weise wie die Windows Firewall von Windows XP SP2. Da es der Zweck eines Servercomputers ist, auch unverlangt eingehenden Netzwerkverkehr zu verarbeiten, ist die Windows Firewall jedoch unter Windows Server 2003 SP1 standardmäßig deaktiviert.
Ein Ausnahme stellt hierbei die folgenden Situation dar: Bei einer Neuinstallation von Windows Server 2003 mit SP1 (Slipstream-Installation) ist die Windows Firewall standardmäßig für die Dauer der Post-Setup-Sicherheitsupdates aktiviert. Bei diesem Vorgang handelt es sich um einen Teil des Setups des Servercomputers, in dem die aktuellsten Sicherheitsupdates über Windows Update und Automatisches Update heruntergeladen, installiert und konfiguriert werden. Danach wird die Windows Firewall deaktiviert. Wenn Sie keine Post-Setup-Sicherheitsupdates durchführen möchten, können Sie die Windows Firewall-Einstellungen über eine Unattend.txt-Antwortdatei oder eine Gruppenrichtlinie ändern. Wenn Windows Firewall-Einstellungen konfiguriert sind, werden keine Post-Setup-Sicherheitsupdates durchführt.
Sie können die Windows Firewall auf einem Computer unter Windows Server 2003 mit SP1 über die Windows Firewall-Komponente in der Systemsteuerung oder über Gruppenrichtlinieneinstellung (wie im Artikel Windows XP Service Pack 2 - Einstellungen für die Internetverbindungsfirewall bereitstellen beschrieben) manuell aktivieren. Alternativ können Sie den neuen Sicherheitskonfigurationsassistenten von Windows Server 2003 SP1 nutzen. Es wird empfohlen, die Aktivierung der Windows Firewall und andere Sicherheitseinstellungen unter Windows Server 2003 mit SP1 über den Sicherheitskonfigurationsassistenten durchzuführen.
Wenn Sie die Windows Firewall nach der Installation und dem Start des Servers interaktiv aktivieren, sollten Sie den Server neu starten. So stellen Sie sicher, dass die Windows Firewall für die aktiven programmbasierten Ausnahmen Einträge zur Ausnahmentabelle des Servers hinzufügen kann. Wenn diese vor der Aktivierung der Windows Firewall geöffnet wurden, kann die Windows Firewall sie nicht erkennen. Unter Windows Server 2003 SP1 wurden mehrere Benachrichtigungen hinzugefügt, die den Benutzer daran erinnern, den Computer nach einer interaktiven Aktivierung der Windows Firewall neu zu starten.
Serverseitige Unterstützung von WPS
WPS erweitert die WLAN-Clientsoftware und den IAS-Dienst (Internet Authentication Service) von Windows Server 2003 SP1, um in den folgenden Situationen einen konsistenten und automatisierten Konfigurationsprozess zu ermöglichen:
| • | bei öffentlichen WLAN-Hotspots für den Internetzugriff |
| • | bei WLAN-Netzwerken privater Organisationen, die einen Gastzugriff auf das Internet ermöglichen |
Wenn sich ein WLAN-Client zum Beispiel mit einem öffentlichen WLAN-Hotspot verbindet und nicht bereits Kunde des WISP (Wireless Internet Service Provider) ist, dann muss Folgendes ausgeführt werden:
| • | Konfiguration der Netzwerkeinstellungen für eine Verbindung mit dem WISP-Netzwerk |
| • | Übermittlung von Informationen zur Identifizierung und Zahlung an den WISP |
| • | Erhalten der Verbindungs-Anmeldeinformationen |
| • | Neue Verbindung mit dem WISP-Netzwerk, nachdem die Anmeldeinformationen erhalten wurden |
WPS wurde für eine Vereinfachung, Automatisierung und Standardisierung der Erstanmeldung und der Erneuerung von Abonnements entwickelt. Mit WPS kann sich der Benutzer mit jedem Provider über die gleichen Schritte verbinden.
Die clientseitige WPS-Unterstützung wird mit Windows XP SP2 und Windows Server 2003 SP1 zur Verfügung gestellt - sie umfasst die für die automatische Registrierung, Konfiguration und Verbindung zu WLANs mit WPS-Unterstützung erforderlichen Dienste und Komponenten.
Mit Windows Server 2003 SP1 steht nun auch eine serverseitige WPS-Unterstützung zur Verfügung. Außerdem wurde IAS um entsprechende Prozesse erweitert. IAS sendet unter Windows Server 2003 SP1 zum Beispiel während des ersten Verbindungsprozesses Informationen über den entsprechenden Provisioning-Server an den Client.
Weitere Informationen zur Arbeitsweise von WPS im Zusammenhang mit WISP finden Sie im Cable Guy-Artikel vom Dezember 2003 ( Dezember 2003: Wireless Provisioning Services - Übersicht . Mehr Informationen zu WPS finden Sie im Whitepaper Introduction to Deploying Wireless Provisioning Services (WPS) Technology (englischsprachig).
Rqs.exe und Rqc.exe für die Netzwerkquarantäne
Die Netzwerkquarantäne verzögert den normalen Netzwerkzugriff auf ein privates Netzwerk so lange, bis die Konfiguration des Remotecomputers über ein vom Administrator vorgegebenes Script überprüft und bewertet wurde. Wenn ein Remotecomputer eine Verbindung mit einem RAS-Server aufbaut, wird der Benutzer authentifiziert, und der Computer erhält eine IP-Adresse. Die Verbindung wird allerdings im Quarantänemodus platziert (in diesem Modus ist der Zugriff auf das Netzwerk eingeschränkt); dann wird das vom Administrator vorgegebene Script auf dem Remotecomputer ausgeführt. Wenn das Script den RAS-Server darüber benachrichtigt, dass es erfolgreich ausgeführt wurde und der Remotecomputer den Richtlinien des Netzwerks entspricht, wird der Quarantänemodus aufgehoben. Der Remotecomputer erhält einen normalen Netzwerkzugriff.
Für die Quarantänekontrolle ist also eine Benachrichtigungskomponente erforderlich, die nach erfolgreicher Prüfung vom Script ausgeführt wird. Außerdem wird eine Listener-Komponente benötigt, die auf dem RAS-Server ausgeführt wird. Die Listener-Komponente wartet darauf, dass sie eine Benachrichtigung von der Benachrichtigungskomponente auf dem Remotecomputer erhält.
Für Windows Server 2003 ohne Service Pack stellt Microsoft die Benachrichtigungskomponente separat zur Verfügung (Rqc.exe aus den Windows Server 2003 Resource Kit Tools - englischsprachig). Mit Windows Server 2003 SP1 wird Rqc.exe nun direkt zusammen mit der Installation des Verbindungsmanager-Verwaltungskits installiert. Sie finden das Tool im Ordner "Programme\CMAK\Support" auf dem Systemlaufwerk.
Um das Verbindungsmanager-Verwaltungskit unter Windows Server 2003 mit SP1 zu installieren, gehen Sie folgendermaßen vor:
1. | Klicken Sie auf Start , zeigen Sie auf Einstellungen , klicken Sie auf Systemsteuerung , klicken Sie doppelt auf Software , und klicken Sie auf Windows-Komponenten hinzufügen/entfernen . |
2. | Klicken Sie unter Komponenten auf Verwaltungs- und Überwachungstools . |
3. | Klicken Sie auf Details |
4. | Klicken Sie unter Unterkomponenten von Verwaltungs- und Überwachungstools auf Verbindungsmanager-Verwaltungskit und dann auf OK . |
Für Windows Server 2003 ohne Service Pack stellt Microsoft die Listener-Komponente Rqs.exe über die Windows Server 2003 Resource Kit Tools zur Verfügung. Windows Server 2003 SP1 enthält Rqs.exe bereits - es wird zusammen mit der Quarantänekomponente installiert.
Um den Quarantänedienst auf einem RAS-Server unter Windows Server 2003 mit SP1 zu installieren, gehen Sie folgendermaßen vor:
1. | Klicken Sie auf Start , zeigen Sie auf Einstellungen , klicken Sie auf Systemsteuerung , klicken Sie doppelt auf Software , und klicken Sie auf Windows-Komponenten hinzufügen/entfernen . |
2. | Klicken Sie unter Komponenten auf Netzwerkdienste . |
3. | Klicken Sie auf Details . |
4. | Klicken Sie unter Unterkomponenten von Netzwerkdienste auf RAS-Quarantänedienst und dann auf OK . |
Der RAS-Quarantäneagent wird bei der Installation des Dienstes nicht automatisch gestartet. Als Netzwerkadministrator müssen Sie den besten Zeitpunkt zum Start dieses Dienstes festlegen - zusammen mit der Konfiguration des Routing und RAS-Dienstes. Der RAS-Quarantäneagent ist vom Routing und RAS-Dienst abhängig. Wenn der RRAS-Dienst neu gestartet wird, wird der Quarantäneagent jedoch nicht neu gestartet - dies müssen Sie manuell durchführen.
Als Teil der Konfiguration des RAS-Quarantäneagenten müssen die Script-Versionsstrings eingerichtet werden. Diese müssen den Versionsstrings entsprechen, mit denen Rqc.exe über das Quarantänescript ausgeführt wird. Rqs.exe kann so konfiguriert werden, dass es mehrere Versionsstrings akzeptiert. Die zugelassenen Versionsstrings müssen Sie manuell in der Registrierung auf dem RAS-Server konfigurieren. Hierzu ändern Sie mit dem Registrierungseditor (Regedit.exe) den Schlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\rqs\AllowedSet (REG_MULTI_SZ). Standardmäßig ist der Wert AllowedSet mit "RASQuarantineConfigPassed" konfiguriert. Um mehrere Script-Versionsstrings zu nutzen, geben Sie die Strings als separate Zeilen unter dem Wert AllowedSet an.
Standardmäßig wartet Rqs.exe auf TCP-Port 7250 auf Benachrichtigungen von Rqc.exe. Um den standardmäßigen TCP-Port zu ändern, erstellen Sie den Registrierungswert HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\rqs\Port (REG_DWORD) und konfigurieren diesen mit dem entsprechenden Port. Damit die neue Portnummer verwendet wird, müssen Sie den RAS-Quarantäneagenten neu starten. Stellen Sie sicher, dass der für Rqs.exe konfigurierte Port der ist, an den Rqc.exe seine Benachrichtigungen sendet.
Weitere Informationen zur Quarantänesteuerung finden Sie im Dokument Microsoft Windows Server 2003 Quarantänesteuerung .
Beispiele zu Scripts für die Quarantänesteuerung finden Sie unter Sample Scripts for verifying client configuration for VPN Quarantine (englischsprachig) .
TCP/IP-Erweiterungen
Unter Windows Server 2003 SP1 wurden die folgenden Erweiterungen im Bezug auf TCP/IP vorgenommen:
| • | der Schutz vor SYN-Angriffen ist standardmäßig aktiviert |
| • | es gibt neue IP Helper-APIs für Benachrichtigungen zu SYN-Angriffen |
| • | Intelligente TCP-Port-Bereitstellung |
Schutz vor SYN-Angriffen ist standardmäßig aktiviert
Ein TCP-SYN-Angriff (Synchronize) ist ein DoS-Angriff (Denial-of-Service), der mit Hilfe von SYN-ACK-Segmenten (Synchronize-Acknowledgement) währen des TCP-Dreiwege-Handshakes ausgeführt wird. Ein solcher Angriff erzeugt eine große Menge an halboffenen TCP-Verbindungen. Abhängig von der Implementierung des TCP/IP-Protokolls kann eine große Menge an halboffenen Verbindungen zu folgenden Situationen führen:
| • | Der gesamte zur Verfügung stehende Speicher wird ausgelastet. |
| • | Es wird die maximale Anzahl von Einträgen im TCP Transmission Control Block (TCB) - einer internen Tabelle, in der alle TCP-Verbindungen eingetragen werden - verwendet. Weitere Verbindungen sind somit nicht mehr möglich. |
| • | Es wird die maximale Anzahl an halboffenen Verbindungen verwendet. Auch hier sind keine weiteren TCP-Verbindungen mehr möglich. |
Um eine große Anzahl an halboffenen TCP-Verbindungen zu erstellen, senden Angreifer eine große Menge an SYN-Segmenten - jedes Segment verwendet hierbei eine gefälschte IP-Adresse und TCP-Portnummer. Auf die vom Opfer zurückgesendeten SYN-ACKs wird nicht reagiert. SYN-Angriffe werden häufig dazu genutzt, Internetserver lahm zu legen.
Um die Auswirkungen eines SYN-Angriffs zu verringern, minimiert TCP/IP die Menge der für unvollständige TCP-Verbindung verfügbaren Ressourcen und verringert die Zeit bis zum Abbruch der unvollständigen Verbindungen. Wenn ein SYN-Angriff erkannt wird, verringert TCP/IP unter Windows Server 2003 und Windows XP die Anzahl der neu übermittelten SYN-ACK-Segmente. Außerdem wird kein Speicher reserviert, und es werden keine Einträge in der Tabelle angelegt - dies geschieht erst dann, wenn der TCP-Dreiwege-Handshake vollständig ist.
Sie können den Schutz vor SYN-Angriffen über den Registrierungswert SynAttackProtect unter HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters (REG_DWORD) konfigurieren. Um den Schutz zu deaktivieren, setzen Sie den Wert SynAttackProtect auf 0. Zur Aktivierung muss der Wert mit 1 konfiguriert werden.
Unter Windows XP (alle Versionen) und Windows Server 2003 ohne Service Pack ist der Wert SynAttackProtect standardmäßig mit 0 konfiguriert. Unter Windows Server 2003 SP1 hat er standardmäßig den Wert 1.
Weitere Informationen zu diesem Thema finden Sie im Dokument Microsoft Windows Server 2003 TCP/IP Implementation Details (englischsprachig).
Neue IP Helper-APIs für Benachrichtigungen zu SYN-Angriffen
Um einer Anwendung die Benachrichtigung der Netzwerkadministratoren im Fall eines SYN-Angriffes zu ermöglichen, stellt die IP Helper-API die neuen APIs NotifySecurityHealthChange und CancelSecurityHealthChangeNotify zur Verfügung. Im Moment stehen im Microsoft Developer Network (MSDN) leider noch keine Informationen zu diesen APIs zu Verfügung. Sobald weitere Informationen veröffentlicht werden, erfahren Sie in dieser Kolumne mehr darüber.
Intelligente TCP-Bereitstellung
Wenn ein TCP-Peer eine TCP-Verbindungsterminierung durchführt, wird die TCP-Verbindung in den Status TIME WAIT versetzt. In diesem Status wartet TCP zweimal so lange wie die maximale Segment-Lebensdauer (Segment Lifetime - MSL) beträgt. Erst dann kann eine neue Verbindung mit dem gleichen Socket erstellt werden. Der Socket setzt sich aus der Quell- und Ziel-IP und dem Quell- und Ziel-TCP-Port zusammen. Die MSL ist die maximale Dauer, die ein TCP-Segment in einem Netzwerk vorhanden sein kann. Der empfohlene Wert für die MSL beträgt 120 Sekunden. Diese Verzögerung verhindert, dass TCP-Segmente neuer Verbindungen, die den gleichen Socket nutzen, mit TCP-Segmenten der alten Verbindung durcheinander geraten.
Der TCP-Port einer Verbindung im Status TIME WAIT wird als verfügbar betrachtet und kann von einer Anwendung genutzt werden. Dies kann zur folgenden Situation führen:
1. | Eine Anwendung fordert einen verfügbaren TCP-Port an. |
2. | TCP/IP weist einen TCP-Port für den Anwendungssocket zu. |
3. | Die Anwendung versucht einen Socket mit einer bestimmten Ziel-IP-Adresse zu öffnen. |
4. | Die Anwendung baut eine TCP-Verbindung auf und sendet Daten. |
5. | Die Anwendung terminiert die TCP-Verbindung. |
6. | TCP/IP versetzt die TCP-Verbindung der Anwendung in den Status TIME WAIT - und zwar so lange, bis die doppelte MSL abgelaufen ist. |
7. | Die gleiche Anwendung fordert einen weiteren TCP-Port an. |
8. | TCP/IP weist einen TCP-Port für den Anwendungssocket zu. Da der Port für die Verbindung im Status TIME WAIT als offen betrachtet wird, kann es sich beim zugewiesenen Port um genau diesen Port handeln. |
9. | Wenn TCP/IP diesen Port zuweist, versucht die Anwendung einen Socket mit der gleichen Ziel-IP-Adresse zu öffnen. |
10. | Da die Verbindung den gleichen Socket wie die Verbindung mit dem TIME WAIT-Status nutzt, zeigt TCP/IP der Anwendung einen Fehler an. |
Sie können diese Situation folgendermaßen vermeiden:
| • | Konfigurieren Sie den Wert MaxFreeTWTcbs unter HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters (REG_DWORD) auf einen geringeren Wert. Der Wert von MaxFreeTWTcbs steuert die Anzahl der Verbindungen, die den Status TIME WAIT haben können. Nachdem diese Anzahl überschritten wird, wird der Status TIME WAIT automatisch für die älteste Verbindung entfernt. |
| • | Setzen Sie den Wert TcpTimedWaitDelay unter HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters (REG_DWORD) auf einen geringeren Wert. Der Wert TcpTimedWaitDelay legt den Zeitraum fest, in dem eine Verbindung im Status TIME WAIT verbleibt. |
Diese Werte zu verringern, widerspricht jedoch dem ursprünglichen Design von TCP und MSL.
Weitere Informationen zu den oben genannten Registrierungsschlüsseln finden Sie im Dokument Microsoft Windows Server 2003 TCP/IP Implementation Details (englischsprachig). Um zu verhindern, dass Anwendungen Verbindungen mit einem Socket einrichten, dessen Status TIME WAIT ist, wurden unter Windows Server 2003 SP1 ein neuer Algorithmus zur Port-Bereitstellung eingeführt. Wenn eine Anwendung einen TCP-Port anfordert, versucht TCP/IP als erstes einen Port zu nutzen, der keiner Verbindung mit dem TIME WAIT-Status entspricht.
Durch dieses neue Verhalten wird es deutlich unwahrscheinlicher, dass einer Anwendung ein TCP-Port mit TIME WAIT-Status zugewiesen wird. Sie müssen die Registrierungswerte MaxFreeTWTcbs und TcpTimedWaitDelay nun nicht mehr konfigurieren.
Zusätzliche Informationen
Weitere Informationen finden Sie unter: